index example auth autenticación http-headers xmlhttprequest

http-headers - example - header authorization token



HTTP 401: ¿cuál es el valor adecuado del encabezado WWW-Authenticate? (3)

La aplicación en la que estoy trabajando en este momento tiene un valor de tiempo de espera de la sesión. Si el usuario no ha interactuado durante más tiempo que este valor, la siguiente página que intenta cargar, se le pedirá que inicie sesión.

Todas las solicitudes realizadas se enrutan a través de este mecanismo, que incluye llamadas AJAX. Originalmente estábamos enviando un encabezado 200 con la página de inicio de sesión, que presenta algunos problemas con AJAX ya que el código se ejecuta si se envía una respuesta 200, y la mayoría de los datos enviados desde estas llamadas RPC es JSON o JavaScript sin procesar que se evalúa (no preguntar: |).

He sugerido que un 401 es mejor, ya que nuestro analizador JSON no intentará consumir una página de inicio de sesión HTML ... :)

Sin embargo, al leer la especificación , noté que el campo WWW-Authenticate también debe enviarse.

¿Cuál es un buen valor para este campo? ¿Será suficiente el Application Login ?

Cuando indicamos Autenticación básica HTTP, devolvemos algo como:

WWW-Authenticate: Basic realm="myRealm"

Mientras que Basic es el esquema y el resto depende mucho de ese esquema. En este caso, el dominio solo proporciona al navegador un literal que se puede mostrar al usuario cuando se solicita el ID de usuario y la contraseña.

Obviamente, no estás utilizando Basic, ya que no tiene sentido que expire la sesión cuando se utiliza Basic Auth. Supongo que estás utilizando algún tipo de autenticación basada en formularios.

Desde la recolección, Windows Challenge Response usa un esquema diferente y diferentes argumentos.

El truco es que depende del navegador determinar qué esquemas admite y cómo responde a ellos.

Mi instinto me dice que si está utilizando formularios basados ​​en la autenticación es quedarse con la página 200 + relogin pero agregar un encabezado personalizado que el navegador ignorará pero su AJAX puede identificar.

Para una experiencia realmente buena de Usuario + AJAX, obtenga la secuencia de comandos para aferrarse a la solicitud AJAX que encontró que la sesión expiró, inicie una solicitud de relogin a través de una ventana emergente y, si tiene éxito, vuelva a enviar la solicitud AJAX original y continúe normalmente.

Evite el truco que solo hace que el script acceda al sitio cada 5 minutos para mantener la sesión activa porque eso acaba con el vencimiento de la sesión.

La otra alternativa es grabar la solicitud AJAX, pero esa es una experiencia de usuario deficiente.

Cuando la sesión del usuario expira, le devuelvo un código de estado HTTP 204. Tenga en cuenta que el estado de HTTP 204 no contiene contenido. En el lado del cliente hago esto:

xhr.send(null); if (xhr.status == 204) Reload(); else dropdown.innerHTML = xhr.responseText;

Aquí está la función Reload ():

function Reload() { var oForm = document.createElement("form"); document.body.appendChild(oForm); oForm.submit(); }