2009-05-30 18 views
13

Estoy escribiendo algunas funcionalidades dinámicas del lado del navegador y utilizando HTTP Basic Auth para proteger algunos recursos. La experiencia del usuario es muy importante y está altamente personalizada.¿Cómo evito que Firefox solicite el nombre de usuario/contraseña con HTTP Basic Auth con JQuery AJAX?

Aquí es un método jQuery prueba sencilla que con el tiempo pondrá a prueba si un usuario ha suministrado las credenciales correctas en un formulario:

$(document).ready(function() { 
    $("#submit").click(function() { 
    var token = Base64.encode($('#username').val() + ':' + $('#password').val());   
    $.ajax({ 
     url: '/private', 
     method: 'GET', 
     async: false, 
     beforeSend: function(req) { 
     req.setRequestHeader('Authorization', 'test:password'); 
     }, 
     error: function(request, textStatus, error) { 
     if (request.status == 401) { 
      alert('401'); 
     } 
     } 
    }); 
    return false; 
    }); 
}); 

Si no se les permite acceder a la /private, en el momento en que no vean sólo la caja de alerta. Sin embargo, en Firefox, aparece un formulario de inicio de sesión provisto por el navegador (para volver a intentarlo con nuevas credenciales). Safari no hace esto.

Queremos controlar por completo la experiencia con formularios personalizados, fundidos, transiciones, etc. ¿Cómo puedo mantener el cuadro predeterminado de Firefox para que no se muestre? (. Si va a ser un problema cuando se prueba para IE, me gustaría saber las soluciones allí, también)

+1

Tenga en cuenta el seguimiento en http://stackoverflow.com/questions/928967/can-i-coerce-apache-into-not-including-a-www-authenticate-header-for-failed-http. –

Respuesta

3

Lamentablemente, estoy llegando al mismo problema aquí.

En mi opinión, los navegadores no deben dar un aviso para una xmlhttprequest. Realmente desearía que alguien insistiera porque la gente realmente está deseando pasar a jQuery por sus necesidades de autenticación.

Bueno, aquí está la ayuda que puedo darte, encontré esta cosa de jQuery Digest, no tengo idea de lo que realmente hace o de nada, pero si alguien pudiera tomar este código de la manera correcta, podríamos tener una autorización de resumen jquery sistema.

https://www.openhub.net/p/digestj

yo creo que con esta nueva opción útil AuthDigestDomain, podríamos tener el guión reescrito por encima o lo que sea y tener la zona de seguridad 'ligada' juntos y que podría superar este problema de una vez por todas. Bueno ... la mejor de las suertes =)

35

La solución es establecer el encabezado WWW-Authenticate a algo que no sea Basic. Por ejemplo configurarlo para: inicio de sesión basado

WWW-Authenticate: None 

o

WWW-Authenticate: FormBased 

si se utiliza la forma. Entonces, el navegador no le mostrará una ventana de inicio de sesión.

+1

Como se indica en el comentario de respuesta de la pregunta relacionada. El 'WWW-Authenticate' debe indicar uno (o más) desafío válido. Y creo que 'None' no es real. http://stackoverflow.com/questions/1748374/http-401-whats-an-appropriate-www-authenticate-header-value#comment-33722946 – mems

+1

Mire aquí para encontrar una solución sobre cómo solucionar esto con Java y ** Spring Security **: http://stackoverflow.com/questions/19079687/rest-call-on-expired-session-http-401-response-causes-browser-to-display-login/19102959#19102959 – lanoxx

+1

Es * la * solución, aunque parece irregular. https://www.ietf.org/rfc/rfc2617.txt (4.6) especifica múltiples esquemas, sin embargo, no se limita a Basic, Digest, etc.De modo que depende del cliente (navegador) admitir un esquema o no, si el esquema no es compatible, el navegador no interactúa con el usuario. Utilizo este enfoque para la recuperación transparente desde Windows SSO (SPNEGO) a un inicio de sesión de formulario simple. Por cierto: solo funciona de manera confiable en Chrome + IE al acceder al servidor a través del nombre de host; no use IPs – comeGetSome

Cuestiones relacionadas