티스토리 뷰

벌써 9주 차 수업이 끝났다는 사실이 믿기지가 않다. 

 

수강 완료까지 3주밖에 남지 않았다.

 

이번 주는 그리 열심히 공부하지 못했다.

회사 발표 준비로 많은 시간을 할애했기 때문에 강의에 집중하기 어려웠다.

참고로 발표 주제는 'TTA 시험인증 취득을 위한 HTTP Digest'였다. (TTA 시험인증을 이미 취득했으니 해당 사이트에서 확인 가능).

 

이번 주엔 쇼핑몰 제작을 통해 지금까지 배운 내용을 전반적으로 복습하고, 보다 심화된 과정을 배우는 시간이었다.

아직 익숙하지 않은 부분이 많아 10분짜리 강의를 소화하는 데에 1시간이 넘게 걸렸다.

이를 극복할 수 있는 유일한 방법은 반복 학습과 숙달뿐임을 알고 있다.

언젠가 나도 무념무상으로 자연스레 테스트코드를 작성하고, 최적의 로직을 구상할 수 있는 사람이 되어 있길 바라본다.

 


이번 주는 공부보다 좀 더 집중했던 HTTP Digest를 간단히 정리하고 넘어가볼까 한다.

누군가에겐 필요할 수 있는 정보이니 번외로 생각하면 될듯 하다.

 

HTTP Digest는 HTTP 표준 인증방법 중 하나이다.

작동 원리

Client에서 요청을 보낸다.

 

Server에서는 WWW-Authenticate 헤더에 인증에 쓰일 정보를 각 필드에 담아 401 응답을 전달한다.

필드 종류로는 realm, alogrithm, qop, nonce 등이 있다.

HTTP Digest에서 쓰이는 algorithm은 MD5, SHA-256 이 대표적이다.

단, 브라우저별로 지원이 안 되는 경우가 있으므로 mdn을 참고하는 것이 좋다.

 

Client에서는 401 응답과 함께 www-authenticated 헤더에 담긴 정보를 활용하여 요약을 생성하고, Authorization 헤더에 필드마다 해당 정보를 채워 다시 요청을 한다.

 

server는 정보를 비교하여 올바른 정보라고 판단하면 200응답을 하게 된다.

 

여기서 내가 겪은 문제는 client라고 표현되지만 사실 이 client는 엄연히 따지면 브라우저다.

인증에 쓰인 사용자가 입력한 개인정보는 개발자가 만든 JS 코드에서 알 수 없다.

401 응답과 함께 WWW-Authenticate 헤더가 있으면 브라우저가 반응하여 아래와 같은 로그인 다이얼로그를 띄우게 된다.

chrome에서 보게되는 dialog

여기 입력된 정보는 브라우저의 보안정책때문에 JS 내부에서 알 수도 사용할 수도 없게 된다.

이를 방지하려면 RFC7616에 나온 표준이 아닌 방법 즉, 비표준을 사용해야 한다.

예를 들자면,

Authorization: Digest
    username=<username>,
    realm="<realm>",
    uri="<url>",
    algorithm=<algorithm>,
    nonce="<nonce>",
    nc=<nc>,
    cnonce="<cnonce>",
    qop=<qop>,
    response="<response>",
    opaque="<opaque>"

Authorization 헤더에 들어가는 스키마를 위와 같은 Digest가 아닌 X-Digest라는 식으로 변경해야 한다.

 

반응형
LIST
댓글
링크
공지사항
최근에 올라온 글