Пользовательский заголовок авторизации HTTP

Question

Мне было интересно, допустимо ли помещать пользовательские данные в заголовок авторизации HTTP. Мы разрабатываем API-интерфейс RESTful, и нам может потребоваться указать собственный метод авторизации. В качестве примера назовем это FIRE-TOKEN аутентификация.

Будет ли что-то подобное действительным и разрешенным в соответствии со спецификацией: Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=

Первая часть второй строки (перед ':') - это ключ API, вторая часть - хеш строки запроса.

Answer 1

Формат, определенный в RFC2617 , равен credentials = auth-scheme #auth-param.Итак, соглашаясь с fumanchu, я думаю, что исправленная схема авторизации будет выглядеть так:

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

Где FIRE-TOKEN - схема, а две пары ключ-значение - параметры аутентификации.Хотя я полагаю, что цитаты являются необязательными (из Apendix B p7-auth-19) ...

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

Answer 2

Поместите его в отдельный пользовательский заголовок.

Перегрузка стандартных заголовков HTTP, вероятно, вызовет больше путаницы, чем стоит, и нарушит принцип наименьшего удивления . Это также может привести к проблемам с совместимостью для ваших клиентских программистов API, которые хотят использовать готовые наборы инструментов, которые могут работать только со стандартной формой типичных заголовков HTTP (например, Authorization).

Answer 3

Нет, это недопустимое производство в соответствии с определением «учетных данных» в RFC 2617 . Вы даете действительную схему аутентификации, но значения auth-param должны иметь форму token "=" ( token | quoted-string ) (см. Раздел 1.2), и ваш пример не использует "=" таким образом.

Answer 4

Старый вопрос я знаю, но для любопытных:

Верьте или нет, эта проблема была решена ~ 2 десятилетия назад с помощью HTTP BASIC, который передает значение в виде base64-кодированного имени пользователя: пароль. (См. http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side)

Вы можете сделать то же самое, чтобы приведенный выше пример стал:

Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==