HTTP 권한 헤더에 사용자 지정 데이터를 넣을 수 있는지 궁금합니다. 우리는 RESTful API를 설계하고 있으며 사용자 정의 인증 방법을 지정하는 방법이 필요할 수도 있습니다. 예를 들어, FIRE-TOKEN 인증이라고합시다.사용자 지정 HTTP 권한 헤더
겠습니까 뭔가 : Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=
(전과 ':') 두 번째 문자열의 첫 번째 부분은 API의 핵심은, 두 번째 부분은 쿼리 문자열의 해시 .
별도의 맞춤 헤더에 넣으십시오.
표준 HTTP 헤더를 과부하하는 것은 아마도 혼란을 야기 할 수 있으며 principle of least surprise을 위반하게됩니다. 표준 양식의 일반적인 HTTP 헤더 (예 : Authorization) 만 처리 할 수있는 상용 도구 키트를 사용하려는 API 클라이언트 프로그래머에게도 상호 운용성 문제가 발생할 수 있습니다.
아니요, RFC 2617의 "자격 증명"정의에 따라 유효한 제작물이 아닙니다. 유효한 auth-scheme을 지정했지만 auth-param 값은 token "=" (token | quoted-string) (1.2 절 참조)이어야하며 예제에서는 "="그런 식으로 사용하지 않습니다.
그건 맞지 않아. 예제 형식에 대해서는 5 페이지를 참조하십시오. 권한 부여 : 기본 QWxhZGRpbjpvcGVuIHNlc2FtZQ == – NRaf
사실입니다. 그러나 http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16#section-2.3.1에서 ""b64token "표기법은 기존 인증 체계와의 호환성을 위해 도입되었으며 오직 챌린지/자격 증명마다 한 번만 사용할 수 있으므로 새로운 스키마는 "auth-param"구문을 대신 사용해야합니다. 그렇지 않으면 향후 확장이 불가능할 수 있기 때문입니다. " 사용자 정의 헤더에서 인증을 수행하는 것과 관련하여 캐시 토론을 참조하십시오. – fumanchu
RFC2617에 정의 된 형식은 credentials = auth-scheme #auth-param입니다. 그래서, fumanchu와 동의에, 나는 수정 된 인증 방식이 FIRE-TOKEN는 방식과 두 개의 키 - 값 쌍은 인증 매개 변수입니다입니다
Authorization: FIRE-TOKEN apikey="0PN5J17HBGZHT7JJ3X82", hash="frJIUN8DYpKDtOLCwo//yllqDzg="
과 같을 것이다 생각합니다. 나는 ... (P7-인증-19의 Apendix B에서) 따옴표는 선택
auth-param = token BWS "=" BWS (token/quoted-string)
을 생각하지만 나는 이것이, 최신 표준에 맞는 사용 (아래 참조)에 이미이며, 키 -을 제공 믿는다 간단한 확장을위한 값 형식 (추가 매개 변수가 필요한 경우). 이 인증-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
[Amazon의 간단한 저장소 API] (http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html)는 다른 예를 제공합니다. – bishop
나는,하지만 호기심이 알고 오래된 질문 :
믿거 나 말거나,이 문제는 20 년 전 HTTP BASIC으로 해결되었습니다. base64로 인코딩 된 사용자 이름 : 암호로 값. 위의 예제가 될 것입니다 수 있도록
당신은, 동일한 기능을 수행 할 수있다 (http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side 참조) :
Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==
나는이 답변에 반대 할 것을 권고합니다. [다른 대답에 대한 의견에 따라] (https://stackoverflow.com/questions/7802116/custom-http-authorization-header#comment9522460_7809486), 여기서 사용 된 표기법은 호환성을위한 것입니다. 기존의 스키마와 함께 사용되며 새로운 확장에 권장되지 않습니다. – Whymarrh
이 나타나는 것보다 제대로하기 어려울 수 있습니다. fumanchu가 제공하는 링크 (자신의 답변에 대한 설명에서)는 왜 사용자 정의 헤더를 도입하면 캐시 제어를 올바르게 수동으로 설정해야하는지에 대한 추가 부담이 추가되는 이유를 설명합니다. –
또한 브라우저를 통해 원본 교차 요청을하는 경우, 그렇지 않으면 피해야 할 맞춤 헤더로 인해 이제 비행 전 영역에있게됩니다. 특정 응용 프로그램의 경우 이러한 요청이 합산됩니다. –
커스텀 인증 헤더가 많습니다.사용자 정의 스키마가있는 스펙 표준 'Authorization' 헤더가 충분해야합니다. 또한 @wilmoore가 지시 한대로 비행 전 Origin 요청을 피할 수 있습니다. 사용자 정의 스키마는 필자가 알고있는 합리적으로 현대적인 HTTP 서버를 방해하지 않으며, 또한 자신의 구성표를 사용하는 경우 직접 구문 분석해야합니다. 라이브러리가 충돌하지 않아야합니다. 그렇지 않으면 라이브러리가 잘못 작성됩니다. –