Rails - Invalid Authenticity Token After Deploy

Question

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

EngineYard Cloud deploys to AWS instances in a manner similar to

Answer 1

The authenticity token is a hidden field on the form that rails checks when the form is submitted to ensure that the post data is coming from a live session.

It is there as a security measure to prevent malicious people from using a form submit on their site to say a delete action on someones account.

You can turn it off on your whole app by adding this to config/environment.rb

config.action_controller.allow_forgery_protection = false

You can turn it off a single controller using

skip_before_filter :verify_authenticity_token

or turn it on

protect_from_forgery :except => :index

check out the ActionController::RequestForgeryProtection::ClassMethods docs for more details

Answer 2

I've never gone to any length to figure out the details, but for me, this is a client-side data rot issue. If I've been messing around with the way I store my sessions (and therefore, my authorization details,) I get this error from time to time. Clearing out the private browser data; cookies, authenticated sessions, the works, has always solved it for me.

Hope this helps.

Answer 3

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:

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.

[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

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).

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.

Answer 4

If it would only be there for mongrels! I'm getting the exact same error on passenger as well (user loads form, deploy, submit -> invalid authenticity token). It'd be interesting to know how you solved the issue by switching to passenger? Any further hints are highly welcome. I'll have a closer look as well...

Cheers!

Answer 5

It sounds like the secret key used for authentication is changing when you redeploy, invalidating all existing sessions.

Do you have the configuration parameter config.action_controller.session set anywhere, and if you do, is there anything which would cause it to change when you redeploy?

One of my apps has it configured in config/environment.rb, and a more recent one (generated with Rails 2.3) has it set in config/initializers/session_store.rb. The setting looks like:

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

If you don't have this configured for some reason, rake secret will generate a key for you, which can then be inserted into your configuration.

(If it is — and it's not being changed by your deployment processes — then I have no idea what's going on.)

Answer 6

Have encountered this same problem with Rails 2.3 and a Mongrel cluster where the session secret is definitely set in the session initializer. The problem occured even after clearing the client cookies on the client.

However the suggestion of doing a curl get request across all the mongrels after they restart appears to work - thank goodness someone figured this out because it appears to be pretty darned obscure.

The only added info I can supply we are using Apache mod_proxy_balancer along with https in front of our Mongrels, however this problem was occuring before we turned on SSL. Is anyone seeing this with haproxy as the balancer instead of Apache?