2012-06-12 4 views
5

Por lo tanto, me he encontrado con un problema un poco extraño, y espero que haya algunos sabios de IE que puedan arrojar algo de luz sobre este comportamiento. Mi empresa ejecuta una aplicación de elevación en tiempo real. Utilizamos el modelo de cometa para la comunicación en tiempo real entre los navegadores y el servidor, como es estándar con Lift. También vale la pena señalar: en caso de que los cometas no se sincronicen con el servidor (ya sea por problemas de conexión o reinicio del servidor, cualquier cosa que mate la sesión en el servidor) el servidor responde a esa solicitud de cometa con un document.location.reload(); para volver a cargar página, inicie una nueva sesión, y así sucesivamente.IE continúa ejecutando JS después de que se recibe un 302?

Ahora, para garantizar que los cierres de sesión sucedan como deberían, tenemos una url especial (/ sesión/cierre de sesión) que hace toda la limpieza relacionada con la sesión y luego te devuelve a nuestra página de inicio. Esto puede activarse haciendo clic en un delimitador a esa URL o el servidor puede emitir un 302 a esa URL si intenta hacer algo que requiera que se cierre la sesión. Lo suficientemente simple, ¿verdad? En la mayoría de los navegadores, esto funciona muy bien debido a que el flujo de trabajo es como la siguiente:

  1. usuario o bien hace clic en el botón de cierre de sesión o el servidor envía un 302 a/sesión/cierre de sesión
  2. la ejecución de Javascript en la página actual se detiene, por lo todos los cometas se cerraron.
  3. navegador carga/sesión/cierre de sesión
  4. navegador recibió 302 mensajes de servidor (que significa la limpieza de sesión se lleva a cabo) para poner al usuario a la página de inicio.
  5. El navegador carga la página de inicio.

Sin embargo, en el IE que estamos viendo el siguiente comportamiento:

  1. usuario o bien hace clic en el botón de cierre de sesión o el servidor envía un 302 a/sesión/cierre de sesión
  2. navegador empieza a cargar/sesión/cierre de sesión
  3. El navegador recibió 302 mensajes del servidor (lo que significa que la limpieza de la sesión está completa) para expulsar al usuario a la página de inicio.
  4. El navegador comienza a cargar la página de inicio.
  5. cometas reciben una document.location.reload(); desde el servidor, ya que nunca fueron cerradas por el IE, la carga de la página es abortado y la página actual se vuelve a cargar sin que el usuario se haya identificado.

Esto es totalmente indeseable porque necesitamos el resultado correcto de/session/logout para cargar - especialmente en situaciones en las que un usuario intentaba hacer algo que no podía hacer cuando iniciaba sesión (en ese caso, el 302 devuelto desde el cierre a donde originalmente estaban tratando de ir).

¿Alguien se ha encontrado con este tipo de problema anteriormente? ¿Algún consejo sobre cómo lidiar con este problema?

+0

¿Qué versión de IE? Modo estándar o no? – joshp

+0

IE 8 e IE 9, ambos ejecutados en modo estándar, muestran este comportamiento. –

Respuesta

0

No sé nada sobre el cometa, específicamente, pero deberías ser más explícito en el cierre del cometa.

Yo recomendaría capturar la ventana. Antes de descargar el evento y cerrar explícitamente el cometa en lugar de confiar en el navegador para hacer este trabajo por usted.

+0

Eso, desafortunadamente, no funciona.Parecería que debido a que el IE ha decidido que realmente no quiere ir a una página diferente, onBeforeUnload no se está llamando y todavía estoy viendo el comportamiento de recarga. :( –

Cuestiones relacionadas