rails ruby-on-rails ruby deployment

ruby on rails - Rails-Token de autenticidad no válido después de la implementación



jwt rails (7)

¡Si solo estuviera allí para los mestizos! También obtengo el mismo error exacto en el pasajero (el usuario carga el formulario, implementa, envía -> el token de autenticidad no válido). ¿Sería interesante saber cómo resolvió el problema cambiando a pasajero? Cualquier otra sugerencia es muy bienvenida. Voy a echar un vistazo más de cerca también ...

¡Aclamaciones!

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

EngineYard Cloud se implementa en instancias de AWS de una manera similar a Capistrano. Después de cada implementación, nos encontramos con errores de token de autenticidad no válidos. Específicamente, cualquier usuario que haya visitado previamente nuestra aplicación y luego las visitas después de la implementación y luego intenta enviar un formulario recibe 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:in `Verify_authenticity_token ''

El objeto de la sesión es nulo después de la implementación, sin embargo, los datos de la sesión aún persisten en la base de datos y la cookie de ID de sesión todavía existe:

Sesión:

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

No hemos podido explicar esto. ¿Alguna idea sobre cuál podría ser la causa raíz?

Gracias por cualquier sugerencia!

EDITAR: Solo para actualizar esto, hemos podido aislar un ejemplo del error.

1) El usuario carga el formulario 2) El código se actualiza en el servidor 3) El usuario envía el formulario ** Se produce un error de token de autenticidad no válido

Parece que cuando el entorno cambia, Rails no puede manejar esto con el token de autenticidad.

Hemos intentado varios pasos para resolver:

  • Restablecer la sesión
  • Eliminar la cookie de sesión (tanto en JavaScript como en Rails)
  • Limpiando la tabla de sesiones 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 probamos Binging!) Para obtener respuestas, pero no dados. Este 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 podido reproducirlo en nuestro servidor de desarrollo que implementamos a través de Capistrano.

Cualquier pensamiento sería aceptado con gratitud.

¡Gracias!

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

Es una medida de seguridad para evitar que las 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 la aplicación agregando esto a config/environment.rb

config.action_controller.allow_forgery_protection = false

Puedes apagarlo con un solo controlador usando

skip_before_filter :verify_authenticity_token

o enciéndelo

protect_from_forgery :except => :index

revisa los documentos ActionController::RequestForgeryProtection::ClassMethods para más detalles

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

Sin embargo, la sugerencia de hacer una solicitud de obtención de un rizo en todos los mestizos después de que se reinicien parece funcionar, gracias a Dios que alguien descubrió esto porque parece ser bastante oscuro.

La única información adicional que puedo proporcionar es que estamos usando Apache mod_proxy_balancer junto con https frente a nuestros mestizos, sin embargo, este problema estaba ocurriendo antes de activar SSL. ¿Alguien está viendo esto con haproxy como el equilibrador en lugar de Apache?

Nunca he ido tan lejos para 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 almaceno mis sesiones (y, por lo tanto, mis datos de autorización), recibo este error de vez en cuando. Borrar los datos del navegador privado; Las cookies, las sesiones autenticadas, los trabajos, siempre me lo resolvieron.

Espero que esto ayude.

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

¿Tiene el parámetro de configuración config.action_controller.session configurado en cualquier lugar y, si lo hace, hay algo que pueda hacer que cambie cuando se config.action_controller.session ?

Una de mis aplicaciones la tiene configurada en config/environment.rb , y una más reciente (generada con Rails 2.3) la tiene configurada en config/initializers/session_store.rb . El escenario se ve como:

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

Si no tiene esto configurado por algún motivo, rake secret generará una clave para usted, que luego podrá insertar en su configuración.

(Si lo es, y sus procesos de implementación no lo están modificando, no tengo idea de lo que está pasando).

RESPUESTA: Después de un extenso trabajo de EngineYard (¡son increíbles!) Pudieron diagnosticar el problema. La causa raíz de este problema es un error con los clústeres mestizos. Mongrel no parece ver la primera solicitud de publicación después de haber comenzado. EngineYard realizó un extenso trabajo para diagnosticar esto:

Parece que no hay nada en su código que cause el problema y he encontrado personas fuera de nuestro entorno que también han experimentado el error ( 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 la atribuyen a la gente.

[Hay una solución alternativa posible utilizando CURL]. La solución de curl alrededor haría una simple solicitud GET para cada uno de sus mestizos en el servidor para prepararlos por así decirlo. Podría hacer esto con capistrano, pero eso no funcionará si lo implementa a través del panel de control. Puede encontrar una sección corta sobre los ganchos de implementación que hemos incorporado en la infraestructura aquí: https://cloud-support.engineyard.com/faqs/overview/getting-started-with-engine-yard-cloud

La adición de un curl de ejecución simple http://localhost:500x > / dev / null debería funcionar (donde x es el puerto que tiene 5000-50005 en su configuración actual).

Hemos abordado el problema cambiando nuestra pila de Mongrel a Pasajero, pero aparentemente, hay una solución para Mongrel en las obras. Con suerte, esto ayuda a alguien que ve este mismo problema extraño.