Cómo evitar que Safari intercepte 401 respuestas a solicitudes ajax

Question

Tengo el siguiente problema en una extensión de Safari. Le pido al usuario que proporcione su nombre de usuario/contraseña para un servicio web y envíe una solicitud rápida para verificar que las credenciales sean correctas. Si no lo son, el servicio responderá con un 401 como creo que debería. El problema es que Safari parece interceptar esta respuesta antes de que mi código de JavaScript pueda manejarlo, mostrando el cuadro gris de inicio de sesión en lugar de dejarme manejar el error.

¿Hay algo que pueda hacer al respecto? Estoy usando una biblioteca js para hacer la llamada, pero es funcionalmente equivalente a la siguiente jQuery.

$.ajax({ 
    type: "GET", 
    url: url, 
    username: username, 
    password: password, 
    success: function() { /* handle success */ }, 
    error: function() { /* handle error */ } 
}); 

Answer 1

Por lo que yo soy consciente (después de haber tenido este problema yo mismo) no hay manera de que obtendrá Safari para detener interceptar un 401. Si esos hallazgos son correctos, la única forma es el uso creativo (leer: mal) de otro código de error, p. 403, o utilizando uno personalizado (ver a continuación).

Por supuesto, esto supone que tiene acceso a cambiar el código de estado enviado desde el servicio web (no está del todo claro si también desarrolló el servicio web).

403, por supuesto, dice "ya estás autenticado, pero no autorizado para acceder a este recurso", que no es correcto (de ahí el "uso indebido"), pero al menos no tiene efectos secundarios en los navegadores que Soy consciente de.

400 a veces se utiliza como una alternativa, pero desde ese ("solicitud incorrecta") significa un error del protocolo HTTP, puede causar efectos secundarios (nunca visto o escuchado que ocurra, pero potencialmente, podría provocar un intento demasiado útil por parte de algún futuro navegador o software anti-secuestro para iniciar la resolución de problemas/diagnósticos).

412 es otra alternativa que he visto aplicar ("Error de condición previa"), pero en realidad está destinado a indicar que el servidorno estuvo a la altura de las condiciones previas de la solicitud conjunto.

O podría hacer su propio error 4xx no estándar, por ejemplo. 461 - que está permitido (nótese que Twitter tiene un código de estado personalizado 420, por ejemplo)

Answer 2

Un enfoque más correcto sería seguir utilizando 401 como el código de error, pero no enviar la cabecera WWW-Authenticate cuando se han enviado las credenciales pero no fueron correctos.

Eso ya no dispara el diálogo del navegador y le permite procesar 401 directamente.