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 实例.每次部署后，我们都会遇到 Invalid Authenticity Token 错误.具体来说，任何以前访问过我们的应用程序然后在部署后访问然后尝试提交表单的用户都会收到无效的真实性令牌错误.此错误一直存在，直到他们为该站点重置 cookie.在他们重置 cookie 后，该网站按预期运行，没有任何错误.

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'

部署后会话对象为nil，但是会话数据仍然存在于数据库中，会话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:

会话:

• 会话 ID:无
• 数据:无

我们一直无法解释这一点.关于可能是根本原因的任何想法?

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) 用户提交表单** 发生 Invalid Authentity Token 错误

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

似乎当环境发生变化时，Rails 无法使用真实性令牌来处理.

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

我们尝试了几个步骤来解决:

We've tried several steps to resolve:

• 重置会话
• 删除会话 cookie(在 JavaScript 和 Rails 中)
• 部署代码后擦除数据库中的会话表

没有任何效果.唯一有效的是让用户在客户端清除他们的 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.

谢谢！

推荐答案

答案: 经过 EngineYard 的大量工作(他们太棒了！)，他们能够诊断问题.此问题的根本原因是杂种集群的错误.Mongrel 在启动后似乎没有看到第一个 post 请求.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 有一个潜在的解决方法.] curl 解决方法将对服务器上的每个杂种执行简单的 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

添加一个简单的运行 curl 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 切换到 Passenger 解决了这个问题，但显然，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屋！