injector - http status 400

¿Qué código HTTP utilizar en los casos "No autenticado" y "No autorizado"? (4)

A menos que pretenda utilizar la autenticación HTTP, la respuesta correcta es 403 ("Prohibido").

Un código de respuesta de 401 hace que el navegador muestre un cuadro de diálogo de contraseña y luego vuelva a enviar la misma solicitud con un encabezado WWW-Authenticate con los datos de contraseña que el usuario proporcionó. Probablemente ese no sea el comportamiento que quieres.

No se preocupe demasiado por las explicaciones en los RFC: a lo que realmente debe prestar atención son los efectos secundarios del navegador y el motor de búsqueda de los distintos códigos de respuesta.

En cuanto al bit de "Authorization will not help" , en este caso es correcto, ya que el uso de la autorización HTTP (que específicamente significa el encabezado WWW-Authenticate ), de hecho, no servirá de nada.

Una respuesta 403 le dice al navegador que el usuario no tiene permiso para realizar esa solicitud, y que el navegador no debe intentar recopilar datos de autenticación y volver a enviar la solicitud. Esa es exactamente la respuesta que estás buscando.

Leí que el código "401 no autorizado" debe usarse cuando un usuario:

No está registrado, pero se requiere inicio de sesión ("no autenticado");
Está registrado, pero su perfil no permite ver esa URL ("no autorizado");

Según RFC, en ambos casos el servidor debe devolver el código 401 . Pero necesito diferenciarme entonces en mis peticiones ajax.

¿Alguien tiene un consejo para resolver esto?

Nota: No quiero usar el código 403 Forbidden , porque en 403 "Authorization will not help" , de acuerdo con RFC.

Creo que 403 es el correcto. Es posible que tengamos que ajustar el lenguaje en la especificación para que quede claro.

Debe pasar un encabezado personalizado además del código de estado para las necesidades específicas de la aplicación.

Creo que la práctica actual es prefaciar encabezados personalizados con X-

Actualización, agosto de 2012:

Del RFC 3864 publicado en los comentarios (con fecha de septiembre de 2004):

En algunos casos (especialmente HTTP [24]), la sintaxis y el uso del encabezado se redefinen para la aplicación específica. [...] En algunos casos, el mismo nombre de campo puede especificarse de manera diferente (por documentos diferentes) para usar con diferentes protocolos de aplicación. [...] Necesitamos acomodar campos específicos de la aplicación, mientras que deseamos reconocer y promover (cuando sea apropiado) características comunes de otros campos en múltiples aplicaciones.

En una RFC más reciente ( 6648 , fechada en junio de 2012), abordan específicamente los encabezados X-

Elimina la convención "X-" para los parámetros recién definidos en los protocolos de aplicación, incluidos los nuevos parámetros para los protocolos establecidos. [...] No recomienda contra la práctica de parámetros privados, locales, preliminares, experimentales o específicos de la implementación, solo contra el uso de "X-" y construcciones similares en los nombres de dichos parámetros.

Es importante tener en cuenta que, si bien X- se señala específicamente , aún así condonan implícitamente los encabezados personalizados como una forma de transferir información. Un prefijo específico de la aplicación ( MyApp- ) podría ser más apropiado para evitar chocar con otros encabezados.

Vea también: ¿Es seguro usar el encabezado "X-" en una respuesta HTTP de hace unos años?

IIS diferencia estos casos con códigos de sub-estado ( reference ):

401 = El usuario no ha iniciado sesión, pero se requiere inicio de sesión
401.1 = El usuario intentó iniciar sesión pero sus credenciales no son válidas.
401.3 = Las credenciales del usuario son válidas, pero el usuario no está autorizado para ver el recurso.