internet-explorer session cakephp cookies cakephp-1.3

internet explorer - CakePHP Cookie/problemas de sesión



internet-explorer session (4)

¿Se ha asegurado de no tener espacios ni nuevas líneas después de cerrar la etiqueta php?>? Quizás fue lo primero que comprobó, pero por experiencia, sé que las etiquetas php mal cerradas causan problemas esporádicos con el manejo de las sesiones de php.

Estoy teniendo problemas con mi aplicación CakePHP. Esto parece suceder solo en IE, y solo en ciertas computadoras. Sin embargo, es consistente en las computadoras donde está sucediendo.

Problema uno: el usuario ha iniciado sesión y en la página https://example.com/users/view y hace clic en cerrar sesión. El usuario se redirige a http://example.com y parece que se desconecta hasta que visita otra página https y todavía está conectado. Puede hacer clic en cerrar sesión tantas veces como lo desee, pero siempre está conectado en https y solo cerrar la sesión en http.

Problema dos: el usuario inicia sesión en https://example.com/users/signin y se redirige a http://example.com y ahora parece que ha iniciado sesión. El usuario va a https://example.com/admin/slides y aún no lo sabe, pero ahora está desconectado, al hacer clic en cualquier otra página (o simplemente actualizar su página actual) se les solicitará que inicien sesión nuevamente.

No tengo idea de lo que está pasando. He leído y probado las soluciones descritas en estos dos problemas similares: la sesión no se guarda al pasar de ssl a no-ssl y la cookie no se renueva / sobrescribe en IE, pero todavía tengo los mismos problemas.

La única pista que he notado hasta ahora (y no sé si esto significa algo) es cuando $_SESSION y $this->Session->read() en las páginas HTTP SIEMPRE solo $ this-> Session- > read () devuelve un valor. en las páginas HTTPS, algunos SIEMPRE devuelven el mismo valor para ambos, otros SIEMPRE solo devuelven un valor para $ this-> Session-> read ().

Por ejemplo, http://example.com y https://example.com/users nunca ve $ _SESSION, https://example.com/carts siempre ve $ _SESSION. No estoy seguro, pero estoy pensando que tal vez se supone que las páginas seguras deben estar viéndolo y ya que algunos no pueden, tal vez, algo esté mal, sin embargo, cuando inspecciono el código no veo ninguna diferencia que sugiera por qué uno lo hace y otro no t

Además, si agrego $this->Session->destroy() al antesFilter en AppController, entonces todas las páginas, incluso HTTP, pueden ver $ _SESSION. En realidad no uso $ _SESSION en mi aplicación, solo pensé que esto podría ser una pista de lo que está mal.

ACTUALIZAR

Seguí el consejo de Gustav Bertram y miré la cadena del agente de usuario. Comparé la cadena de agente de usuario con IE en una computadora que tenía el problema con IE en una computadora que no tenía el problema. Eran iguales, excepto que el que tenía problemas tiene "marco Google Chrome" en la cadena del agente de usuario. Desinstalé Google Chrome Frame de esa computadora, reinicié, lo intenté de nuevo y el problema parecía haberse resuelto.

Si esta es la verdadera causa, entonces la solución simple sería hacer que los usuarios desinstalen Chrome Frame. Sin embargo, me pregunto si hay una solución alternativa que les permita tener instalado Chrome Frame y seguir funcionando.


Intenta colocar esto en el filtro de aplicación de tu AppController y ver si hace algo. Tengo la sensación de que la configuración de las cookies no está configurada como usted necesita. Vea aquí para más información.

function beforeFilter() { $this->Cookie->domain = ''.example.com''; $this->Cookie->secure = false; }


Intente agregar lo siguiente a su archivo core.php:

Configure::write(''Session.checkAgent'', false); Configure::write(''Session.ini'',array(''session.cookie_secure'' => false, ''session.referer_check'' => false));

Estos parámetros deberían obligar a la cookie a persistir incluso a través de Google Chrome Frame. Esto establecerá la configuración de PHP y CakePHP para permitir que las cookies persistan en http y https.


Mi sugerencia es que eche un vistazo a los paquetes directamente, para ver qué está sucediendo con las cookies.

Instale Wireshark en su máquina cliente y conéctese a un servidor web remoto. (Wireshark ignorará el tráfico localhost).

Mi sospecha es que las cookies se están dañando (¡una vez tuve algunas cookies dañadas por PHP!) O están bloqueadas (lo que sería culpa de IE). De cualquier manera, tendrá más información sobre lo que está mal.

Como último recurso, verifique la cadena de usuario-agente en el código de la versión ofensiva / no compatible de IE, e inste a las personas a que realicen la actualización.