쿠키 맛있게 굽는 방법

Cookie

: Http 의 stateless의 단점을 보완하기 위해 최소한의 상태정보를 저장하는 개념.
상태정보를 서버측에 저장 : session
상태정보를 클라이언트측에 저장 : Cookie

Cookie 사용 단계

1. 쿠키 생성

2. response에 쿠키를 실어 클라이언트에게 전송(header에.)

   • line [상태코드],
     header [쿠키가 들어가기 적합],
     body [클라이언트에게 보내지는 컨텐츠]
   • header에 저장하기 때문에 문자 형태로 전송된다.
   • Base64, ASCII 쿠키라는 녀석은 클라이언트의 저장소를 빌려 사용하는데 쿠키 정책을 참조한다.

3. 각 브라우저는 쿠키를 저장할 수 있는 저장소를 가짐. 이 쿠키 저장소에 자기의 쿠키를 저장한다.

4. 다음번 요청시(request)에 쿠키를 포함시켜 서버에 재전송(header에 저장)

5. request를 통해 전송된 쿠키를 상태 복원

http resp header를 통해 전달되며 세번째 문단이 쿠키의 정책이다.


크롬의 저장소

엣지의 저장소

VALUE값을 통해 구분한다. 각 브라우저를 대상으로 세션이 유지되며
브라우저별로 쿠키 저장소는 별도이다.

4번째 단계로 이 쿠키를 받아 상태를 복원한다.

이제는 제대로 사용해보자.

클라이언트가 보내는 정보를 절대로 믿어선 안된다.

null값이 존재할수도 있다.

우선 쿠키가 존재하는지 확인할 것.

예로 네이버에 남겨있는 쿠키가 다음에서도 쓸수있다면?
이를 막아주는게 도메인이다. 도메인이 동일한 경우에만 재전송이된다.

도메인 다음으로 기준이 되는것이 Path이다.path로
설정된 경로 이하로 발생하는 요청에만 쿠키를 재전송.
생략시 쿠키의 생성 경로가 반영됨.

Session은 쿠키를 지울 시기를 저장하고 있다. 쿠키의 기본값을 지정하지 않으면 쿠키의 MaxAge와 같다. 만일 세션에 이 값이 지정되어 있지 않다면 세션 종료와 함께 쿠키도 사라진다.

HttpOnly는 해당 프로토콜로만 재전송하겠다는 의미이다.

사진과 같이 여러 프로토콜로 전송이 가능한데 HttpOnly에 체크되어 있다면 Htttp 프로토콜만 이용한다는 의미이다.

Secure를 사용한다면 Https이다.

모든 도메인이 동일한 경우에만 전송된다.
도메인은 레벨 구조를 가지는데, 패턴매칭을 통해 모든 레벨이 동일한 경우에만 재전송한다.

이 모든 구조는 쿠키를 어떤 조건하에 전송할 것인지 기준이 되는 정보이다.

는 크롬이 자체적으로 우선순위를 지정한것임.

톰캣 8.5를 사용하기 때문에 오류가 안나는데.

반드시 %인코딩 방식을 이용해야 하는 제약이 있는데 위 사진에서는 전혀 읽을 수 없는 문자가 저장되어있다.


한글이 깨지지 않고 출력된다.

한글을 포함한 문자를 원형그대로 보내서는 안된다. 톰캣8.5가 아닐 수도 있고, 이를 지원하지않는 브라우저 일수 있기 때문에.

반드시 decode를 수행해야한다.

컨텍스트와 컨텍스트 사이 데이터를 주고 받을 수 있다. 만일 경로를 /로 시작한다면