IT's 잡탕찌개 블로그

HTTP Header 란?

http header란 http 통신에서 client와 server가 요청 또는 응답에 부가적인 정보를 전송할 수 있도록 해준다.

Header 는 대소문자를 구분하지 않는 key값, 그에 대응되는 value값으로 이루어져 있다.

header는 4가지 분류로 구분할 수 있는데 아래와 같이 그룹화 할 수 있다.

. generic header

 - 요청, 응답에 모두 적용되지만 message body 와는 관계없는 header

. request header

 - 패치될 resource나 client 자체에 대한 정보를 포함하는 헤더

. response header

 - 위치 또는 server 자체에 대한 정보와 응답에 대한 부가적인 정보를 포함하는 헤더

. entity header

 - 컨텐츠 길이나 MIME 타입과 같이 Entity body에 대한 자세한 정보를 포함하는 헤더

대표적인 Header의 종류[Request]

. Host : 요청하려는 서버 호스트의 이름과 포트번호

. User-agent : client의 프로그램 정보

. Referer : 바로 직전에 머물렀던 web irl 주소 [ 경우에 따라서 null 일 수도 있다.]

. Accept : client가 처리 가능한 미디어 타입 종류 정보

. Accept-charset : client가 지원 가능한 언어 계열

. Accept-encoding : client가 지원 가능한 언어 encoding

. Content-location : 해당 개체의 실제 위치

. Origin : 서버로 Post 요청을 보낼 때 요청이 어느 주소에서 시작되는지 나타내는 값

. Cookie : 쿠키 값

대표적인 Header의 종류[Response]

. Location : redirect시 이동해야할 url 이 담겨있다.

. Server : web server의 종류

. Age : max-age 시간 내에서 얼마나 흘렀는지 초단위로 알려주는 값.

참고

 - https://hazel-developer.tistory.com/145

 - https://developer.mozilla.org/ko/docs/Web/HTTP/Headers

이번 포스팅에서는 Elasticsearch에 대해서 알아보자.

Elasticsearch란?
Elasticsearch는 Lucene을 기반으로 개발된 검색엔진으로 다양한 방식의 검색을 할 수 있다.
또한 cluster를 구성할 수 있으며, cluster는 여러개의 node로 구성된다.

elasticsearch에서 중요한 개념은 아래와 같다.
. 색인(index)과 역색인(reverse index)
. data의 집계
.cluster
대충 요약하자면 cluster 환경에서 색인과 역색인을 통해 빠른 검색이 가능하며 data에 대해서 집계정보 까지 활용이 가능하다는 것이라고 이해하면 될 것 같다.

Elastic에서는 각 data를 json 형태로 저장한다.
해당 data들은 Index라는 개념으로 구분되어 저장되는데 여기서 Index는 색인의 개념이라기보다는 RDB의 Table과 유사한 개념이라고 생각하면 된다.
해당 Index들은 저장되는 data에 대한 항목별로 각 type 정보들을 정의할 수 있다.
ELK stack에서 data를 import 할 때 자동으로 설정해서 Index가 생성되긴하지만 해당 type에 대해서는 확인을 하는 것이 좋다.
이유로는 특정 항목의 값이 원래는 실수 범위이지만 import 하는 data가 모두 정수값인 경우 index가 type을 정수로 지정하는 경우가 생길 수 있기 때문이다.
cluster의 경우 elastic이 기본적으로 방대한 양의 data를 저장하고 이를 검색에 활용하기 때문에
가령 하드웨어의 용량을 초과하거나 혹은 너무 많은 용량을 지녀 검색이 느려지는 등의 문제가 발생할 수 있다.
이를 방지하기 위해서는 cluster 환경을 구축하는 것이 좋은데 cluster에서 sharding 과 replica를 구현할 수 있기 때문이다.
shard는 Index를 일종의 조각으로 분해하는 것이다.
Index 생성 시 원하는 갯수로 shard 를 지정할 수 있고 이 shard 자체 역시 온전한 Index의 역할을 한다.
해당 shard들은 data volume을 수평분할 및 확장이 가능해지게 하며 여러 shard에 분산된 만큼 검색 성능을 더 끌어 올릴 수 있다.
이 때 오류가 일어나 해당 shard에 대해서 접근을 못하거나 사라지게 되는 경우를 대비하여 replica shard라는 것 역시 존재한다(이하 replica).
replica를 만들면 원본 shard 혹은 해당 shard를 지닌 node에 문제가 발생하더라도 검색기능에는 문제가 생기지 않는다.
물론 해당 replica는 원본 shard와 다른 node에 존재한다.

실제로 elasticsearch 의 설치에 대해서는 다음 포스트에서 알아보자.

참고 - https://nanbuja.com/entry/Elasticsearch%EB%9E%80-%EA%B0%9C%EB%85%90-%EB%B0%8F-%EC%A2%85%EB%A5%98-RDBMS%EC%99%80-%EC%B0%A8%EC%9D%B4

ELK stack이란?
ELK stack이란 말은 서버 개발자라면 한번 들어봤을 것이다.
ELK stack이란 Elasticsearch Logstash Kibana를 구축하여 활용하는 환경을 의미한다고 보면 된다.
ELK를 구성하는 것들 (위의 3가지)는 각자 맡은 역할이 다르고 장단점도 존재하지만 이 포스팅에서는 크게 다루지는 않고 간단하게 역할만 짚고 넘어간다.

Elasticsearch
elasticsearch는 검색엔진이다.
JAVA 언어 기반으로 구현되었으며 data의 검색 및 집계에 사용된다.

Logstash
다양한 data source로부터 data를 수집 및 집계, 가공할 수 있다.
ELK stack에서의 역할은 수집 및 가공된 data들을 Elastic에 전달하는 역할을 맡는다.

Kibana
kibana는 ELK stack에서 모니터링 및 시각화를 담당한다.

ELK stack의 구성형태 및 처리 순서
. Data processing ( Logstash )
-> log, 혹은 DB등에서 data 수집 ( input )
-> data 변환 ( filter )
-> data 전달 ( output )
. Storage ( Elasticsearch )
-> data의 저장
-> data의 분석
-> data의 관리
. Visualize ( Kibana )
-> dashboard등 다양한 시각화 자료 확인 가능
-> elastic 환경에 대한 접근 제어

ELK의 장점
ELK 의 경우 전반적인 장점으로는 빠른 검색과 특정 data들에 대한 분석, 시각화를 손꼽는다.
더불어 개발자가 아니더라도 ata에 대한 집계 및 검색을 하기 쉽다는것도 장점이다.
그 외의 다양한 모듈등이 존재하며 유연하게 data를 분석,가공 할 수 있는 생태계라는것 역시 장점이다.
실제 작성자가 참여한 프로젝트에서도 ELK를 활용했었는데 서버LOG를 빠른속도로 보기 쉽도록 가공된 상태로 조회한다는게 좋았던 기억이 있다.

ELK의 단점
E, L, K의 각각의 단점이 아닌 ELK stack 자체의 단점으로는 아무래도 리소스를 많이 사용한다는 점과 용량 역시 많이 차지한다는 점이 있다.
또한 ELK stack 환경을 구축하는 것이 해당 정보분석에 다소 과하진 않은가 에 대해서도 충분히 고려해야 한다.

HTTP란 무엇인가?
위키에서 HTTP에 대한 설명은 아래와 같다.
HTTP는 W3 상에서 정보를 주고받을 수 잇는 protocol이다.
주로 HTML 문서를 주고받을 때 사용되며 주로 TCP를 사용한다.
(HTTP/3 부터는 UDP를 사용할수 있다고 함)

반면 MSDN에서는 아래와 같이 설명하고 있다.
HTTP는 HTML 문서와 같은 "리소스"들을 가져올 수 있도록 해주는 PROTOCOL입니다.
HTTP는 WEB에서 이루어지는 모든 데이터 교환의 기초이며, Client-Server protocol이다.
수신자 측에 의한 요청이 초기화 되는 protocol을 의미한다.
하나의 오나전한 문서는 텍스트, 레이아웃 정보, 이미지, 비디오, 스크립트 등의 하위 문서들로 재구성된다.
client와 server 들은 개별적인 message를 통해 통신하며 이를 각각 request, response라고 한다.
HTTP는 Application layer의 protocol로 TCP 혹은 암호화된 TLS를 통해 전송된다.
HTTP의 호가장성 덕분에 오늘날 하이퍼 텍스트문서, 이미지, 비디오 등의 정보를 server로 전달하기 위해서 사용되기도 한다.


HTTP기반 시스템의 구성 요소
HTTP 는 기본적으로 client-server protocol이다.
요청은 단 하나의 개체에 의해서 전송되며, 개별적인 요청들은 서버로 보내진 후 server에서는 이 요청에 대해서 처리한 결과를 응답에 담아 전달한다.
이 요청과 응답의 사이에는 여러 개체가 존재하는데 gateway, proxy server 등이 있다.

HTTP에서의 client란?
실제 User를 대신해서 동작하는 모든 도구를 의미한다.
브라우저가 될 수도 있고 web을 크롤링하는 bot이 될수도 있다.
브라우저는 항상 server에 요청을 보내는 개체이며 절대 server가 될 수 없다.(가끔 혼동하는 사람이 있다.)

HTTP에서의 Web Server란?
Server는 Client 요청에 대해서 문서(응답)을 제공하는 역할을 한다.
논리적으로는 단일 기계이지만 실제로는 복합 장치(로드밸런싱, DB, 캐시서버 등)들로 구성 될 수 있다.
  
HTTP의 특징
. HTTP는 간단하다.
. HTTP는 확장가능하다.
. HTTP는 stateless이다.

HTTP의 기본적인 순서
. 요청을 보내거나 응답에 사용 될 TCP 연결을 준비한다.
. HTTP message를 전송한다. 이 때 HTTP essage는 HTTP 버전에 따라 암호화 되기도 한다.
- HTTP /2 이전 버전의 경우 message가 평문이라서 인간이 읽을 수 있지만 HTTP/2는 압축 및 암호화 된다.
. Server에 의해 전송 된 HTTP 응답을 읽는다.
. 이후 TCP연결을 닫거나 다른 요청을 위해서 재사용한다.


HTTP 요청에는 무엇이 있는가?
HTTP는 웹 page를 로드하는데 필요한 정보를 요청하는 방식으로 인터넷에서 이루어진 HTTP 통신에는 여러 정보를 포함하고 있다.

HTTP Request 에 포함된 정보
. HTTP 버전 정보
. URL
. HTTP Method
. HTTP HEADER
. HTTP body

HTTP Method란?
HTTP Method는 HTTP 요청을 통해 Server에 기대하는 작업을 나타낼 수 있다.
Method는 GET, POST, PATCH 등 다양한 종류가 있고 각각의 Method 별로 Server에 기대하는 작업이 다르다.
가령, GET Method의 경우 요청에 대한 응답으로 특정 정보를 수신하는 것을 기대하는 반면, POST Method의 경우 요청정보에 포함된 특정 값들이 Server의 data에 반영되는것을 기대한다.

HTTP HEADER란?
HTTP HEADER에는 Dictionary Data가 저장된다.
키와 대응되는 값이 포함되어 있으며 HEADER는 모든 HTTP요청 및 응답에 포함된다.
HEADER 에는 브라우저가 활용하거나 요청 데이터와 관련된 정보등 핵심정보들이 포함된다.


HTTP Request Body
HTTP Request Body에는 여러가지 정보가 포함되어 있거나 어떤한 정보도 없을 수 있다.
실제 현실에서는 주로 특정 유저의 data가 포함되거나 검색을 요청 시 검색타입 및 검색어가 포함되어 있다.

HTTP Response에 포함된 정보
. HTTP Status Code
. HTTP HEADER
. HTTP Request Body

HTTP Status Code란?
HTTP Status Code는 HTTP요청에 대한 상태를 나나태며 해당 요청이 정상적으로 응답되었는지 등에 대한 여부를 구분할 수 있게 각각 여러 값을 지닐 수 있다.
(HTTP Status Code에 대해서는 별도 포스팅할 예정)

HTTP Response Body 란?
HTTP Response Body 는 HTTP Request Body 처럼 응답에 포함되는 여러 정보를 포함한다.
가령, HTTP Request Method가 GET인 경우에 대한 응답일 경우 해당 URL에 대한 HTML 문서가 포함된다.

HTTP HEADER
HTTP Response  의 경우에도 HEADER를 포함한다.
이 때 HEADER에 포함되는 정보는 응답 본문의 내용이 어떠한 컨텐츠 타입인지, 해당 데이터의 언어 형식 등 중요한 정보가 포함되어 전달된다.



참고 -
https://developer.mozilla.org/ko/docs/Web/HTTP/Overview https://www.cloudflare.com/ko-kr/learning/ddos/glossary/hypertext-transfer-protocol-http/

client
. client는 일반적으로 WEB에 연결된 장치를 의미한다.
. 모바일 장치, pc, web browser 등이  client 에 속한다.

server
. 일반적으로 web page, site을 저장하거나 application 을 구동하는 장비를 server라고 지칭한다.


web page 접속 시 발생하는 일들.
. 브라우저는 DNS에 입력받은 URL 주소를 요청 후 실제 IP를 확인.
. 브라우저는 server 로부터 web site의 사본을 HTTP을 사용하여 요청한다.
. server는 요청을 수신 후 응답코드와 함께 응답 메세지를 브라우저에 전달한다.
-> TCP 소켓을 통한 응답이기때문에 Strem 형식으로 전달 및 수신된다.
. 브라우저는 응답을 수신 후(해당 stream을 모두 수신 및 조립 완료 후) web page로 유저에게 노출한다.
-> 일반적인 경우에 html 이 포함된 응답이 전달되므로 이렇게 설명함.



참고 : https://developer.mozilla.org/ko/docs/Learn/Getting_started_with_the_web/How_the_Web_works

인터넷은 어떻게 동작하는가?
두개의 컴퓨터 사이에서 통신이 필요한 경우 우리는ㄴ 다른 컴퓨터와 물리적, 혹은 무선으로 연결되어야 한다.
이런 네트워크 연결은 단순히 두대의 컴퓨터로 제한되진 않는데 연결 수가 많아질수록 매우 복잡해진다.
(네트워크 연결 구조에 대해서는 나중에 포스팅 할 예정이다.)
이러한 복잡한 연결을 줄이기 위해서 각 PC는 "라우터"라는 장비에 연결되며, 이 라우터는 신호에 따라서 특정 PC에 메세지를 보내고 잘 도착하는지를 확인한다.
이러한 방식으로 특정  라우터에 소속된 pc 집단에서의 통신 또는 다른 라우터에 속한 pc집단 사이에 통신을 할 시 두대의 라우터 사이의 연결만으로도 통신이 가능해진다.

이러한 방식으로 네트워크를 확대하는 것이 가능하며 같은 네트워크에 속한 pc같의 통신이 가능해진다.
여기서 더 나아가 라우터로 직접 연결되지 않은 다른 네트워크에 "모뎀"을 통해  접근하며 다른 지역의 네트워크까지 통신이 가능해진다.
이러한 서비스를 제공하는 인터넷 서비스 제공 업체를 우리는 ISP(Internet Service provider)라고 부른다.

IP Address란?
그렇다면 네트워크 상에서 다른 PC에 대해서 어떠한 방식으로 특정을 하는 방법이 필요하다.
현재 우리의 인터넷 환경은 IP주소를 통해 특정 라우터 혹은 PC를 구분하는 방식을 사용한다.
IP주소 할당 방식 등 좀더 깊은 내용이 있지만 해당 포스팅에서는 다루지 않는다.

DNS
하지만 오늘날 우리는 naver등에 접속할 때 위의 IP 주소를 직접 URL창에 입력하지 않는다.
우리가 입력하는 것은 "domain"인데 이는 Domain Name Service를 통해 IP 주소와 mapping 되어 있기 때문에 어떠한 네트워크에 접속할지를 판단할 수 있다.
(DNS 역시 별도 포스팅을 통해 알아보자.)



참고 : https://developer.mozilla.org/ko/docs/Learn/Common_questions/Web_mechanics/How_does_the_Internet_work

restful api란 무엇인가?
restful api란 두 컴퓨터 사이의 정보를 안전하게 교환하기 위해 사용되는 인터페이스 중 하나이다.
여러 API 방식 중 일반적으로 REST 원칙을 따르는 API를 지칭한다.

대부분의 사람들이 REST API는 URL 을 통해서 Resource를 식별하고 Http Method를 사용하여 해당 Resource에 대한 행위를 규정하며 그 결과를 전달 받는 것으로 알고있다
이 포스팅에서는 REST API에 대해서 좀더 자세히 알아본다.

REST란? ( Representational State Transfer )
분산 하이퍼 미디어 시스템을 위한 API 아키텍쳐 스타일을 의미한다.
오늘날 HTTP 규약만 잘 지켜도 REST API 조건 중 다수를 만족할 수 있다.
그렇다면 REST API 아키텍처 스타일에는 어떤것들이 있을까?
주요 스타일은 아래의 6가지가 존재하며 해당 사항에 대해 좀더 자세히 알아볼 것이다.
. client - server
. stateless
. cache
. uniform interface
. layered system
. code on demand(Optional)

Client - Server
. UI는 client에서, data는 server에서 처리하여 관리한다.
. 즉, client와 server가 별도로 개선될 수 있어야 한다.

Stateless
. client와 server는 요청을 완료할 때 필요한 모든 정보를 제공해야 한다.
. 요청이 일어난 시점에 제공된 정보만을 사용하여 작업을 완료할 수 있어야 함.

Cache
. 응답은 cache될 수 있어야 하며, 이는 성능향상에 도움이 된다.

Layered System
. 계층화된 구조를 활용하여 각 Component의 행동을 제약하고 추상화 할 수 있어야 한다.
-> REST Server는 다중 계층으로 구성될 수 있고 보안, 로드 밸런싱, 암호화 계층 등 을 추가할 수 있다.


Uniform Interface
: resource에 대한 조작을 통일되고 한정적인 interface로 수행하는 아키텍처를 의미한다.
. resource는 uri로 식별이 되어야 한다.
. resource에 대한 관리는 http method에 해당 방식이 포함되어야 한다.
-> http method로 CRUD 구분
. self-descriptive message
-> message는 스스로를 설명해야한다
-> message 안에 해당 요청, 응답에 대한 모든 정보가 포함되어야 한다.
  => ex : message 안에 Content-Type이 생략되어 있는 등의 경우는 self-descriptive message를 불만족.
. HATEOAS
-> application의 상태는 항상 hyperlink를 이용해서 전이되어야 한다.
  => ex : 게시글 생성 버튼 링크를 통해 application의 상태가 변경된다.

Code on Demand(Optional)
. Server에서 보낸 정보를 토대로 client에서 code를 실행할 수 있어야 한다.
-> ex : server 가 client 에 응답으로 보낸 것중 javascript

Uniform Interface가 필요한 이유
. server와 client 간의 독립성을 보장하기 위해서
-> ex : server가 기능을 변경해도 client는 업데이트 할 필요가 없다.
-> ex : web의 경우 브라우저 업데이트가 되어도 web site는 변경할 필요가 없다.

REST API를 구현 시 주의해야 할 설계 원칙은 어떤 것들이 있을까
. Url 은 Resource를 표현해야 한다.
. Resource에 대한 행위는 Http Method를 통해 나타낸다.
. 슬래시는 Url 마지막에 사용하지 않는다.
. 하이픈은 Url 가독성을 높이기 위해서 사용할 수 있다.
. 언더바는 띄어쓰기처럼 보일때가 있고, Url에 혼동을 줄 수 있어 사용하지 않는다.
-> 하이픈을 사용하는걸 추천
. Url 경로에는 소문자만 사용한다.
-> Url은 대소문자를 구분하기 때문에 다른 resource로 인식할 여지가 있다.
. file 확장자는 url에 포함시키지 않는다.
-> 대신 Header에 AcceptHeader를 사용하여 file의 확장자를 알수 있게 한다.


REST API를 통한 CRUD 작업과 이에 대응하는 Http Method
. CREATE : POST
. READ : GET
. UPDATE : PUT, PATCH
. DELETE : DELETE
=> Http method와 관련된 CRUD에 대해서는 추후 좀 더 자세한 포스팅으로 다룰 예정이다.


참고
. https://youtu.be/RP_f5dMoHFc?si=q-5csLAZvzXnm_-h

. https://kmkunk.tistory.com/m/139

개인 공부용 포스팅입니다. 틀린 내용이 포함되어 있을 수 있으니 적당히 거르고 검증하시길 바랍니다.

틀린 내용은 댓글로 알려주시면 확인 후 반영하겠습니다.

세션이란 무엇인가?

 - 웹에서 사용자의 정보를 저장하는 방법을 의미한다.

 - 또 다른 의미로는 사용자가 브라우저를 닫기전까지 연결이 유지되는 상태를 의미하기도 한다.

Session은 server에 사용자의 중요한 정보를 저장하고 이에 대한 id값을 cookie에 전달하여 

실제 사용자가 해당 id를 통해 사용자 정보에 접근할수 있게 해준다.

기존 Cookie를 활용하는 방법보다는 보안성 측면에서 훨씬 안전하다.

일반적인 Session 과정

 - 사용자가 server 에 접속

 - server는 해당 요청 속 JSESSIONID header가 존재하는지 여부를 확인

 - 없다면 새로운 session id를 발급

 - 발급된 session id를 response의 JSESSIONID Header에 저장

 - 이후 요청에는 신규발급된 session id가 포함되어 요청됨

 - 사용자의 로그인 요청

 - 해당 유저의 로그인 정보 확인

 - 확인 후 적합한 로그인 요청이었다면 해당 회원에 대한 session 정보 생성

 - 각 요청에 대해서 server는 session id를 통해 해당 유저의 session data를 활용

   -> 해당 유저의 요청에 대해서 authentication, authorization 등을 검증 시 활용.

참고 : 해당 JSESSIONID cookie는 session cookie이므로 브라우저와의 접속이 끊길 시 자동으로 사라진다.

참고2 : JSESSIONID cookie에 대해서 별도의 만료기간을 지정할 수 있다.

세션의 실제활용 예

 - 로그인을 한 유저인지 판별

 - 로그인 후 특정 권한에 대한 정보 식별

 - 특정 page에 접근 시 권한 확인.

 - 유저가 로그아웃 시 새로운 session id를 발급.

세션의 단점

 - 기본적으로 cookie보다는 보안성이 좋지만 특정 유저의 session id를 탈취당하면 보안이슈가 발생할 수 있다.

개인 공부용 포스팅이라 다소 틀린 내용이 포함되어 있을수 있으니 적당히 거르고 검증해서 보시기 바랍니다.

틀린내용은 댓글로 알려주시면 감사합니다.

쿠키란?

 - 서버의 필요에 따라서 웹 브라우저가 저장하는 작은 데이터들이라고 생각하면 된다.

 - 쿠키는 서버에서 오는 응답 속 header 내용에 따라서 저장된다.

 - 그냥 로컬 파일 데이터라고 생각하면 편함

쿠키는 어떻게 사용하는가?

 - 서버의 응답속 Heaer 중 Set-Cookie Header안에 key=value 형태로 포함되어 있다.

 - 해당 key에 따른 value 값을 저장하며 쿠키 항목에 대한 여러가지 추가 설정을 지정할 수 도 있다.

쿠키 저장 순서

 - Response 내의 Set-Cookie Header 확인.

 - 해당 Header 속 cookie들을 웹 브라우저가 저장

 - 그 이후 브라우저를 통해 보내는 요청에는 cookie 정보가 포함되어 전송된다.

쿠키의 활용 예

 - 특정 유저의 로그인 정보를 개별 브라우저에 저장하여 자동 로그인에 활용 가능

 - 특정 계정의 인터넷 검색어 등을 쿠키에 저장하고 이를 활용하여 유저에게 맞춤 화면을 노출 가능.

쿠키의 장점

 - http 특징중 하나인 stateless를 극복하려할 때 쿠키를 사용 가능.

  -> 위의 활용 예와 같은 경우 특정 유저에 대한 일종의 상태정보를 쿠키로 누적 가능.

쿠키의 단점

 - 브라우저에 저장된다.

 - 타인에게 노출되거나 변조될 여지가 있다.

 - 웹 브라우저마다 생성되기 때문에 다른 브라우저로 접속시 쿠키가 유지되지 않는다.

사실상 단점중 보안상의 이슈가 제일 크며 이로 인해 중요한 정보를 쿠키로 저장하면 이슈가 생길 수 있다.

==============

위에서는 간단한 내용만 적어보았고 이제 좀더 세세한 내용을 알아 보자

===============

쿠키의 종류는 어떤것이 있을까?

1. persistence cookie

2. session cookie

persistence cookie

 - 파일로 생성된다.

  -> tmi : 임시 인터넷 파일로 생성됨.

 - 브라우저의 쿠키 파일을 삭제하거나 해당 쿠키가 만료된 후 사라진다.

 - 최초 접속 시 서버로 전송된다.

 - 주로 사용되는 곳으로는 팝업 하루동안 띄우지 않기 등이 있다.

session cookie

 - 브라우저의 메모리에 생성된다.

 - 브라우저를 종료하면 사라진다.

 - 최초 접속 시 서버로 전송되지 않는다.

 - 주로 session id를 저장할 때 허용된다.

cookie 실제 추가 요청 시

server response :

 - Set-Cookie : tmp_cookie=tmp_val

 - Set-Cookie : other_key=other_value

cookie가 실제 request에 포함되어 있을 때

 - cookie Header 안에 포함되어 온다.

 - ex 

    -> cookie : tmp_name=tmp_val;  other_cookie_name=other_cookie_val; ...

    -> cookie라는 Header 안에 ;를 구분자로 여러 cookie 항목이 저장되어 있다.

위와 같이 server response에 Set-Cookie header가 들어 있다면

브라우저는 해당 cookie들을 저장한다. 이때 Set-Cookie는 한가지 쿠키밖에 지정을 못하기 때문에 

여러 쿠키를 저장할 경우 Set-Cookie Header를 여러개 지정해 주어야 한다.

cookie 추가 시 여러가지 속성 지정하는 방법

Header에 cookie를 지정할 때 여러가지 속성을 지정할 수 있으며 종류는 대략 아래와 같다.

 - cname=calue : cookie 이름과 cookie 값

 - expires=someday : 해당 cookie의 만료 기간에 대한 정보.

  -> 참고 : Max-Age로 해당 쿠키의 유효기간을 짖어할 수도 있다

  -> 참고2 : expires, Max-Age를 지정하면 해당 cookie는 persistence cookie가 된다.

그외에도 path, domain 등의 속성 지정이 가능하니 필요 시 검색해보길 바란다.

session cookie 중 알아야하는 것으로는 JSESSION cookie 항목이 있다.

 - Session에 대한 정보를 서버가 저장한 후 이에 대해 접근할 수 있도록 지정한 id 를 저장하는 cookie

 - 주의 : Session 에 대한 정보를 저장한 cookie가 아니고 그에 대한 식별id 정보이다.

 - 주의2 : 해당 JSESSION 속 session id는 각각 접속시, 각각의 브라우저 마다 다르게 할당된다.

해당 포스팅은 개인 공부용으로 정리하는 내용이며 잘못된 내용이 포함되어 있을 수 있습니다.

잚소된 내용은 댓글로 알려주시면 반영하겠습니다.

OAuth란 무엇인가.

공식 url : https://oauth.net/2/

OAuth란 인증을 위한 개방형 표준 프로토콜이다.

예전부터 문제가 많이 발생했던 각 홈페이지가 특정 유저의 개인 정보를 수집, 활용하던 방식에서

유저와 특정 서비스가 믿을만한 중개사를 끼고 인증을 보장받는 방식으로 바뀐것이 OAuth 라고 생각하면 이해가 쉽다.

기존의 서비스에서 발생하던 문제들은 주로 불필요한 개인정보 수집, 그리고 이로인한 해킹등의 보보안 이슈로 인해서 발생하는 개인정보 유출 등이 있다. 이러한 문제를 해결하고자 많은 사람들이 고심하며 만들어낸 것이 OpenID, OAuth이다.

현시대에서 게임에 로그인하거나 쿠팡등의 서비스에 로그인할 때 "간편 로그인"으로 들어갈 수 있게 해주는 인증방식을 제공해주는 것이 OAuth이다.

OAuth에서의 주요 용어와 그 뜻

Authentication

 - 인증 자격이 있는지 검증하는 단계

Authorization

 - 접근 자격, 권한을 부여하는 것을 의미하며, 인가완료 시 접근권한이 담긴 AccessToken을 부여한다.

AccessToken

 - 리소스에 대한 접근 권한을 획득할 때 사용되는 Token으로 만료기간이 존재한다.

 - AccessToken은 특별히 어떤 형식을 지니고 있지 않다.

RefreshToken

 - AccessToken 만료 시 갱신하기 위한 용도로 사용되는 Token이다.

OAuth에서의 각 역할 주체

Resource Owner

 - 자원 소유자를 의미하며 특정 Service에 해당 자원에 대한 접근 권한을 부여해주는 주체를 의미한다.

 - ex : game에 간편로그인으로 접속하려는 user

Client

 - 자원에 대한 접근 요청을 하는 Service 또는 App

Resource Server

 - 사용자의 자원에 대한 호스팅을 담당하는 Server

Authorization Server

 - 인증과 권한 부여를 수행하는 Server로 client의 접근자격을 확인한 후 AccessToken을 발급하여 권한을 부여한다.

OAuth 인증 방식의 종류

Authorization Code

 - 권한 부여 승인 코드 방식

 - 가장 많이 쓰이고 있는 방식이다.

 => ex : 간편 로그인

 - client가 User를 대신하여 특정 자원에 대한 접근을 요청할 때 사용되는 방식.

 - Refresh Token이 사용 가능하다.

Impicit Grant [ legacy ]

 - 자격증명을 안전하게 저장하기 힘든 환경에 최적화된 방식.

 => ex : 자바스크립트 등

 - 권한부여 승인 코드 없이 바로 AccessToken이 발급된다.

 - Token 유출을 막기 위해서 해당 Token의 만료기간을 짧게 설정하며 RefreshToken의 사용이 불가능한 방식이다.

Resource Owner Password Credential Grant [ legacy ]

 - 자원 소유자 자격 증명 승인 방식

 - username, password를 통해 AccessToken을 받는 방식으로 RefreshToken까지 사용이 가능하다.

 - 이 방식은 권한서버, 리소스 서버, client가 모두 같은 시스템에 속해있을 때 사용해야 한다.

Client Credentials

 - client가 자신이 관리하는 resource 혹은 권한 서버에 해당 client를 위한 별도의 resource가 존재할 때 사용된다.

Device Code

 - 해당 인증방식은 브라우저가 없거나 입력이 제한된 장비에서 이전에 AccessToken를 위해  획득된 device code를 교체하기 위한 과정에서 사용된다.

 - client가 AccessToken이 만료된 경우 사용하는 인증 방식.

 - 이 경우 client는 user와 상호작용 없이 적합한 AccessToken을 획득할 수 있다.