Suprimir el cuadro de diálogo de autenticación del navegador

Question

Me disculpo porque ya hay una pregunta similar, pero me gustaría plantearla en términos más generales.

¿Hay alguna manera de determinar en el lado del cliente de una aplicación web si la solicitud de un recurso devolverá un código de estado 401 y hará que el navegador muestre un feo cuadro de diálogo de autenticación?

O, ¿hay alguna manera de cargar un recurso de audio mp3 en flash que falla de manera invisible en el caso de un código de estado 401 en lugar de dejar que el navegador muestre un diálogo feo?

El tiempo de ejecución de Adobe Air suprimirá la autenticación si configuro la propiedad "autenticar" del objeto URLRequest pero esta propiedad no está en el tiempo de ejecución de Flash. Cualquier solución que funcione en el cliente servirá. No es probable que una XMLHttpRequest funcione, ya que los recursos en las preguntas estarán en diferentes dominios.

Es importante fallar de manera invisible porque la aplicación tendrá una lista de muchos recursos de audio para probar y no tiene sentido molestar al usuario para intentar autenticarse para uno cuando haya muchos otros disponibles. Es importante que la solución funcione en el cliente porque los mp3 en cuestión provienen de varios servidores fuera de mi control.

Answer 1

Estoy teniendo el mismo problema con la API de Twitter: cualquier usuario protegido necesita que el cliente se autentique.

La única solución que se me ocurrió fue cargar las páginas en el servidor y devolver una lista de las URL con su código de respuesta http.

Answer 2

"¿Hay alguna manera de determinar en el lado del cliente de una aplicación web si la solicitud de un recurso devolverá un código de estado 401 y hará que el navegador muestre un feo cuadro de diálogo de autenticación?"

No, no en general. La respuesta 401 es la única forma estándar para que el servidor indique que la autenticación es necesaria.

Answer 3

Simplemente ajuste su acceso al recurso que podría requerir autenticación a una llamada Ajax. Puede capturar el código de respuesta y usar javascript para hacer lo que quiera (es decir, reproducir ese sonido). Si el código de respuesta está bien, entonces use javascript para reenviar al usuario al recurso.

Es muy probable que este enfoque genere un poco más de carga en el servidor (puede que tenga que recurrir a cargar el mismo recurso varias veces en algunas circunstancias), pero debería funcionar. Cualquier buen tutorial sobre cómo usar XMLHttpRequest debe contener todo lo que necesita. Eche un vistazo a, por ejemplo, http://www.xul.fr/en-xml-ajax.html

Answer 4

Si está utilizando URLRequest para obtener los archivos, entonces está ejecutando algo más que el elegante manejo de errores, se está encontrando con una diferencia fundamental en los tiempos de ejecución de Flash y AIR.

Si se utiliza el objeto URLRequest para recuperar archivos, se obtendrá un error de seguridad de Flash en cada solicitud a cada servidor que no haya establecido un archivo de política para permitir este tipo de solicitudes. AIR permite estas solicitudes ya que básicamente ES el cliente. Esto tiene sentido ya que es la diferencia entre instalar una aplicación y visitar una página web.

Odio proporcionar la falta de respuesta, pero si no puede hacer una llamada al lado del servidor, y está llegando a una gama de servidores "desconocidos", va a ser un camino difícil para azada.

Pero tal vez no lo entiendo, ¿está tratando de vincular a los archivos y evitar que el usuario obtenga enlaces defectuosos, o está tratando de cargar realmente los archivos?