Rails - Invalid Authenticity Token After Deploy

Rails - Invalid Authenticity Token After Deploy

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.

How to solve invalid authenticity token error in Rails when sending form data from external page

Since this sounds like a separate app that you want to use to post data to a rails endpoint, you probably don't care about CSRF issues for the controller action that handles this. You could disable the authenticity token verification for your controller action with:

# inside your controller class
skip_before_action :verify_authenticity_token, only: [:your_wordpress_action]

Invalid Authencity Token after deploy

Where do you store your sessions? Deploying per se will not invalid sessions if the new code can reach the old sessions (e.g Cookie, DB or shared folder based sessions).

Only if you deploy with Capistrano/Webistrano and the sessions are stored in the actual release folder (not the shared folder), then the old sessions will be lost and users need to aquire new auth_token.

So, what you can do is try to preserve session data between deploys by using some kind of shared storage.

Invalid authenticity token when POSTing to a Rails API

2 Part answer for you here.

First if you are going to be using Rails as an API I would recommend you use another way of validating that the user making the request is actually the user they say they are such as creating a unique token upon account creation or login that can be returned in the initial response and provided as a HTTP header in subsequent requests. If you are worried about the security of this you could optionally base64 encode the key plus some other value and decode it server side before comparison.

If you still wish to use the CSRF method baked in to Rails you can do so as long as the user is making a request from the webapp using AJAX or whatever. If you have the csrf_meta_tags ERB in the header of your layout file you can get the value and set it in the X-CSRF-Token HTTP header. Using jQuery it may look something like:

$.ajaxPrefilter(function(options, originalOptions, xhr) {
  var token = $('meta[name="csrf-token"]').attr('content');
  if (token) xhr.setRequestHeader('X-CSRF-Token', token);  
});

This would cause it to be added to every ajax request made using jQuery.

Ruby 2.6.0 Invalid authenticity token

Looks like you are trying to do protect_from_forgery with config/application.rb

config.api_only = true

Here is your situation described

If you will use your app as API, you should regenerate it like

$ rails new my_api --api

And if you need more security, you can store your tokens in other places(not cookie or session) - for example you can use JWT Tokens.
For more security you can also use rack-cors gem
And if you accidently removed assets and dont want to use API, you can set this config to false

---

Related Topics