it-swarm.com.de

Benutzerdefinierter HTTP-Autorisierungsheader

Ich habe mich gefragt, ob es akzeptabel ist, benutzerdefinierte Daten in einen HTTP-Autorisierungsheader einzufügen. Wir entwerfen eine RESTful-API und benötigen möglicherweise eine Möglichkeit, eine benutzerdefinierte Autorisierungsmethode anzugeben. Nennen wir es als Beispiel FIRE-TOKEN Authentifizierung.

Wäre so etwas gültig und erlaubt gemäß der Spezifikation: Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=

Der erste Teil der zweiten Zeichenfolge (vor dem ':') ist der API-Schlüssel, der zweite Teil ist ein Hash der Abfragezeichenfolge.

122
NRaf

Das in RFC2617 definierte Format ist credentials = auth-scheme #auth-param. In Übereinstimmung mit Fumanchu denke ich, dass das korrigierte Genehmigungsschema so aussehen würde

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

Woher FIRE-TOKEN ist das Schema und die beiden Schlüssel-Wert-Paare sind die Authentifizierungsparameter. Obwohl ich glaube, dass die Anführungszeichen optional sind (aus Anhang B von p7-auth-19) ...

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

Meiner Meinung nach entspricht dies den neuesten Standards, wird bereits verwendet (siehe unten) und bietet ein Schlüsselwertformat für die einfache Erweiterung (falls Sie zusätzliche Parameter benötigen).

Einige Beispiele für diese Auth-Param-Syntax finden Sie hier ...

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

129
StarTrekRedneck

Setzen Sie es in einen separaten, benutzerdefinierten Header.

Das Überladen der Standard-HTTP-Header wird wahrscheinlich mehr Verwirrung stiften als es wert ist und wird das Prinzip der geringsten Überraschung verletzen. Dies kann auch zu Interoperabilitätsproblemen für Ihre API-Client-Programmierer führen, die Standard-Toolkits verwenden möchten, die nur die Standardform typischer HTTP-Header (wie z. B. Authorization) unterstützen.

20
Brian Kelly

Nein, das ist keine gültige Produktion gemäß der Definition "Credentials" in RFC 2617 . Sie geben ein gültiges Auth-Schema an, aber Auth-Parameter-Werte müssen die Form token "=" ( token | quoted-string ) haben (siehe Abschnitt 1.2), und in Ihrem Beispiel wird "=" nicht verwendet.

15
fumanchu

Alte Frage, die ich kenne, aber für die Neugierigen:

Ob Sie es glauben oder nicht, dieses Problem wurde vor ~ 2 Jahrzehnten mit HTTP BASIC gelöst, das den Wert als base64-verschlüsselten Benutzernamen: Passwort übergibt. (Siehe http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side )

Sie könnten dasselbe tun, so dass das obige Beispiel wie folgt aussehen würde:

Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==
9
Mike Marcacci