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

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

Что-то вроде этого допустимо и разрешено в соответствии со спецификацией: Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=

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

Ответ 1

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

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

Где FIRE-TOKEN - это схема, и две пары ключ-значение являются параметрами auth. Хотя я считаю, что цитаты не являются обязательными (из Приложения B of 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

Ответ 2

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

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

Ответ 3

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

Ответ 4

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

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

Вы можете сделать то же самое, чтобы следующий пример:

Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==