¿Es posible utilizar la autenticación implícita con una solicitud XMLHTTP?

Tengo una pregunta simple: ¿Es posible usar la autenticación implícita con una solicitud XMLHTTP?¿Es posible utilizar la autenticación implícita con una solicitud XMLHTTP?

Si la respuesta es no, ¿cuál es el motivo técnico? O si es posible, ¿cómo puedo hacer eso?

Muchas gracias ... Google no tiene buena respuesta hasta el momento: -/

EDIT:

Gracias por las respuestas. La modificación del encabezado para que coincida con el esquema de autenticación resumida, después de que se recibió un nonce, parece ser una solución.

Pero lo que realmente estaba buscando era que podía cambiar mi llamada actual: xmlhttp.open ("GET", url, falso, nombre de usuario, contraseña); a sth. como ese xmlhttp.open ("GET", url, falso, nombre de usuario, contraseña, "DIGEST");

Eso también es parte de mi pregunta inicial: ¿Por qué el método abierto no ofrece la opción de hacer una solicitud de resumen?

Tal vez haya js-lib que podría recomendar que me permita hacer eso - como imagina que realmente no quiero cambiar el simple y simple xmlhttp.open a múltiples solicitudes y primero obtener un nonce.

Fuente

2011-08-23 user880625

¿Qué has intentado hasta ahora? Si su página de servidor requiere autenticación Digest (devolviendo un 401 a solicitudes no autenticadas), y pasa un nombre de usuario y contraseña a su llamada XHR open(), todo debería funcionar bien. – EricLaw

¿Lo has hecho? Realmente apreciaría un poco de código. ¡Gracias! – vrunoa

Puede hacerlo sin problema. Simplemente siga las partes de las especificaciones que desee;)
http://tools.ietf.org/html/rfc2617
y es todo lo que le falta para comenzar a escribir su biblioteca de autenticación
http://pajhome.org.uk/crypt/md5/
en el lado del cliente.

pre-cambio de nombre de usuario y contraseña
Hey, quiero para autenticar ----> servidor
autorización aquí es un cliente nonce/sal ---->
aquí es un hash MD5 suma de mi nombre de usuario password timestamp y the salt -----> servidor
Acabo de actualizar su contraseña y nombre de usuario de la misma manera que lo hizo y son el mismo -----> cliente
Esos son los conceptos básicos.

¡Olvidé que necesita incluir el URI del recurso solicitado en el hashsum!
Por supuesto, usted hace esto con cada solicitud que hace de un recurso para el servidor de esa manera alguien que intercepta el hash solo puede ver el contenido que ha solicitado y no puede solicitar un recurso misceláneo. Este método no protege los datos. solo acceda a ella.

Fuente

2011-08-23 10:41:22 Prospero

No estoy de acuerdo. Cualquiera puede pedir un nonce al servidor. ¿Cómo desea transportar de manera segura al lado del cliente? – Chielus

No es solo para que sea más difícil descifrar la contraseña del md5 y hacer que cada intento de autenticación sea único. http://en.wikipedia.org/wiki/Cryptographic_nonce. De esta forma, alguien no puede man en el medio hash y volver a autenticarse con él en otro momento. De hecho, usan un nonce en Oauth. Sé lo que estás pensando que todavía es totalmente inseguro, pero el objetivo de este tipo de autenticación es solo preservar tu nombre de usuario y contraseña. Es muy básico. – Prospero

:/¿Cuál fue el voto negativo? – Prospero

La mejor manera de hacerlo es mediante el uso de SSL. No creo que exista ninguna otra solución segura (corríjame si estoy equivocado)

Fuente

2011-08-23 11:03:00 Chielus

No está mal solo cauteloso;) – Prospero

¡El resumen es más seguro que Basic + SSL! Consulte RFC 2617, la sección de seguridad. – wprl

Sin SSL, un atacante de MitM (por ejemplo, proxy hostil o comprometido, por ejemplo, en un punto de acceso WiFi público) puede inyectar JavaScript arbitrario (o simplemente enlaces) al HTML. De esta forma, las solicitudes del atacante se originarán en el navegador de los usuarios, por lo que el servidor no tendrá la oportunidad de decir que no son del usuario. El atacante ni siquiera necesita descubrir la contraseña. – robert4

Echa un vistazo a este artículo: http://marcin-michalski.pl/2012/11/01/javascript-digest-authentication-restful-webservice-spring-security-javascript-ajax/. Explica cómo hacer el cliente de JavaScript para Autenticación implícita con SpringSecurity en el lado del servidor. El código está disponible en github: https://github.com/Arrowgroup/JSDigestAuth

Fuente

2012-11-02 09:08:02

Esta es la mejor respuesta. Apuntando a la publicación de alguien que ha hecho todo el trabajo y proporciona el código fuente completo (con una manera muy fácil de probarlo) –

He codificado un flujo de trabajo completo para esto, no es difícil en absoluto una vez que está utilizando una biblioteca externa para MD5 (yo uso Crypto-js).

El mayor problema que puede tener es que en el primer servidor 401 responda que cualquiera de los navegadores más usados abrirá un cuadro de diálogo para obtener sus credenciales.Por lo que he visto, no hay una manera fácil de eludir esto: How can I supress the browser's authentication dialog?

Para resolverlo, modifiqué el servidor web que codifiqué desde un proyecto Codeplex de C#. En la primera solicitud, el cliente pasa un encabezado de "Advertencia" que dice "No levante un 401". El servidor crea el desafío y lo envía de vuelta con una excepción HttpException no 401 personalizada (yo uso 406 por el momento, que es "no aceptable" en HTTP). El cliente crea el hash y lo envía de vuelta.

Puedo publicar algunos fragmentos de código si alguien está interesado, esta es una pregunta muy antigua.

Fuente

2012-12-17 13:25:59 malber

Esto no parece ser cierto para Safari, cuando recibe 401 en un XHR. – wprl

¿Qué quiere decir con "esto"? "this" = "¿el navegador abre un cuadro de diálogo también para XHR 401"? Si ese es el caso, no es necesario el truco del encabezado de advertencia. Las soluciones ampliamente compatibles aún requerirían una solución alternativa. – malber

¿Es posible utilizar la autenticación implícita con una solicitud XMLHTTP?

Respuesta

Cuestiones relacionadas