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

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

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

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

117
authorization header http rest

4 ответов

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

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

124

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

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

21

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

15

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

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

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

Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==
8