1. Inicio
  2. Pregunta y respuesta
  3. Encabezado de autorización HTTP personalizado

Encabezado de autorización HTTP personalizado

2011-10-18 27 views
111

Me preguntaba si es aceptable colocar 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 autenticación FIRE-TOKEN.Encabezado de autorización HTTP personalizado

¿Podría algo como esto sea válido y permitido según la especificación: Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=

La primera parte de la segunda cadena (antes de la ':') es la clave de la API, la segunda parte es un hash de la cadena de consulta .

Fuente

2011-10-18 NRaf

Respuesta

22

Colóquelo en un encabezado personalizado y separado.

La sobrecarga de los encabezados HTTP estándar probablemente cause más confusión de lo que vale y violará el principle of least surprise. También podría generar problemas de interoperabilidad para los programadores de cliente API que deseen utilizar kits de herramientas estándar que solo pueden tratar con la forma estándar de encabezados HTTP típicos (como Authorization).

Fuente

2011-10-18 03:55:44

+2

Esto puede ser más difícil de conseguir la derecha de lo que parece. El enlace que proporciona fumanchu (en un comentario a su respuesta) explica por qué la introducción de un encabezado personalizado agrega la carga adicional de tener que configurar manualmente el Control de caché correctamente. –

+3

Además, si realiza una solicitud de origen cruzado a través del navegador, ahora se encuentra en territorio de pre-vuelo solo por el encabezado personalizado donde de otra manera podría haberlo evitado. Para ciertas aplicaciones, estas solicitudes se suman. –

+17

Enorme no a los encabezados de autenticación personalizados.El encabezado de especificación 'Autorización' con su propio esquema personalizado debería ser más que suficiente. Además, evita las solicitudes de origen previas al vuelo como lo indica @wilmoore. Los esquemas personalizados no interfieren con ningún servidor HTTP razonablemente moderno que yo sepa, y si usa su propio esquema, tendrá que analizarlo usted mismo; ninguna biblioteca debería entrar en conflicto (de lo contrario, la biblioteca no está bien escrita). –

15

No, esa no es una producción válida de acuerdo con la definición de "credenciales" en RFC 2617. Usted otorga un esquema de autenticación válido, pero los valores de auth-param deben ser del tipo token "=" (token | quoted-string) (ver sección 1.2), y su ejemplo no usa "=" de esa manera.

Fuente

2011-10-18 15:08:05 fumanchu

+0

Eso no es correcto. Consulte la página 5 del documento para obtener un formato de ejemplo: Autorización: QWxhZGRpbjpvcGVuIHNlc2FtZQ == – NRaf

+10

básico. Es cierto. Pero como dice http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16#section-2.3.1, "La notación" b64token "se introdujo por compatibilidad con los esquemas de autenticación existentes y solo puede ser usado una vez por desafío/credenciales. Por lo tanto, los nuevos esquemas deberían usar la sintaxis "auth-param" porque de lo contrario las futuras extensiones serán imposibles ". Consulte también la discusión del caché en relación con hacer auth en encabezados personalizados. – fumanchu

115

El formato definido en RFC2617 es credentials = auth-scheme #auth-param. Por lo tanto, al acordar con fumanchu, creo que el régimen de autorización corregida se vería

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

Dónde FIRE-TOKEN es el esquema y los dos pares de valores clave son los parámetros de autenticación. Aunque creo que las comillas son opcionales (de Apéndice B de la p7-auth-19) ...

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

creo que esto se ajusta a las normas más recientes, ya está en uso (ver más abajo), y proporciona un número- formato de valor para la extensión simple (si necesita parámetros adicionales).

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

Fuente

2012-07-10 19:39:45 StarTrekRedneck

+2

[API de almacenamiento simple de Amazon] (http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html) ofrece otro ejemplo. – bishop

8

vieja pregunta lo sé, pero para los curiosos:

Lo creas o no, este problema se resolvió ~ hace 2 décadas con HTTP BASIC, que passe s el valor como nombre de usuario codificado en base64: contraseña. (Ver http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side)

Usted podría hacer lo mismo, por lo que el ejemplo anterior se convertiría en:

Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==

Fuente

2014-04-17 21:52:48

+1

Recomendaría esta respuesta, ya que, [por un comentario en otra respuesta aquí] (https://stackoverflow.com/questions/7802116/custom-http-authorization-header#comment9522460_7809486), la notación utilizada aquí es para compatibilidad con esquemas existentes y no se recomienda para nuevas extensiones. – Whymarrh

Cuestiones relacionadas

 Cuestiones relacionadas