En-tête d'autorisation HTTP personnalisé
Je me demandais s'il était acceptable de placer des données personnalisées dans un en-tête d'autorisation HTTP. Nous concevons une API RESTful et nous aurons peut-être besoin d'un moyen de spécifier une méthode d'autorisation personnalisée. Par exemple, appelons-le FIRE-TOKEN authentification.
Est-ce que quelque chose comme ceci serait valide et autorisé selon la spécification: Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=
La première partie de la deuxième chaîne (avant le ':') est la clé de l'API, la deuxième partie est un hachage de chaîne de requête.
Le format défini dans RFC2617 est credentials = auth-scheme #auth-param. Donc, en accord avec fumanchu, je pense que le régime d'autorisation corrigé ressemblerait à
Authorization: FIRE-TOKEN apikey="0PN5J17HBGZHT7JJ3X82", hash="frJIUN8DYpKDtOLCwo//yllqDzg="
Où FIRE-TOKEN est le schéma et les deux paires clé-valeur sont les paramètres auth. Bien que je crois que les citations sont facultatives (de l’annexe B de p7-auth-19) ...
auth-param = token BWS "=" BWS ( token / quoted-string )
Je crois que cela correspond aux dernières normes, est déjà utilisé (voir ci-dessous) et fournit un format clé-valeur pour une extension simple (si vous avez besoin de paramètres supplémentaires).
Quelques exemples de cette syntaxe auth-param peuvent être vus ici ...
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
Placez-le dans un en-tête personnalisé séparé.
Surcharger les en-têtes HTTP standard va probablement causer plus de confusion que cela ne vaudra et va enfreindre le principe de moindre surprise . Cela pourrait également entraîner des problèmes d'interopérabilité pour vos programmeurs clients d'API qui souhaitent utiliser des kits d'outils standards qui ne peuvent traiter que la forme standard des en-têtes HTTP classiques (tels que Authorization).
Non, ce n'est pas une production valide selon la définition de "credentials" dans RFC 2617 . Vous donnez un schéma d'authentification valide, mais les valeurs auth-param doivent être de la forme token "=" ( token | quoted-string ) (voir la section 1.2), et votre exemple n'utilise pas "=" de cette façon.
Vieille question que je connais, mais pour les curieux:
Croyez-le ou non, ce problème a été résolu il y a environ 2 décennies avec HTTP BASIC, qui transmet la valeur en tant que nom d'utilisateur codé en base64: mot de passe. (Voir http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side )
Vous pouvez faire la même chose pour que l'exemple ci-dessus devienne:
Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==