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 참조) 예제에서는 그런 식으로 “=”를 사용하지 않습니다.
답변
내가 아는 오래된 질문이지만 호기심 많은 사람들을 위해 :
믿거 나 말거나,이 문제는 base64로 인코딩 된 사용자 이름 : 암호로 값을 전달하는 HTTP BASIC을 사용하여 20 년 전에 해결되었습니다. ( http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side 참조 )
동일한 작업을 수행 할 수 있으므로 위의 예는 다음과 같습니다.
Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==
답변
