인증
Authorization
- 클라이언트 인증 정보를 서버에 전달
WWW-Authenticate
- 리소스 접근시 필요한 인증 방법 정의
- 보통 401 Unauthorized 응답과 함께 사용한다
* WWW-Authenticate : Newauth realm="apps", type=1, title="Login to \"apps\"",Basic realm="simple"
Newauth realm="apps", type=1, title="Login to \"apps\""
- Newauth라는 사용자 정의 인증 방식을 설명
realm="apps"
- 인증이 적용되는 영역, 자원을 의미하며 클라이언트에게 어떤 영역에 대한 인증이 필요한지 알려주는 역할
type=1, title="Login to \"apps\""
- 추가적인 인증 정보를 의미하며 구체적인 방법은 서버, app의 문서를 참조해야함
Basic realm="simple"
- HTTP 기본 인증을 의미하며, 사용자의 이름과 비밀번호를 :로 연결 후 Base64로 인코딩하여 전송함
Stateless (무상태)
- HTTP는 무상태 프로토콜
- 요청과 응답을 주고받으면 연결이 끊어짐
- 재 요청시 서버는 이전 요청을 기억하지 못함
- 서로 상태를 유지하지 않음
위 특징을 해결하기 위해 착안한 방안
1. 쿠키
Set-Cookie
- 서버에서 클라이언트로 쿠키 전달
Cookie
- 클라이언트가 서버에서 받은 쿠키를 저장 후, HTTP 요청시 서버로 전달
생명 주기
- 영속 쿠키
-
Set-Cookie : expires=sat, OO-DEC-OOOO 00:00:00 GMT
만료일 지날경우 삭제
-
Set-Cookie : max-age=3600
0이나 음수 지정시 쿠키 삭제
-
세션 쿠키
만료 날짜 생략시 브라우저 종료시 까지만 유지
도메인
domain=example.org
- 명시 - 명시한 문서 기준 도메인 + 서브 도메인 포함
-
domain=example.org 쿠키 생성시
* example.org, dev.example.org도 쿠키 **접근 가능**
- 생략 - 현재 문서 기준 도메인만 적용
-
example.org에서 쿠키 생성 후 domain 지정을 생략
* example.org 에서만 쿠키 접근, dev.example.org는 쿠키 **미접근**
경로
경로를 포함한 하위 경로 페이지만 쿠키 접근
ex)
- path=/home 지정 시,
- /home, /home/level1/~ 가능
- /hello 불가능
보안
1. Secure
- 쿠키는 http,https 구분하지 않고 전송
- Secure 적용시 https인 경우에만 전송한다
2. HttpOnly
- JS에서 접근 불가능함
- HTTP 전송에만 사용함
3. SameSite
- 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키를 전송한다
사용처
- 사용자 로그인 세션 관리
- 광고 정보 트래킹
주의 사항
- 보안에 민감한 데이터 저장 지양
생명 주기
1.1 쿠키 미사용시
- 모든 요청과 링크에 사용자 정보를 포함시킨다
-> 브라우저 완전히 종료하고 다시 열면 동일한 문제 발생
-> 요청마다 데이터 낭비가 생길 가능성이 높음
2. 캐시
캐시가 없을 때의 특징
- 데이터 변경이 없어도 계속 네트워크를 통해 데이터를 다운받아야함
- 브라우저 로딩 속도가 느림
캐시 사용시 특징
- 캐시 유효 시간동안 네트워크를 사용하지 않아도 됨
- 브라우저 로딩 속도가 빨라짐
HTTP/1.1 200 OK
Content-Type: image/jpeg
cache-control: max-age=60 //브라우저 내의 캐시에서의 유효시간 60초를 의미
Content-Length: 34012
--message body--캐시 시간 초과
- 캐시 유효 시간 만료시 서버에서 데이터를 다시 조회, 캐시를 갱신함
이때, 서버에서 기존 데이터를 변경 혹은 유지 두 가지 상황이 나타남
- 데이터를 변경하지 않았을 경우
- 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있음
ex)
HTTP/1.1 200 OK
Content-Type: image/jpeg
cache-control: max-age=60의미
Last-Modified : 0000년 00월 00일 00:00:00 // 데이터의 수정 시간을 의미
Content-Length: 34012
--message body--Last-Modified를 기준으로 데이터의 수정 여부를 확인할 수 있음
위처럼 Last-Modified를 검증 헤더라고 하는데, 검증 헤더는 조건부 요청과 함께 쓰는 경우가 많음
검증 헤더와 조건부 요청
- 304 Not Modified + 헤더 메타 정보만 응답
- 응답 헤더 정보로 캐시의 메타 정보를 갱신함, 만약 미갱신시 캐시에 저장돼있는 데이터를 재활용함
- 이 과정에서 네트워크 다운로드가 발생하긴 하지만 용량이 적은 헤더 정보만을 다운받으므로 매우 실용적인 해결책임
검증 헤더
- 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터
ex) Last-Modified, ETag
- Last-Modified
- 데이터가 수정 됐다면 200 OK, 미변경시 304 Not Modified
- ETag
- 데이터를 변경시 이름을 바꾸기 때문에 단순히 ETag를 보내서 같으면 유지, 다르면 다시 다운 받기를 선택할 수 있음
ex) ETag : "v1.0" -> ETag: "v2.0"
조건부 요청 헤더
- 검증 헤더로 조건에 따른 분기
ex)
If-Modified-Since: Last-Moidified 사용
If-None-Match : ETag 사용
조건 만족시 200 OK, 불만족시 304 Not Modified
캐시 제어 헤더
- Cache-Control - 캐시 제어
하위 호환
- Pragma - 캐시 제어
- Expires - 캐시 유효 기간
Cache Control
- max-age
- 캐시 유효 시간 단위
- no-cache
- 데이터는 캐시해도 되지만, 사용할때마다 본 서버에서 검증하기
- no-store
- 저장하면 안됨 (개인정보 등)
Pragma
하위 호환으로, no-cache만을 사용함
Expires
하위호환으로 캐시 만료일을 지정한다
- 캐시 만료일을 정확한 날짜로 지정함
ex) Mon, 01 Jan 1990 00:00:00 GMT
하지만, 현재는 cahce-control의 max-age가 더 유연하므로 사용하지 않음
