2011-01-21 13 views
16

Tengo una aplicación que está utilizando el dispositivo para la autenticación. Rieles 3 en ruby ​​1.9.2, con pasajero en la parte superior de nginx.Las sesiones se están cruzando. Ruby on Rails

Aquí está mi problema: he notado que ocasionalmente mis sesiones se están cruzando. Mientras estoy conectado como un usuario, a veces me convierto en otro usuario. Este es realmente un problema horrible. Logré hacer que se detuviera utilizando el almacenamiento de las sesiones de active_record. Pero estoy perplejo sobre dónde podría estar pasando. Sucede tanto cuando se usa el almacenamiento de cookies como el almacenamiento de memoria. No estoy seguro de dónde comenzar la depuración. He revisado todo mi código, y solo estoy leyendo de 'current_user' no escribiendo. No tengo ningún código que almacene elementos en sesión.

¿Alguien me puede dar sugerencias sobre dónde o cómo podría estar pasando esto?

Actualización:

I fijó un div en la parte superior de la página para volcar el contenido de la sesión en cada petición. No es solo el cambio de usuario, es toda la sesión. Hay algunas variables ficticias que configuré en la sesión solo para ver qué sucedería. Cuando se cruzan las sesiones, (el usuario A se convierte en el usuario B), el usuario A ahora ve las variables ficticias que tenía el usuario B. Y el usuario B ha cerrado la sesión.

ACTUALIZACIÓN 2

me encontré con otra pregunta aquí en desbordamiento de pila que describe exactamente el mismo problema: In Rails, what could cause a user to have another user's session?

Parece que podría ser un problema pasajero? Pero más importante, ¿cómo es que incluso está sucediendo? Este es un gran problema REAL. ¿Cómo pongo un alto a esto?

ACTUALIZACIÓN 3

ahora estoy utilizando Unicorn para servir a mi aplicación. Configuré config.threadsafe! y comenzó a usar sesiones de registro activo exclusivamente. No más sesiones de memcached. El problema se ha ido. Al menos puedo dejar de sacarme el pelo porque el agujero de seguridad está enchufado.

Todavía me gustaría saber exactamente qué lo está causando. La mayoría de los tutoriales muestran cómo configurar pasajeros, con el método de desove predeterminado. Naturalmente, creo que memcached funcionaría mejor para la gestión de sesiones que otros métodos. Especialmente en un entorno de servidor de aplicaciones múltiples.

Actualización 4

actualización Vale, la última y definitiva. Este era un problema con los procesos bifurcados que usan la misma conexión memcached. Lo arreglé usando el cliente memcached dalli y reiniciando la conexión en la devolución de llamada after_fork de unicornio o pasajero.

+0

¿Está utilizando los diferentes usuarios en el mismo navegador? ¿O es simplemente un otro usuario completamente aleatorio que no has usado recientemente? –

+0

No ha iniciado sesión con usuarios separados en el mismo navegador. Esto sucede incluso en redes separadas. El usuario A podría convertirse en el usuario B. Aunque se encuentren en ubicaciones separadas. Sucede al azar y lo único que he encontrado es que ambos tienen que iniciar sesión para que suceda. – demersus

+0

¿Es posible que se trate de un problema de pasajeros? ¿Diseña/guarda caché la variable current_user? – demersus

Respuesta

4

Estaría dispuesto a apostar que estás usando el desove inteligente (predeterminado) del Pasajero, y ser víctima del Spawning Gotcha.

Configure su PassengerSpawnMethod en 'conservador' y verifique si esto se soluciona. Esto explica fácilmente el caso de Memcache, a menos que esté protegiéndolo. Presumiblemente un problema similar en el diseño (o su código).

¿Ve que las sesiones se realizan en servidores físicos o solo en un servidor?

+0

Actualmente corro pasajero con el método de desove predeterminado en una máquina. La variable de sesión actual no se debe borrar correctamente entre las solicitudes. No me puedo imaginar, con la configuración predeterminada, esto no ha sido notado como un problema por otras personas. Probaré el método de generación conservador, pero este tipo de derrota algunos de los beneficios del uso de pasajeros. – demersus

+0

Si fuera realmente la variable de sesión, también afectaría a las sesiones de Activerecord, ¿verdad? Así que no creo que sea eso. Los problemas de Memcache como este se mencionan EXPLICITAMENTE en la documentación del pasajero (en ese caso), por lo que debe asegurarse de tenerlo cubierto, y si no, corrija y regrese a las sesiones de Memcache. ¿Puedes reproducir en un entorno de desarrollo? – user510365

+0

Este problema se suspendió temporalmente al usar las sesiones activerecord. Recientemente traté de usar Unicorn para servir la aplicación, y parece estar sucediendo con Unicorn también. – demersus

1

Es muy probable que este error pueda solucionarse actualizando a la memoria caché de bastidor 1.2 o superior. Esto es lo que podría estar pasando:

  1. El usuario A solicita una página. Se crea una sesión y se devuelve un encabezado Set-Cookie en la respuesta.
  2. en rack de caché almacena en caché incorrectamente la cabecera Set-Cookie con el ID de sesión de usuario A.
  3. usuario B solicita la misma página y en bastidor caché sirve la respuesta en caché, incluyendo la cabecera Set-Cookie con el ID de sesión A. usuario

Estos dos billetes de discutir este problema: https://github.com/rails/rails/issues/476 y https://github.com/rtomayko/rack-cache/pull/52

por último, este problema se menciona en las notas de la versión para rack caché 1.2: https://github.com/rtomayko/rack-cache/blob/master/CHANGES

También tenga en cuenta que, incluso cuando NO está utilizando el almacén de sesiones de cookies, la sesión ID todavía se almacena en una cookie, por lo que este error podría seguir mordiendo incluso cuando no esté utilizando el almacén de cookies.

Espero que esto ayude.

Johannes