Encabezado de Autorización HTTP Personalizado
Me preguntaba si es aceptable poner datos personalizados en un encabezado de autorización HTTP. Estamos diseñando una API RESTful y es posible que necesitemos una forma de especificar un método personalizado de autorización. Como ejemplo, vamos a llamarlo FIRE-TOKEN autenticación.
Sería algo como esto válido y permitido de acuerdo con la especificación: Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=
La primera parte de la segunda cadena (antes de ':') es la clave API, la segunda parte es un hash de la cadena de consulta.
4 answers
El formato definido en RFC2617 es credentials = auth-scheme #auth-param. Entonces, al estar de acuerdo con fumanchu, creo que el esquema de autorización corregido se vería como
Authorization: FIRE-TOKEN apikey="0PN5J17HBGZHT7JJ3X82", hash="frJIUN8DYpKDtOLCwo//yllqDzg="
Donde FIRE-TOKEN es el esquema y los dos pares clave-valor son los parámetros auth. Aunque creo que las citas son opcionales (del Apéndice B de p7-auth-19)...
auth-param = token BWS "=" BWS ( token / quoted-string )
Creo que esto se ajusta a los últimos estándares, ya está en uso (consulte a continuación) y proporciona un formato clave-valor para una extensión simple (si necesita más parámetros).
Algunos ejemplos de esta sintaxis auth-param se pueden ver aquí...
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
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-07-10 19:39:45
Póngalo en un encabezado personalizado separado.
Sobrecargar las cabeceras HTTP estándar probablemente causará más confusión de la que merece la pena, y violará el principio de menos sorpresa. También puede provocar problemas de interoperabilidad para los programadores de clientes de API que desean utilizar kits de herramientas estándar que solo pueden tratar con la forma estándar de encabezados HTTP típicos (como Authorization).
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-10-18 03:55:44
No, no es una producción válida según la definición de "credenciales" en RFC 2617. Usted da un esquema auth válido, pero los valores auth-param deben ser de la forma token "=" ( token | quoted-string ) (vea la sección 1.2), y su ejemplo no usa "=" de esa manera.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-10-18 15:08:05
Vieja pregunta que sé, pero para los curiosos:
Lo creas o no, este problema se resolvió hace ~2 décadas con HTTP BASIC, que pasa el valor como base64 codificado nombre de usuario:contraseña. (Véase http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side )
Usted podría hacer lo mismo, de modo que el ejemplo anterior se convertiría en:
Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-07-20 22:19:54