¿Debo devolver un código de estado http 401 en un formulario de inicio de sesión basado en html?

¿Debo devolver un código de estado http 401 en un formulario de inicio de sesión basado en html? La página es un formulario de inicio de sesión dedicado y no tiene ningún otro contenido significativo, solo el marco del sitio. Sin embargo, la URL puede ser para una página que tiene contenido significativo, pero requiere inicio de sesión. Tenga en cuenta que esta configuración solo devuelve el código de estado 401 y no solicita al usuario la autenticación básica.

Mirando los estándares, parece que 401 es un código de estado inapropiado para formularios de inicio de sesión basados ​​en HTML. Sin embargo, nunca he experimentado ni oído hablar de ninguna consecuencia negativa de hacerlo.

Al enviar 401, "La respuesta DEBE incluir un campo de encabezado WWW-Authenticate (sección 14.47) que contenga un desafío aplicable al recurso solicitado".

requisito mencionado aquí:

http://tools.ietf.org/html/rfc2616#section-10.4.2

detallado aquí:

http://tools.ietf.org/html/rfc2617#section-3.2.1

Sé que hay formas de evitar los motores de búsqueda para convencerlos de que indexen o no páginas basadas en la presencia de un formulario de inicio de sesión, pero preferiría usar códigos de estado http, específicamente 401, ya que su definición parece ser una combinación perfecta si no fuera por el requisito de encabezado WWW-Authenticate.

¿Hay alguna razón por la que no debería usar 401 en este caso? Semánticamente, ¿hay alguna diferencia entre no estar autorizado a nivel http y estar autorizado a nivel de aplicación? Obviamente puede tener ambas, pero ¿no es la autenticación a nivel http solo por la facilidad de no implementarla a nivel de aplicación?

Como observa, RFC 2616 requiere que una respuesta 401 esté acompañada de un encabezado RFC 2617 WWW-Authenticate. Supongo que técnicamente podría cumplir con ese requisito enviando un encabezado falso como:

WWW-Authenticate: Bogus realm="blahblah", comment="use form to log in"

pero no tengo idea de qué harán los navegadores si se les presenta una respuesta 401 que no contiene desafíos que entiendan. Me gustaría suponer que la mayoría si no todos ellos podrían presentar el cuerpo de la petición al usuario (como RFC 2616 dice que deben hacer si falla la autenticación), pero tampoco RFC parece decirlo explícitamente, por lo que podrían legítimamente acaba de mostrar un mensaje de error genérico en lugar.

Una alternativa posible (si no desea usar una respuesta 200 como parece que hacen todos los demás) sería usar un código de estado Prohibido 403 . Este es un código de respuesta ampliamente utilizado, y que yo sepa, casi todos los agentes de usuario interactivos (es decir, los navegadores, en lugar de, por ejemplo, los motores de búsqueda o los administradores de descargas) deberían reaccionar presentando el contenido al usuario, al menos si es lo suficientemente largo .

Aunque la descripción del código de estado 403 dice que "[una] autorización no será de ayuda", esto debería entenderse en mi contexto como referencia a la autenticación RFC 2617 o mecanismos similares de autorización a nivel de protocolo; en lo que respecta al navegador, no tiene idea de si enviar un formulario y recibir una cookie en respuesta cuenta como "autorización" o algo más.

Un mecanismo más comúnmente utilizado sería responder a solicitudes no autenticadas con una redirección temporal a una página de inicio de sesión separada, con la URL original pasada como parámetro para que el usuario pueda ser redirigido nuevamente después de una autenticación exitosa. Sin embargo, tenga en cuenta que una implementación ingenua podría permitir que una persona malintencionada cree un enlace de inicio de sesión que redirija al usuario a una URL arbitraria después de iniciar sesión. Si esto podría ser un problema de seguridad, debe tomar medidas para evitarlo, por ejemplo, al aceptar URL de retorno que coinciden con un patrón seguro conocido o protegiendo el URL de retorno con un código de autenticación de mensaje para evitar modificaciones

En cualquier caso, si está utilizando cookies HTTP para almacenar tokens de autenticación después de iniciar sesión, debe incluir un encabezado Vary en sus respuestas (tanto antes como después de la autenticación) para evitar el almacenamiento en caché inapropiado, como en Vary: Cookie.

Primero, si la página necesita iniciar sesión, entonces probablemente debería bloquearla mediante robots.txt

En segundo lugar, si los robots llegan a la página, es correcto un error 401.

probablemente, los códigos de estado pueden ser útiles para no humanos [y para algunos navegadores? ]

independientemente por el método de inicio de sesión, se debe enviar el encabezado correcto

por ejemplo, en el futuro, es posible que deba escribir un cliente de contenedor (no un navegador web) que simplemente se autenticará solo solicitando los encabezados de página, no la totalidad del código html

puede implementar su aplicación de inicio de sesión con ambos métodos usando la misma base de datos que la lista de usuarios