커스텀 HTTP 인증 헤더

커스텀 HTTP 인증 헤더

---

HTTP 인증 헤더에 사용자 정의 데이터를 넣을 수 있는지 궁금합니다. RESTful API를 설계 중이며 사용자 정의 권한 부여 방법을 지정하는 방법이 필요할 수 있습니다. 예를 들어 FIRE-TOKEN인증 이라고하겠습니다 .

이와 같은 것이 유효하고 사양에 따라 허용됩니까? Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=

두 번째 문자열의 첫 번째 부분 ( ':'앞)은 API 키이고 두 번째 부분은 쿼리 문자열의 해시입니다.

---

RFC2617에 정의 된 형식 은 credentials = auth-scheme #auth-param입니다. 따라서 fumanchu에 동의하면 수정 된 승인 체계가 다음과 같습니다.

Authorization: FIRE-TOKEN apikey="0PN5J17HBGZHT7JJ3X82", hash="frJIUN8DYpKDtOLCwo//yllqDzg="

FIRE-TOKEN체계는 어디에 있고 두 개의 키-값 쌍은 인증 매개 변수입니다. 따옴표는 선택 사항이라고 생각하지만 (p7-auth-19의 Apendix B에서) ...

auth-param = token BWS "=" BWS ( token / quoted-string )

나는 이것이 최신 표준에 적합하고 이미 사용 중이며 (아래 참조) 간단한 확장을 위해 키-값 형식을 제공합니다 (추가 매개 변수가 필요한 경우).

이 auth-param 구문의 일부 예는 여기에서 볼 수 있습니다 ...

http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-4.4

https://developers.google.com/youtube/2.0/developers_guide_protocol_clientlogin

https://developers.google.com/accounts/docs/AuthSub#WorkingAuthSub

---

별도의 사용자 정의 헤더에 넣으십시오.

표준 HTTP 헤더를 오버로드하면 아마도 가치보다 더 혼란 스러울 수 있으며 최소한 놀람 의 원칙을 위반합니다 . 또한 표준 HTTP 헤더 형식 (예 :) 만 처리 할 수있는 상용 툴킷을 사용하려는 API 클라이언트 프로그래머에게 상호 운용성 문제가 발생할 수 있습니다 Authorization.

---

아니요, RFC 2617 의 "자격 증명"정의에 따른 올바른 프로덕션이 아닙니다 . 유효한 auth-scheme을 제공하지만 auth-param 값은 형식이어야하며 token "=" ( token | quoted-string )(섹션 1.2 참조), 예에서는 "="를 사용하지 않습니다.

---

내가 아는 오래된 질문이지만 호기심이 있습니다.

믿거 나 말거나,이 문제는 20 년 전에 HTTP BASIC으로 해결되어 base64로 인코딩 된 username : password로 값을 전달합니다. ( http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side 참조 )

위의 예가 다음과 같이되도록 동일한 작업을 수행 할 수 있습니다.

Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==

참고 URL : https://stackoverflow.com/questions/7802116/custom-http-authorization-header