Rails - 部署后无效的真实性令牌 [英] Rails - Invalid Authenticity Token After Deploy

问题描述

我们正在使用EngineYard Cloud部署我们的Ruby on Rails应用程序。我们正在运行Rails v2.3.3。

We're using EngineYard Cloud to deploy our Ruby on Rails application. We are running Rails v2.3.3.

EngineYard Cloud以类似于Capistrano的方式部署到AWS实例。每次部署后，我们都会遇到无效的真实性令牌错误。具体来说，任何先前访问过我们的应用程序，然后在部署之后访问然后尝试提交表单的用户都将获得无效的真实性令牌错误。此错误仍然存​​在，直到他们重置其网站的Cookie。在他们重新设置他们的cookies之后，该网站按预期工作，没有任何错误。

EngineYard Cloud deploys to AWS instances in a manner similar to Capistrano. After each deploy, we're running into Invalid Authenticity Token errors. Specifically, any user that has previously visited our application and then visits after the deploy and then tries to submit a form gets an invalid authenticity token error. This error persists until they reset their cookies for the site. After they reset their cookies, the site works as expected with no errors.

我们正在使用ActiveRecord的会话存储，并将会话保存到数据库。

We are using ActiveRecord's session store and sessions are being saved to the database.

这是我们看到的错误：

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'

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'

部署后会话对象为零，但会话数据仍然存在于数据库中，会话ID Cookie仍然存在：

The session object is nil after the deploy, however, the session data still persists in the database and the session ID cookie still exists:

会话：

Session:

• 会话ID：nil


• data：nil

我们无法解释这一个。任何想法可能是根本原因？

We haven't been able to explain this one. Any thoughts on what could be the root cause?

感谢任何建议！

编辑：只是为了更新，我们已经能够隔离错误的一个例子。

Just to update on this, we've been able to isolate an example of the error.

1）用户加载表单
2）代码在服务器上更新
3）用户提交表单
**无效的真实性令牌错误发生

1) User loads form 2) Code is updated on server 3) User submits form ** Invalid Authenticity Token error occurs

看起来当环境变化我们已经尝试了几个步骤来解决：

It seems that when the environment changes, Rails is unable to handle this with the authenticity token.

>

重置会话

删除会话cookie（在JavaScript和Rails中）

擦除会话cookie部署代码后的数据库

• Resetting the session
• Deleting the session cookie (both in JavaScript and Rails)
• Wiping the session table in the database after deploying code

无效。唯一有用的是让用户清除他们的cookie客户端。

Nothing works. The only thing that works is having the user clear their cookies client-side.

（我们一直是谷歌（甚至尝试Binging！）的答案，但没有骰子。这似乎是一个类似的相关问题： http://railsforum.com/viewtopic.php?id= 21479 ）

(We've been Googling (even tried Binging!) for answers, but no dice. This seems to be a similar related issue: http://railsforum.com/viewtopic.php?id=21479)

另外：最初我们认为这是孤立的，我们部署到EngineYard，但是我们也能够在我们的开发服务器上重现它我们通过Capistrano部署。

Also: initially we thought this was isolated to our deployment to EngineYard, but we've also been able to reproduce it on our development server that we deploy to via Capistrano.

任何想法都将被感激地接受。

Any thoughts would be gratefully accepted.

谢谢！

推荐答案

ANSWER：在EngineYard进行广泛的工作后（他们很棒），他们能够诊断问题。这个问题的根本原因是杂种群集的错误。 Mongrel在启动后似乎没有看到第一个帖子请求。 EngineYard做了大量工作来诊断这个问题：

ANSWER: After extensive work by EngineYard (they're awesome!) they were able to diagnose the issue. The root cause of this issue is a bug with mongrel clusters. Mongrel doesn't seem to see the first post request after being started. EngineYard did extensive work to diagnose this:

您的代码中似乎没有任何内容导致问题，我们的环境也经历了这个错误（ http://www.thought-scope.com/2009/07/mongrelcluster-rails-23x-bad-post.html ）。我想很多人看不到它，因为对网站的第一个请求一般不是一个帖子，或者他们粉刺吸烟。

There doesn't appear to be anything in your code causing the issue and I have found people outside of our environment that have experienced the bug as well (http://www.thought-scope.com/2009/07/mongrelcluster-rails-23x-bad-post.html). I suppose a lot of people don't see it because the first request to a site generally isn't a post or they chalk it up to flukes.

[有使用CURL的潜在解决方案。]卷曲工作将对服务器上的每个mongrels执行一个简单的GET请求，以便他们说出来。您可以使用capistrano进行此操作，但如果通过仪表板进行部署，则无法正常工作。您可以在这里找到我们在基础架构中构建的部署钩子的一小段：
https://cloud-support.engineyard.com/faqs/overview/getting-started-with-engine-yard-cloud

[There is a potential workaround using CURL.] The curl work around would do a simple GET request to each of your mongrels on the server to prime them so to speak. You could do this with capistrano, but that won't work if you deploy via the dashboard. You can find a short section on deploy hooks we have built into the infrastructure here: https://cloud-support.engineyard.com/faqs/overview/getting-started-with-engine-yard-cloud

添加一个简单的运行卷曲 http：// localhost：500x > / dev / null应该工作（其中x是您当前设置中的5000-50005的端口。

Adding a simple run curl http://localhost:500x > /dev/null should work (where x is the port you have 5000-50005 on your current setup).

我们已经通过将我们的堆栈从Mongrel切换到乘客，但显然，Mongrel的修复是在作品中。希望这可以帮助看到同样奇怪问题的人。

We have addressed the issue by switching our stack from Mongrel to Passenger, but apparently, a fix for Mongrel is in the works. Hopefully, this helps someone who sees this same strange issue.

这篇关于Rails - 部署后无效的真实性令牌的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！