¿Corregir el código de estado HTTP para el formulario de inicio de sesión?

Question

Estoy implementando la autenticación para una aplicación, y estoy usando un sistema conectable con "métodos de autenticación". Esto me permite implementar autenticación tanto HTTP básica como basada en HTML.

Con autenticación HTTP Básico/Digest el servidor envía un encabezado de respuesta 401 Unauthorized. Sin embargo, de acuerdo con la HTTP/1.1 RFC:

la respuesta debe incluir un campo de cabecera WWW-Authenticate (sección 14.47) que contiene un desafío aplicable al recurso solicitado.

Ya que no conozco ningún cabecera WWW-Authenticate "html", el envío de un 401 con un formulario de acceso HTML parece inadecuado. ¿Hay alguna alternativa a esto? Quiero diseñar mi aplicación de una manera RESTful.

¿Cuál es el código de estado HTTP correcto (y los encabezados) para un formulario de inicio de sesión basado en HTML? ¿Y cuál es el código correcto cuando falla el inicio de sesión?

Nota: No estoy interesado en Autenticación implícita.

Answer 1

Para HTML Creo que se debe responder con un 400.

Esto puede ser cierto para las solicitudes que no sean HTML, así, ya que 401 es por lo que yo entiendo que es más diseñado para responder a una petición de contenido que requiere autenticación, no para responder a una solicitud de autenticación.

El HTML no siempre permite el uso puro de las API RESTful, por lo que está bien cortar las esquinas aquí y allá, pero tal vez hay una mejor manera que no estoy viendo en este caso particular.

Answer 2

Esta es una pregunta engañosa, en gran parte porque los clientes HTTP mejor establecidos que utilizan las personas son los navegadores. De acuerdo con el RFC, el encabezado WWW-Authenticate puede contener cualquier cosa. La autenticación básica y resumida son solo dos ejemplos de mecanismos de desafío/respuesta estandarizados adicionales. Simplemente puede especificar un desafío como html-form id=foo y devolver el 401 junto con un formulario HTML. Además, recuerde de la especificación que se pueden especificar múltiples desafíos dentro del mismo encabezado WWW-Authenticate, pero no tengo ninguna experiencia probando extensamente los navegadores con diferentes esquemas.

Answer 3

@ 17/02/2016 Actualizado

El estado login form http debe ser 200 OK.

El estado de error http mejor uso 401 Unauthorized. (El nombre puede confundir, 401 es acerca de la autenticación. RFC7235

3,1. 401 no autorizado

El (no autorizado código de estado 401) indica que la solicitud no ha ha aplicado porque carece de las credenciales de autenticación válidas para el recurso de destino. El servidor que genera una respuesta 401 DEBE enviar un campo de encabezado WWW-Authenticate (Sección 4.1) que contenga al menos un desafío aplicable al recurso de destino.

Si la solicitud incluye credenciales de autenticación, la respuesta 401 indica que se ha rechazado la autorización de esas credenciales. El agente de usuario PUEDE repetir la solicitud con un campo de encabezado de Autorización nuevo o sustituido (Sección 4.2). Si la respuesta 401 contiene el mismo desafío que la respuesta anterior, y el agente de usuario ya ha intentado la autenticación al menos una vez, entonces el agente de usuario DEBERÍA presentar la representación adjunta al usuario, ya que generalmente contiene información de diagnóstico relevante.

Si desea manejar si no tiene permiso correcto, es posible que necesite 403 Forbidden [RFC7231]

HTTP 422 se utiliza para WebDAV, pero el significado puede adaptarse a las necesidades. (No se sugiere para la mayoría de los casos)

Para obtener más información, consulte el comentario de Cássio Mazzochi Molin a continuación.

---

@ 12/02/2016 Actualizado(Esta es la referencia a la respuesta aceptada.)

El estado login form http debe ser 200.

El estado http error mejor uso 400.

HTTP 422 se utiliza para WebDAV, pero el significado puede ajustarse a las necesidades. HTTP 401 es para autorización. Y no es adecuado para la autenticación.

---

@ 12/02/2016 original

HTTP 422 es ahora mejor opción con excepción de 400/401. HTTP 422 es una opción alternativa.

Porque significa que el servidor entiende los datos pero no es correcto para parte de los datos. es decir, puede mostrar al cliente que el nombre de usuario/contraseña es incorrecto.

11.2. 422 Entidad no procesable

El (Entidad no procesable) código de estado 422 significa que el servidor entiende el tipo de contenido de la entidad de solicitud (por lo tanto, un 415 (no admitido Tipo de soporte) código de estado es inapropiada), y la sintaxis de la solicitud la entidad es correcta (por lo tanto, un código de estado de 400 (Solicitud incorrecta) es inapropiado) pero no pudo procesar las instrucciones que figuran. Por ejemplo, esta condición de error puede ocurrir si un cuerpo de solicitud XML contiene instrucciones XML bien formadas (es decir, sintácticamente correctas), pero semánticamente erróneas.

RFC4918

Answer 4

Qué tal este?

Al solicitar el formulario de acceso que es una página pública, se obtiene lo que quiere, por lo que es un código de estado 200:

GET /login -> 200 

Al solicitar una página que necesita un nivel de autenticación HTTP que no lo hiciste t iniciado (http básica, certificado SSL, etc.), la aplicación debe decirle al navegador en sí que necesita para iniciar esta autenticación para usted:

GET /secured -> 401 with WWW-Authenticate header 

Cuando la autenticación es una sesión basada en cookies, que ya tiene una cookie (si no es el caso, obtendrá uno con el encabezado set-cookie al solicitar la página) pero esta cookie no indica que tiene permiso para acceder al uri /secured. Por lo tanto, si intenta acceder a este uri, debe obtener el estado "403 prohibido". Entonces la acción "conectarse" no es más que simplemente cambiar el estado de la aplicación con una solicitud POST para hacer que el acceso a la subvención solicitud de esta cookie, así que ...

Conectarse con malas credenciales:

GET /secured -> 403 with HTML login form (with action="/login") 
POST /login -> 403 with HTML login form, displaying errors 

Conectarse con buenas credenciales pero no suficientes permisos:

GET /secured -> 403 with HTML login form (with action="/login") 
POST /login -> 403 with HTML page saying "I know you are John, but you can't get this page" 

Conectarse con buenas credenciales y permisos suficientes:

GET /secured -> 403 with HTML login form (with action="/login") 
POST /login -> 302 (temporary redirection to /secured) 
GET /secured -> 200