Własny nagłówek autoryzacji HTTP

Zastanawiałem się, czy jest dopuszczalne umieszczanie niestandardowych danych w nagłówku autoryzacji HTTP. Projektujemy RESTful API i możemy potrzebować sposobu na określenie niestandardowej metody autoryzacji. Jako przykład, nazwijmy to uwierzytelnieniem FIRE-TOKEN.

Czy coś takiego jest ważne i dozwolone zgodnie ze specyfikacją: Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=

Pierwsza część drugiego łańcucha (przed':') jest kluczem API, druga część jest skrótem łańcucha zapytania.

Author: Marius Bancila, 2011-10-18
Source

4 answers

Format zdefiniowany w RFC2617 to credentials = auth-scheme #auth-param. Tak więc, zgadzając się z fumanchu, myślę, że poprawiony schemat autoryzacji wyglądałby jak 

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

Gdzie FIRE-TOKEN jest schematem, a dwie pary klucz-wartość są parametrami auth. Chociaż uważam, że cytaty są opcjonalne (z Apendix B z p7-auth-19)...

auth-param = token BWS "=" BWS ( token / quoted-string )

Wierzę, że to pasuje do najnowszych standardów, jest już w użyciu (patrz poniżej) i zapewnia format klucz-wartość dla prostego rozszerzenia (jeśli potrzebujesz dodatkowych parametry).

Kilka przykładów składni auth-param można zobaczyć tutaj...

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
Author: StarTrekRedneck,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-07-10 19:39:45

Umieść go w osobnym, niestandardowym nagłówku.

Przeciążenie standardowych nagłówków HTTP prawdopodobnie spowoduje więcej zamieszania niż jest to warte i będzie naruszać zasadę najmniejszego zaskoczenia . Może to również prowadzić do problemów z interoperacyjnością dla programistów klientów API, którzy chcą używać gotowych zestawów narzędzi, które mogą poradzić sobie tylko ze standardową formą typowych nagłówków HTTP(takich jak Authorization).

 21
Author: Brian Kelly,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-10-18 03:55:44

Nie, to nie jest poprawna produkcja zgodnie z definicją "poświadczeń" w RFC 2617 . Podajesz poprawny schemat auth, ale wartości auth-param muszą mieć postać token "=" ( token | quoted-string ) (patrz sekcja 1.2) , a twój przykład nie używa w ten sposób"=".

 15
Author: fumanchu,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-10-18 15:08:05

Stare pytanie wiem, ale dla ciekawskich:

Wierz lub nie, ten problem został rozwiązany ~20 lat temu z HTTP BASIC, który przekazuje wartość jako Base64 zakodowane username: password. (Patrz http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side )

Możesz zrobić to samo, aby powyższy przykład stał się: 

Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==
 8
Author: Mike Marcacci,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-07-20 22:19:54