¿Cuál es la mejor manera de usar la Autenticación HTTP en una aplicación Ajax que no es 100% AJAX?

jquery xmlhttprequest

Question

Tengo una página de inicio de sesión HTML estándar, que preferiría utilizar mucho más que la ventana emergente de autenticación HTTP estándar proporcionada por los navegadores. Hoy, estoy usando cookies de sesión para hacer un seguimiento de la sesión después de iniciar sesión, pero me gustaría ser apátrida y pasar la autenticación HTTP todo el tiempo. Los servicios web a los que estoy respondiendo ya son compatibles, por lo que este es un problema solo de navegador.

Agregar credenciales de autenticación es trivial en jQuery, pero no sé cómo mantenerlos. Si va desde la página de inicio de sesión (a jsp) a la página de inicio (otra jsp) claramente no conserva los campos de nombre de usuario y contraseña de la página de inicio de sesión. Sé que algunos navegadores almacenarán sus credenciales de autenticación HTTP si las ingresa desde la ventana emergente, pero no sé si se almacenan cuando usan una XHRRequest. Si lo hacen, ¿hay mucha consistencia entre los navegadores?

Además, el usuario debe ser capaz de "cerrar sesión" de la aplicación también. Si el navegador almacena las credenciales de autenticación, ¿hay alguna manera de borrarlas usando JavaScript?

Siento que no puedo ser la primera persona en intentar resolver esto. ¿Hay algún plugin jQuery o algo que ya maneje esto? ¿O simplemente no es posible hacer lo que estoy tratando de hacer?

Answer 1

Actualizar

La respuesta a continuación fue publicada en 2012 y los enlaces en su mayoría están muertos. Sin embargo, desde entonces, apareció un enfoque más elegante basado en estándares para la misma solución utilizando JSON Web Tokens . Aquí hay una buena publicación de blog que explica cómo usarlos.

La mayoría de las respuestas omiten el punto, que es evitar tener cualquier sesión en el servidor. No quiero ningún estado de aplicación en el servidor. Otorgaré la recompensa por la respuesta que estuvo más cerca, pero el verdadero mérito recae en el grupo de discusión de descanso y Jon Moore en la respuesta correcta y Mike Amundsen por ayudarme a entenderlo.

La mejor respuesta que he recibido es usar una cookie, pero no la típica cookie de identificación automática de sesión que te entregan la mayoría de los servidores de aplicaciones. La cookie (que se enviará automáticamente con cada solicitud posterior) es un identificador de usuario y una hora firmada por el servidor. Puede incluir un tiempo de caducidad con la cookie para que simule la sesión típica de 30 minutos en un servidor (lo que significa que debe seguir adelante con las solicitudes posteriores) y evitar que la misma cookie sea válida para siempre.

La parte XHR / AJAX es una pista falsa. Esto funcionará ya sea que esté haciendo solicitudes XHR o una aplicación web pasada de moda página por página. Los puntos principales son:

• La cookie se envía automáticamente en solicitudes posteriores, por lo que no se requieren scripts especiales, sino que ya funcionan los navegadores.
• El servidor no necesita almacenar ninguna sesión para el usuario, por lo que el usuario puede acceder a cualquier servidor en un clúster y no tener que volver a autenticarse.

Answer 2

De acuerdo, intentaré ayudar ...

En primer lugar, comprenda cómo funciona la autenticación HTTP. Hay dos versiones: Basic y Digest. Transmite básico en texto plano, el resumen está encriptado. Con estos tipos de autenticación, el nombre de usuario / contraseña se pasan en el encabezado HTTP con cada solicitud individual. El navegador los captura al iniciar sesión y se almacenan en una cookie inaccesible de la sesión del navegador que se elimina cuando se cierra la sesión del navegador. Entonces, en respuesta a una de sus preguntas, no puede acceder a estos desde javascript.

Puede crear sus propias variables de cookies de sesión para nombre de usuario y contraseña. Las funciones jQuery para esto son realmente simples. Vea el módulo jquery-cookie como un ejemplo de cómo configurar las cookies de sesión. Estos pueden recuperarse de la cookie de sesión y enviarse con cada solicitud ajax y validarse en el servidor. Sin embargo, esta no es una manera particularmente buena de hacer la autenticación, ya que olfatear la red permitirá que cualquiera pueda tomar fácilmente sus detalles de autenticación. Pero, funcionaría.

Usar la autenticación basada en cookies de sesión donde se envía el ID de sesión enviado con cada solicitud es la mejor manera de hacerlo. En el lado del servidor, necesita tener una función llamada para cada solicitud HTTP. Esta función debería hacer lo siguiente:

 check to see if the session has been authenticated
if no:
redirect to login screen
if yes:
do authorization and allow the user access to the page

La mayoría de los marcos web admiten la autenticación de cookies de sesión y la administración de identificadores de sesión en el servidor. Este es definitivamente el camino a seguir.

Answer 3

Esto es interesante.

Administrar sesiones de usuario en el servidor mediante el uso de cookies. Cree una sesión cuando el usuario acceda primero a la página de inicio de sesión y pase la identificación / clave de la sesión como valor a una de las cookies a través de la respuesta. Cuando el usuario es autenticado, ponga información de "clave" de usuario en la cookie y "valores" en el contexto de la aplicación en el servidor. Una vez que el usuario ha iniciado sesión, cualquier solicitud subsiguiente se autenticará en función del valor de la cookie de sesión en el servidor. La autorización se realizará en función de la "clave" del usuario pasada como valor de la cookie.

Al cerrar sesión, borre las cookies del servidor basadas en la sesión y actualice el sitio a la página predeterminada.

Las cookies son extrañas con diferentes navegadores, solo una nota;)

Espero que esto ayude.

Answer 4

Tienes 2 opciones:

1) Almacenamiento de credenciales del lado del cliente: no es una buena idea. Por razones obvias, no desea almacenar el nombre de usuario / contraseña en el cliente. Si tenía una versión hash de la contraseña, podría no ser tan mala, pero aún así no se recomienda. En cualquier caso, si va a almacenar en el lado del cliente, debe usar una cookie o almacenamiento local HTML5 (que aún no es ampliamente compatible)

2) Almacenamiento de credenciales del lado del servidor, generalmente hecho con sesiones. Luego, la ID de sesión resultante se puede pasar al cliente y persistir en una cookie o en la URL de cada llamada AJAX posterior ( ?SESSID=xyz por ejemplo)

El enfoque del lado del servidor sería el más seguro, confiable y fácil de implementar

Answer 5

Un poco interesante en que consideras empujar parte de la autenticación al cliente. Si desea una solución convencional, la sugerencia del lado del servidor de KOGI es el camino a seguir.

Pero también parece que hace preguntas sobre fugas de memoria que involucran los secretos proporcionados por el usuario. Buena pregunta. Pero para dar una respuesta general al responder, diría que debería ser específico del navegador. Es interno del navegador, motor interno de JavaScript -dependiente donde una aplicación del lado del cliente (es decir, el navegador, o js en el navegador) está almacenando los valores que el usuario ingresa.

Lo más probable es que esos valores no se repliquen innecesariamente a lo largo de la memoria, pero no hay forma de garantizar eso. Además de las prácticas de codificación de JavaScript responsable, no hay nada que pueda hacer para garantizar el límite de las ubicaciones de las entradas de los usuarios.

Leve digresión

El punto básico es que si lo almacena en el cliente no es realmente seguro, a menos que el servidor almacene información cifrada en el cliente con una clave que solo el servidor (o el usuario a través de sus credenciales correctas) tiene. Entonces, podría codificar una aplicación JS para hacer autenticaciones en el cliente, de forma similar a cómo la tarjeta bancaria (¿solía hacerlo?) Autentica el TPV al marcar el PIN en el PIN de la tarjeta y no en el DB. Se basa en la suposición (algo frágil) de que el usuario no tiene acceso directo de lectura / escritura de la cookie / almacenamiento local de "área oscura" en la tira de cliente / mag en la tarjeta bancaria. Así que solo aconsejaría esto como descalificador para los authents falsos y no como único calificador para las credenciales.

Punto principal

Si desea ser apátrida, solo almacene las credenciales de usuario en el almacenamiento local, o como una cookie, pero encriptelas con una clave de servidor. Cuando los necesite, envíe un XHR con las credenciales almacenadas encriptadas / usadas al servidor a través de HTTPS, permita que su servidor las descifre y las envíe a la devolución de llamada. Luego, pase esos texto sin formato de HTTPS para hacer su autenticación.