Заголовок HTTP-авторизации

Question

Заголовок HTTP-авторизации

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

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

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

598 4

header rest http authorization

4 ответов:

Comments

Ничего не найдено.

StarTrekRedneck · Accepted Answer · 2012-07-10 22:39:45

формат, определенный в в документе rfc2617 и credentials = auth-scheme #auth-param. Итак, соглашаясь с fumanchu, я думаю, что исправленная схема авторизации будет выглядеть
Authorization: FIRE-TOKEN apikey="0PN5J17HBGZHT7JJ3X82", hash="frJIUN8DYpKDtOLCwo//yllqDzg="
здесь FIRE-TOKEN схема и две пары ключ-значение являются параметрами auth. Хотя я считаю, что цитаты являются необязательными (от 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

Brian Kelly · Accepted Answer · 2011-10-18 06:55:44

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

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

fumanchu · Accepted Answer · 2011-10-18 18:08:05

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

Mike Marcacci · Accepted Answer · 2015-07-21 01:19:54

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

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

вы могли бы сделать то же самое, так что пример выше станет:
Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==