2012-07-20 16 views
5

Tenemos nuestra autenticación delegada en otro dominio (marco de identificación de ventana, configuración de autenticación federada). Ahora, si la sesión agotó el tiempo de espera antes de una solicitud ajax, el servidor redirige la solicitud al servidor de autenticación. Como se convierte en una llamada de dominio cruzado, el navegador cancela la solicitud ajax. ¿Hay alguna manera de detectar esto en jquery/javascript?detectar redireccionamientos de dominios cruzados en la solicitud de ajax

Inspeccioné la propiedad de estado del objeto xhr que se estableció en 0 en tal caso, pero ¿es un buen indicador para las solicitudes canceladas? (Estoy usando jQuery $ .ajax para hacer peticiones Ajax)

+0

¿Por qué hacer eso con el resultado si conoce la url que está solicitando? ¿No puedes simplemente comparar el dominio actual y la URL * antes * de que realices una solicitud ajax? – zerkms

+0

ya que su redirección a un dominio diferente en una solicitud de AJAX, no sé dónde buscar la URL, si jquery planteó un evento en la redirección, entonces sí, puedo agregar ese código allí. – Sush

+0

aquí hay otra manera en que puedo expresar el problema, a) hacer una solicitud AJAX a su dominio b) solicitar "puede obtener" redirigir a otro dominio basado en condiciones certian c) si redirigió, el navegador impide la solicitud y cancela (ya que es una llamada de dominio cruzado) c) se genera un evento de error ..Entonces, la pregunta es ¿cómo puedo detectar que la solicitud falló debido a una llamada de dominio cruzado? – Sush

Respuesta

4

He estado investigando esto, también, y he encontrado muy poca evidencia de que lo que quiere detectar es perfectamente detectable. Sin embargo, he encontrado una manera de detectar que probablemente sucedió.

Aquí es lo que sucede con su caso:

  1. El código JavaScript inicia la solicitud.
  2. El navegador realiza la solicitud al servidor.
  3. El servidor responde con un redireccionamiento.
  4. El navegador determina que la nueva ubicación es un dominio diferente.
  5. El navegador cancela la solicitud (para mantenerte a salvo).
  6. El navegador informa (no del todo cierto) que la solicitud nunca fue enviada.

En su devolución de llamada de error, revise el campo de XMLHttpRequest del objeto . Si es 0 ("INESTABLE"), significa que su solicitud AJAX nunca fue enviada.

Por supuesto, puede que no siempre sea completamente claro por qué no fue enviado. Por ejemplo, es posible que el usuario simplemente desenchufe su cable de red. Sin embargo, si está dispuesto a suponer que la red está funcionando perfectamente, entonces también puede ser razonable suponer, cuando vea readyState == 0, que la solicitud no se envió debido a preocupaciones entre dominios. Eso significa que el redireccionamiento sucedió.

Si está trabajando con jQuery, puede marcar jqXHR.readyState en su lugar.

+0

Solo para confirmar que no es completamente explícito anteriormente, ahora he probado esto y desafortunadamente el mismo readyState 0 también ocurre si el cable de red está desenchufado, y presumiblemente para otros errores de red. Esto significa que no puede distinguir entre un error de red y recibir una redirección. – sam

0

Puede consultar esta página: http://api.jquery.com/jQuery.ajax/

Hay un parámetro de error donde se puede coger si la petición falla.

error (jqXHR, textStatus, errorThrown)

Esperamos que esto ayude.

+0

Y ¿Cómo ayudará esto? – Starx

+0

Solo para aclarar su pregunta. Lo que quiere es verificar en su servidor de autenticación si la solicitud es de un jquery o JavaScript nativo? – jvicente

+0

@jvicente su sugerencia es similar a lo que estoy haciendo, estoy teniendo un controlador de error global (es decir, ajaxError (...) en lugar de controlador de error local. En caso de adjuntar un controlador de error local errorThrown parámetro contiene el valor "no encontrado" y textstatus tiene un valor de "error". Con esos valores no creo que asuma que la solicitud falló debido a que el navegador finalizó la solicitud. – Sush

Cuestiones relacionadas