javascript - tag - ¿Cómo puedo suprimir el diálogo de autenticación del navegador?

title html w3schools

Question

Mi aplicación web tiene una página de inicio de sesión que envía credenciales de autenticación a través de una llamada AJAX. Si el usuario ingresa el nombre de usuario y contraseña correctos, todo está bien, pero si no, sucede lo siguiente:

1. El servidor web determina que, aunque la solicitud incluye un encabezado de Autorización bien formado, las credenciales en el encabezado no se autentican correctamente.
2. El servidor web devuelve un código de estado 401 e incluye uno o más encabezados WWW-Authenticate que enumeran los tipos de autenticación admitidos.
3. El navegador detecta que la respuesta a mi llamada en el objeto XMLHttpRequest es un 401 y la respuesta incluye encabezados WWW-Authenticate. A continuación, aparece un cuadro de diálogo de autenticación que solicita, una vez más, el nombre de usuario y la contraseña.

Todo está bien hasta el paso 3. No quiero que aparezca el diálogo, quiero manejar la respuesta 401 en mi función de devolución de llamada AJAX. (Por ejemplo, al mostrar un mensaje de error en la página de inicio de sesión.) Quiero que el usuario vuelva a ingresar su nombre de usuario y contraseña, por supuesto, pero quiero que vean mi amigable y seguro formulario de inicio de sesión, no el navegador feo, predeterminado diálogo de autenticación.

Dicho sea de paso, no tengo control sobre el servidor, por lo que tener que devolver un código de estado personalizado (es decir, algo que no sea un 401) no es una opción.

¿Hay alguna manera de que pueda suprimir el diálogo de autenticación? En particular, ¿puedo suprimir el cuadro de diálogo de Autenticación requerida en Firefox 2 o posterior? ¿Hay alguna manera de suprimir el cuadro de diálogo Conectar a [host] en IE 6 y posterior?

Editar
Información adicional del autor (18 de septiembre):
Debo añadir que el verdadero problema con el diálogo de autenticación del navegador que aparece es que no proporciona información suficiente para el usuario.

El usuario acaba de ingresar un nombre de usuario y contraseña a través del formulario en la página de inicio de sesión, cree que los ha escrito correctamente, y ha hecho clic en el botón Enviar o presiona enter. Su expectativa es que lo llevarán a la página siguiente o tal vez le digan que ingresó su información incorrectamente y que deberían volver a intentarlo. Sin embargo, se le presenta un cuadro de diálogo inesperado.

El diálogo no reconoce que haya ingresado un nombre de usuario y contraseña. No indica claramente que hubo un problema y que debería volver a intentarlo. En cambio, el cuadro de diálogo presenta al usuario información críptica como "El sitio dice: '' [reino] ''". Donde [reino] es un nombre de dominio corto que solo un programador podría amar.

Los diseñadores de web broswer toman nota: nadie preguntaría cómo suprimir el diálogo de autenticación si el diálogo en sí mismo fuera simplemente más fácil de usar. La razón por la que estoy haciendo un formulario de inicio de sesión es que nuestro equipo de administración de productos considera correctamente que los diálogos de autenticación de los navegadores son terribles.

Answer 1

¿Qué tecnología de servidor usa y hay algún producto en particular que use para la autenticación?

Dado que el navegador solo está haciendo su trabajo, creo que debe cambiar las cosas en el servidor para no devolver un código de estado 401. Esto se puede hacer utilizando formularios de autenticación personalizados que simplemente devuelven el formulario nuevamente cuando falla la autenticación.

Answer 2

El navegador muestra una solicitud de inicio de sesión cuando se cumplen las dos condiciones siguientes:

1. El estado HTTP es 4xx
2. WWW-Authenticate encabezado WWW-Authenticate está presente en la respuesta

Si puede controlar la respuesta HTTP, puede eliminar el encabezado WWW-Authenticate de la respuesta y el navegador no abrirá el cuadro de diálogo de inicio de sesión.

Si no puede controlar la respuesta, puede configurar un proxy para filtrar el encabezado WWW-Authenticate de la respuesta.

Por lo que sé (no dude en corregirme si estoy equivocado), no hay forma de evitar el mensaje de inicio de sesión una vez que el navegador recibe el encabezado WWW-Authenticate .

Answer 3

En Mozilla puede lograrlo con la siguiente secuencia de comandos cuando crea el objeto XMLHttpRequest:

xmlHttp=new XMLHttpRequest();
xmlHttp.mozBackgroundRequest = true;
xmlHttp.open("GET",URL,true,USERNAME,PASSWORD);
xmlHttp.send(null);

La 2da línea previene el cuadro de diálogo ....

Answer 4

En el terreno de Mozilla, establecer el parámetro mozBackgroundRequest de XMLHttpRequest ( docs ) en true suprime esos cuadros de diálogo y hace que las solicitudes simplemente fallen. Sin embargo, no sé qué tan buena es la compatibilidad entre navegadores (incluso si la calidad de la información de error en esas solicitudes fallidas es muy buena en todos los navegadores).

Answer 5

Estoy usando Node, Express & Passport y estaba luchando con el mismo problema. Lo hice funcionar al establecer explícitamente el encabezado www-authenticate en una cadena vacía. En mi caso, se veía así:

(err, req, res, next) => {
if (err) {
res._headers[''www-authenticate''] = ''''
return res.json(err)
}
}

¡Espero que ayude a alguien!

Answer 6

Me doy cuenta de que esta pregunta y sus respuestas son muy antiguas. Pero, terminé aquí. Quizás otros también lo harán.

Si tiene acceso al código para el servicio web que devuelve el 401. Simplemente cambie el servicio para devolver un 403 (Prohibido) en esta situación en lugar de 401. El navegador no solicitará las credenciales en respuesta a un 403. 403 es el código correcto para un usuario autenticado que no está autorizado para un recurso específico. Que parece ser la situación del OP.

Del documento de IETF en 403:

Un servidor que recibe credenciales válidas que no son adecuadas para obtener acceso debe responder con el código de estado 403 (Prohibido)

Answer 7

No creo que esto sea posible: si usa la implementación del cliente HTTP del navegador, siempre aparecerá ese diálogo. Dos piratas vienen a la mente:

1. Tal vez Flash maneja esto de manera diferente (no lo he intentado todavía), por lo que tener una película flash hace que la solicitud pueda ayudar.

2. Puede configurar un ''proxie'' para el servicio al que está accediendo en su propio servidor y hacer que modifique los encabezados de autenticación un poco, para que el navegador no los reconozca.

Answer 8

Para aquellos que usan C #, aquí está ActionAttribute que devuelve 400 lugar de 401 , y ''traga'' el diálogo de autenticación básica.

public class NoBasicAuthDialogAuthorizeAttribute : AuthorizeAttribute
{
protected override void HandleUnauthorizedRequest(AuthorizationContext filterContext)
{
base.HandleUnauthorizedRequest(filterContext);
filterContext.Result = new HttpStatusCodeResult(400);
}
}

utilizar como sigue:

[NoBasicAuthDialogAuthorize(Roles = "A-Team")]
public ActionResult CarType()
{
// your code goes here
}

Espero que esto te ahorre algo de tiempo.

Answer 9

Tengo este mismo problema con MVC 5 y VPN, donde cada vez que estamos fuera de la DMZ usando la VPN, nos encontramos teniendo que responder este mensaje del navegador. Usando .net simplemente manejo el enrutamiento del error usando

<customErrors defaultRedirect="~/Error" >
<error statusCode="401" redirect="~/Index"/>
</customErrors>

hasta ahora ha funcionado porque la acción Index bajo el controlador doméstico valida al usuario. La vista en esta acción, si el inicio de sesión no es exitoso, tiene controles de inicio de sesión que utilizo para iniciar sesión en el usuario usando la consulta LDAP pasada a Servicios de directorio:

 DirectoryEntry entry = new DirectoryEntry("LDAP://OurDomain");
DirectorySearcher Dsearch = new DirectorySearcher(entry);
Dsearch.Filter = "(SAMAccountName=" + UserID + ")";
Dsearch.PropertiesToLoad.Add("cn");

Si bien esto ha funcionado bien hasta el momento, y debo informarle que todavía estoy probándolo y que el código anterior no tiene motivos para ejecutarse, por lo que está sujeto a eliminación ... las pruebas actuales incluyen tratar de descubrir un caso en el que el segundo conjunto de código es de más uso. De nuevo, este es un trabajo en progreso, pero dado que podría ser de alguna ayuda o hacer trizas a tu cerebro para algunas ideas, decidí agregarlo ahora ... Lo actualizaré con los resultados finales una vez que se hayan realizado todas las pruebas.

Answer 10

jan.vdbergh tiene la verdad, si puedes cambiar el 401 en el lado del servidor por otro código de estado, el navegador no captará y pintará la ventana emergente. Otra solución podría ser cambiar el encabezado WWW-Authenticate para otro encabezado personalizado. No creo que el diferente navegador no pueda soportarlo, en algunas versiones de Firefox podemos hacer la solicitud xhr con mozBackgroundRequest, ¿pero en los otros navegadores? aquí, hay un link interesante con este tema en Chromium.

Answer 11

Encontré el mismo problema aquí, y el ingeniero de back-end de mi empresa implementó un comportamiento que aparentemente se considera una buena práctica: cuando una llamada a una URL devuelve un 401, si el cliente ha establecido el encabezado X-Requested-With: XMLHttpRequest , el servidor descarta el encabezado www-authenticate en su respuesta.

El efecto secundario es que la ventana emergente de autenticación predeterminada no aparece.

Asegúrese de que su llamada API tenga el encabezado X-Requested-With establecido en XMLHttpRequest . De ser así, no hay nada que hacer excepto cambiar el comportamiento del servidor de acuerdo con esta buena práctica ...