Rails - Token de autenticidad no válido después de implementar

Question

Estamos utilizando EngineYard Cloud para implementar nuestra aplicación Ruby on Rails. Estamos ejecutando Rails v2.3.3.

EngineYard Cloud se implementa en las instancias de AWS de manera similar a Capistrano. Después de cada implementación, nos topamos con errores Token de autenticidad no válida. Específicamente, cualquier usuario que haya visitado nuestra aplicación previamente y luego visite después de la implementación y luego intente enviar un formulario obtiene un error de token de autenticidad no válido. Este error persiste hasta que restablecen sus cookies para el sitio. Después de restablecer sus cookies, el sitio funciona como se esperaba sin errores.

Estamos utilizando el almacén de sesiones de ActiveRecord y las sesiones se guardan en la base de datos.

Este es el error que estamos viendo:

ActionController :: InvalidAuthenticityToken /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.3/lib/action_controller/request_forgery_protection.rb: 79: en `verify_authenticity_token'

el objeto de sesión es nula después del despliegue, sin embargo, los datos de la sesión aún persiste en la base de datos y todavía existe la cookie de ID de sesión:

Sesión:

• ID de sesión: nil datos
• : cero

No han sido capaces de explicar esto. ¿Alguna idea sobre cuál podría ser la causa raíz?

¡Gracias por cualquier sugerencia!

---

EDIT: Para actualizar al respecto, hemos podido aislar un ejemplo del error.

1) El usuario carga forman 2) Código se actualiza en el servidor 3) El usuario envía forma ** se produce un error no válida autenticidad de emergencia

Parece que cuando el entorno cambia, Rails es incapaz de manejar esto con el token de autenticidad

Hemos probado varios pasos para resolver:

• Restablecimiento de la sesión
• Eliminación de la cookie de sesión (tanto en JavaScript y Pasamanos)
• se limpia la tabla de la sesión en la base de datos después de implementar el código

Nada funciona. Lo único que funciona es que el usuario borre sus cookies del lado del cliente.

(Hemos estado buscando en Google (¡incluso probé Binging!) Para obtener respuestas, pero no dados.Esto parece ser un problema relacionado similar: http://railsforum.com/viewtopic.php?id=21479)

También: inicialmente pensamos que esto estaba aislado de nuestra implementación en EngineYard, pero también hemos sido capaces de reproducirlo en nuestro servidor de desarrollo que implementamos a través de Capistrano.

Cualquier pensamiento sería aceptado con gratitud.

Gracias!

Answer 1

RESPUESTA: Después de un extenso trabajo realizado por EngineYard (¡son geniales!), Pudieron diagnosticar el problema. La causa principal de este problema es un error con los clústeres de mongrel. Mongrel no parece ver la primera solicitud de publicación después de haberse iniciado.EngineYard hizo un extenso trabajo para diagnosticar esta:

No parece haber nada en el código de la causa del problema y he encontrado que la gente fuera de nuestro entorno que han experimentado el fallo también (http://www.thought-scope.com/2009/07/mongrelcluster-rails-23x-bad-post.html). Supongo que mucha gente no lo ve porque la primera solicitud a un sitio generalmente no es una publicación o lo atribuyen a duelas.

[Existe una posible solución usando CURL.] El efecto de curvatura haría una simple solicitud GET a cada uno de sus mestizos en el servidor para prepararlos, por así decirlo. Puedes hacer esto con capistrano, pero eso no funcionará si lo haces a través del tablero. Se puede encontrar una breve sección sobre los ganchos de desplegar hemos construido en la infraestructura aquí: https://cloud-support.engineyard.com/faqs/overview/getting-started-with-engine-yard-cloud

Añadiendo un simple rizo plazo http://localhost:500x>/dev/null debería funcionar (donde x es el puerto que tiene 5.000 a 50.005 en su actual preparar).

Hemos solucionado el problema cambiando nuestra pila de Mongrel a Pasajero, pero aparentemente, se está preparando una solución para Mongrel. Con suerte, esto ayuda a alguien que ve este mismo problema extraño.

Answer 2

El token de autenticidad es un campo oculto en el formulario que rails comprueba cuando se envía el formulario para asegurarse de que los datos de la publicación provienen de una sesión en vivo.

Es allí como una medida de seguridad para evitar que personas malintencionadas utilicen un formulario enviado en su sitio para decir una acción de eliminación en la cuenta de alguien.

Puede desactivarlo en toda su aplicación mediante la adición de esto a config/environment.rb

config.action_controller.allow_forgery_protection = false 

Puede apagarlo un solo controlador utilizando

skip_before_filter :verify_authenticity_token 

o encenderlo

protect_from_forgery :except => :index 

echa un vistazo a los documentos ActionController::RequestForgeryProtection::ClassMethods para más detalles

Answer 3

Parece que la clave secreta utilizada para la autenticación está cambiando cuando se vuelve a implementar, invalidando todas las sesiones existentes.

Tiene el parámetro de configuración config.action_controller.session establecido en cualquier lugar, y si lo hace, ¿hay algo que pueda causar que cambie cuando vuelva a desplegar?

Una de mis aplicaciones tiene configurada en config/environment.rb, y una más reciente (generada con Rails 2.3) la ha configurado en config/initializers/session_store.rb. El ajuste se parece a:

config.action_controller.session = { 
    :secret  => 'long-string-of-hex-digits' 
    } 

Si no tiene esta configurado por alguna razón, rake secret generará una clave para usted, que luego se puede insertar en su configuración.

(Si es — y que no está siendo cambiada por la implementación de procesos — entonces no tengo idea de lo que está pasando.)

Answer 4

nunca he ido a cualquier longitud de averiguar los detalles, pero para mí , este es un problema de corrupción de datos del lado del cliente. Si he estado jugando con la forma en que almacena mis sesiones (y por lo tanto, mis detalles de autorización), recibo este error de vez en cuando. Limpiando los datos privados del navegador; las cookies, las sesiones autenticadas, las obras, siempre las resolvió para mí.

Espero que esto ayude.

Answer 5

¡Si solo estuviera disponible para chuchos! Obtengo exactamente el mismo error en el pasajero (el usuario carga formulario, implementa, envía -> token de autenticidad no válida). Sería interesante saber cómo resolvió el problema cambiando a pasajero? Cualquier sugerencia adicional es muy bienvenida. Voy a echar un vistazo más de cerca también ...

¡Salud!

Answer 6

Han encontrado este mismo problema con Rails 2.3 y un clúster Mongrel donde el secreto de la sesión se establece definitivamente en el inicializador de la sesión. El problema ocurrió incluso después de borrar las cookies del cliente en el cliente.

Sin embargo, la sugerencia de hacer una solicitud de curl para todos los perros grises después de que se reinicien parece funcionar - gracias a Dios que alguien lo descubrió porque parece ser bastante oscuro.

La única información añadida que puedo proporcionar estamos utilizando Apache mod_proxy_balancer junto con https en frente de nuestros Mongrels, sin embargo, este problema se produjo antes de activar SSL. ¿Alguien está viendo esto con haproxy como equilibrador en lugar de Apache?

Answer 7

Esta resolvieron este problema para mí :-) :-) :-)

https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/4690-mongrel-doesnt-work-with-rails-238#ticket-4690-37 Publicado por Mike Betania de agosto de 30mo 2010 @ 18:43.