Devise: getting "Can't verify CSRF token authenticity" even if csrf toke in present

[rtcoms]

I'm doing simple authentication (without ajax or api) and getting error for csrf authenticity token. I'm using latest version of rails and devise

check the post request below

 Parameters: {"utf8"=>"✓",    
 "authenticity_token"=>"SJnGhXXUXjncnPhCdg3muV2GYCA8CX2LVFV78pqddD4=", "user"=> 
{"email"=>"[email protected]", "password"=>"[FILTERED]", "remember_me"=>"0"},
"commit"=>"Sign in"}

Can't verify CSRF token authenticity
 User Load (0.4ms)  SELECT "users".* FROM "users" WHERE "users"."email" =  
 '[email protected]' LIMIT 1
(0.1ms)  begin transaction
SQL (0.4ms)  UPDATE "users" SET "last_sign_in_at" = ?, "current_sign_in_at" = ?,
"sign_in_count" = ?, "updated_at" = ? WHERE "users"."id" = 2  [["last_sign_in_at", Fri,
08 Nov 2013 14:13:56 UTC +00:00], ["current_sign_in_at", Fri, 08 Nov 2013 14:18:49 UTC
+00:00], ["sign_in_count", 3], ["updated_at", Fri, 08 Nov 2013 14:18:49 UTC +00:00]]
(143.6ms)  commit transaction
Redirected to http://localhost:3000/
Completed 302 Found in 239ms (ActiveRecord: 144.5ms | Search: 0.0ms)

[josevalim]

Can you please provide a sample application that reproduces the error?

[rtcoms]

here it is: (keep in mind that there are lots of gem which are not required but mentioned in Gemfile . This rep, I just keep updating to latest gems)

https://github.com/rtcoms/railsstarter

[latortuga]

Your sample application is using an old version of devise. If you update it and are still seeing the error, we can take a look.

[rtcoms]

My bad. really sorry. I've updated the app with latest version of devise gem. Also added the devise secret key.

[kurko]

I'm having this exact same problem in my app, but only in production, not in development/test env. I narrowed it down to this line:

# config/initializers/session_store.rb
Store::Application.config.session_store :cookie_store, key: '_some_key', domain: :all, tld_length: 2

With this line, sessions aren't destroyed anymore either.

---

@rtcoms I wasn't able to reproduce this problem in your sample app, neither in development nor in production (RAILS_ENV=production bundle exec rails server). Could you list exactly what you're doing to make it fail?

[rtcoms]

@everyone problem in my app is fixed. It was not related to devise . I removed 'rails-api' gem and it started working.

@kurko I removed some gems from my Gemfile .Try to have minimum no of gems in Gemfile and add extra gems one by one to find out which gem is causing error.

From my side this issue can be closed.

[lethjakman]

I have the same exact issue as kurko. Did you ever find a solution to your problem?

[kurko]

Nope. I just disabled the feature for now, but I'll need it back soon. If you find the solution, please post it here.

[lethjakman]

Ok so I fixed my issue by changing the domain: to my domain name that I'm currently using. Turns out my dev domain didn't work with my production domain. I don't know if that'll help you but good luck!

[ctide]

This isn't Devise related, as I'm running into the same problem after upgrading to Rails 4 without using the Devise gem at all. Commenting out the ':domain => :all, :tld_length => 2' section 'fixes' it, but we need that. Will try and figure out what the actual issue is and create an issue against Rails for it.

[lethjakman]

I actually found a better solution is to specify your :domain to your
actual domain name. I ran into other weird CSRF issues with :domain => all.

On Wed, Feb 26, 2014 at 7:22 PM, Chris Burkhart [email protected]:

This isn't Devise related, as I'm running into the same problem after
upgrading to Rails 4 without using the Devise gem at all. Commenting out
the ':domain => :all, :tld_length => 2' section 'fixes' it, but we need
that. Will try and figure out what the actual issue is and create an issue
against Rails for it.

Reply to this email directly or view it on GitHubhttps://github.com/plataformatec/devise/issues/2734#issuecomment-36203407
.

[coorasse]

I have the same problem.

I tried removing domain: :all and I don't have ruby-api gem.

I can reproduce the bug easily with my browser in Incognito Mode but only in production.

After digging a bit I did not find any solution so I just discarded the protection from sign_in form

[eiked]

I had the same problem after switching to rails 4.

I store my session data in the database aka:
config.session_store :active_record_store

In my case the the session_id was not saved aka session_id=NULL

It was fixed by placing this in an initializer:
ActiveRecord::SessionStore::Session.attr_accessible :data, :session_id

(see https://github.com/rails/activerecord-session_store/issues/6)

[lethjakman]

I fixed this issue a few times by pulling down a fresh copy of my repo from
get and starting from there. Something weird seemed to have been getting
cached that I couldn't find. Perhaps that could help one of you.

On Thu, Apr 3, 2014 at 4:21 PM, Joshua Kidd [email protected]:

Yes... I too am having this same issue. I didn't have the rails-api gem, I
narrowed my gems down to just devise, and the problem only happens for some
browsers. In my chrome canary it will give error, in normal chrome it
works, in normal chrome incognito works, and in safari depending on what
computer I am on it will sometimes work or not work.

Reply to this email directly or view it on GitHubhttps://github.com/plataformatec/devise/issues/2734#issuecomment-39512319
.

[vanboom]

I am seeing the same thing... Can't verify CSRF token authenticity in my application using Devise 3.2.4.

It seems to happen randomly, but is fairly repeatable shortly after restarting Apache... my app is deployed using Passenger on Apache.

Has anyone found a definitive bug?

[coorasse]

I didn't identified the bug and I'm still waiting for an answer. In the
meantime I just disabled forgery_protection for devise login form.

Alessandro Rodi

On Fri, May 2, 2014 at 1:47 AM, Don [email protected] wrote:

I am seeing the same thing... Can't verify CSRF token authenticity in my
application using Devise 3.2.4.

It seems to happen randomly, but is fairly repeatable shortly after
restarting Apache... my app is deployed using Passenger on Apache.

Has anyone found a definitive bug?

—
Reply to this email directly or view it on GitHubhttps://github.com/plataformatec/devise/issues/2734#issuecomment-41969856
.

[ryanicle]

I am having the same issue as well. As @coorasse said, I disabled forgery_protection for now. Please share if anyone has found a fix. Thanks.

[coorasse]

Please reopen the issue or we'll have to create a duplicate

[josevalim]

Folks, can someone please provide a way to reproduce the issue? It can even be in a new issue, as long as we link to this one. But we need a way to reproduce this, without a way to reproduce it, there is nothing we can do about getting it fixed.

[eiked]

Hi Jose,

Did I report that?
Must not have been me.

~eike

Am 25.06.2014 um 16:08 schrieb José Valim [email protected]:

Folks, can someone please provide a way to reproduce the issue? It can even be in a new issue, as long as we link to this one. But we need a way to reproduce this, without a way to reproduce it, there is nothing we can do about getting it fixed.

—
Reply to this email directly or view it on GitHub.

[rience]

Just my 2c - my problem was that in session_store.rb I had

:secure => Rails.env.production?

and was not using SSL in production (still in development phase). So cookies were not sent => token was missing. Stupid mistake.

[Olgagr]

We had the same issue. In session_store.rb we had these settings:

Rails.application.config.session_store :cookie_store, key: "_eqipia_session", domain: :all

We need it because we use subdomains on our staging and production environments and some of services like Xing do not allows us to setup oAuth callback for many subdomains (no * allowed).

Our client reported that he can't log in into admin panel. Client has access to both environments. The logs errors:

Started POST "/admin/sign_in" for 89.68.139.73 at 2014-07-21 10:37:31 +0000
Completed 422 Unprocessable Entity in 5ms
Processing by Auth::SessionsController#create as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"NK1JAQUUAhm7Pi2aMdfepcOs6q90bi1Uqelq/Py6vi8=", "user"=>{"email"=>"[email protected]", "password"=>"[FILTERED]", "remember_me"=>"0"}}
Can't verify CSRF token authenticity
ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken):
vendor/bundle/ruby/2.1.0/gems/actionpack-4.1.1/lib/action_controller/metal/request_forgery_protection.rb:176:in `handle_unverified_request'
vendor/bundle/ruby/2.1.0/gems/actionpack-4.1.1/lib/action_controller/metal/request_forgery_protection.rb:202:in `handle_unverified_request'
vendor/bundle/ruby/2.1.0/gems/devise-3.2.4/lib/devise/controllers/helpers.rb:182:in `handle_unverified_request'

After some research we figured out that the problem was only present in Chrome. Looking into Resources in Chrome console, I noticed we have the same cookies (one from stage environment and other for production), but of course with different values. It happens because I first logged in to production and then opened new tab and try to log in to staging. With these two cookies, the errors occurs.

So in session_store.rb we change name for cookie into dynamic name:

Rails.application.config.session_store :cookie_store, key: "_eqipia_session_#{Rails.env}", domain: :all

This works, the cookies are not mixed up any more.

[locochris]

Yes, we had the same problem as @rience in our app.
ie. developing locally with RAILS_ENV=production, but with :secure => Rails.env.production? set in session_store.rb.
Next time if we want a more production-like version of our app running in a production environment we might try eg. ngrok-ing in over ssl.

[robinboening]

Had the same issue until adding an initializer that skips before action verify_authenticity_token.

@josevalim shouldn't this issue be opened again, or is it not related to devise?

[latortuga]

Disabling verify_authenticity_token is a dangerous fix - it is putting out a fire by vacuuming up smoke. Please don't disable CSRF protection for your app.

If you have CSRF enabled and you see an authenticity token in the request, check that you actually have a session token in your cookies. Devise has exhaustive tests of this functionality - it is unlikely to be a devise issue.

[robinboening]

@latortuga: its not skipped for all requests in the app, but for our UserSessionsController that inherits from Devise::SessionsController only.

There always is an authenticity token in the request, but for some strange reasons I can not explain it can not be verified and the session is empty. Looks like the user was logged in, but the session is not written because of the not verified token. After this first failing login attempt, the next login just works... I dunno, its always the first attempt that is failing - always directly after a logout.

[latortuga]

If the session is empty, obviously the token will not be verified - this is how CSRF protection in Rails works! Check if you're using httponly or secure flags for your sessions and that they match your desired configuration. If you watch your cookies when you visit the site and you don't see your app's session key (config/initializers/session_store.rb key config), then you don't have a token that can validate against the CSRF token server-side - this will cause the issue.

If you're not validating CSRF protection for login/logout, a malicious attacker could cause you to logout or login as someone else without your knowledge.

[talal7860]

This solved my problem

I overrode the devise sessions controller by creating a new file in controller/users/ with the name of sessions_controller.rb
class Users::SessionsController < Devise::SessionsController
skip_before_filter :verify_authenticity_token, :only => [:destroy]
end

[danielbonnell]

I've tried every solution on here to no avail. I am running Rails 4.2 and the latest version of Devise on Heroku. My issue only seems to occur in Firefox and the environment doesn't matter. It happens both in development, test, and production. I can get around it in testing by stubbing the user login, but I can't seem to get around it in the other environments.

I can't figure out what caused the issue in the first place. I had no problems logging in through Firefox as recently as a week ago. I haven't pushed any new code up to the production app recently.

[talal7860]

Make sure that your csrf tag are being displayed as it should in firefox,
this solved my problem, I accidentally deleted the csrf tags

On Sunday, April 5, 2015, Daniel Bonnell <[email protected]

I've tried every solution on here to no avail. I am running Rails 4.2 and
the latest version of Devise on Heroku. My issue only seems to occur in
Firefox and the environment doesn't matter. It happens both in development,
test, and production. I can get around it in testing by stubbing the user
login, but I can't seem to get around it in the other environments.

I can't figure out what caused the issue in the first place. I had no
problems logging in through Firefox as recently as a week ago. I haven't
pushed any new code up to the production app recently.

—
Reply to this email directly or view it on GitHub
https://github.com/plataformatec/devise/issues/2734#issuecomment-89655905
.

Thanks & Regards,
Talal Arshad

[danielbonnell]

I had thought of that, but the CSRF tags are present in the DOM. Turns out the issue (at least for me) was being caused by the Blur / DoNotTrackPlus extension for Firefox. I had previously disabled it, along with my other extensions, but that had no effect. When I removed it, however, the problem went away. I further confirmed that by having a friend test the site on his machine using Firefox (without the extension).

Hope this helps someone in the future.

[pankajp20]

I'm getting same error while updating a record on IE only. This do not happen application wide but occur for specific action of a controller. While submitting a form (action is used to update a record in DB), received error "Can't verify CSRF token authenticity". When checked form in IE, creates hidden field for "authenticity_token" but submitting the form redirect me to root URL of app (in application controller) and gives same error in console. Also form in IE contains "csrf_meta_tags".

I tried to skip validating the CSRF token authenticity for this specific action but then form's data is not submitted (write skip_before_action :verify_authenticity_token, only: [:] in my controller).

This problem is coming after app migrated from Rails 3.2 to 4.2 (Devise version 3.4). Any one have idea on this issue.

[latortuga]

I know this can be frustrating but it isn't helpful to bump this thread saying that you're experiencing this bug without a reproducible test case. If you have a sample application that exhibits the behavior, we can look at it and try to fix it. A good bug report will include 1. what went wrong 2. what you tried to fix it and 3. a way to reproduce the error.

[talal7860]

And please try devise by installing it on a fresh install of rails with the
same versions. You will figure out what are you doing wrong

On Monday, April 6, 2015, Drew Ulmer [email protected] wrote:

I know this can be frustrating but it isn't helpful to bump this thread
saying that you're experiencing this bug without a reproducible test case.
If you have a sample application that exhibits the behavior, we can look at
it and try to fix it. A good bug report will include 1. what went wrong 2.
what you tried to fix it and 3. a way to reproduce the error.

—
Reply to this email directly or view it on GitHub
https://github.com/plataformatec/devise/issues/2734#issuecomment-90158302
.

Thanks & Regards,
Talal Arshad

[pankajp20]

Thank you @latortuga and @talal7860, but the actual problem was the "div"s. Structure of that page is based on "div" and one "div" (where the form lies) was placed inside table body mistakenly. And that "div" floats in the page causing this bug. Either no table should be used or the "div" should be inside a "td" tag.

[Aleksandaar]

If you are using forms and turbo-links, the issue can be solved by adding a :authenticity_token => true, like:

<%= form_for @your_model, :remote => true, :authenticity_token => true do |f| %>
<% end %>

[pdbradley]

Had this issue only in production (heroku) and fixed it by removing the :domain => :all

Myapp::Application.config.session_store :cookie_store, key: '_myapp_session',:domain => :all

to

Myapp::Application.config.session_store :cookie_store, key: '_myapp_session'

[mtozlu]

Make sure the browser you use accepts cookies (you can do it in settings). You can suspect this is the problem if the error happens in specific browsers (eg. Firefox).

[david-meza]

I had this issue only on heroku as well. Removing domain: :all worked for me

[antonkoh]

Having a similar problem on all browsers with my app:
https://github.com/antonkoh/railsrep/tree/master/lesson17/my_app

First way to reproduce:

1. As unauthorized user open any post on the main page.
2. In another tab sign in ([email protected] / 12345678)
3. On the first tab, enter any symbols in the New Comment field and try to submit.

Second way to reproduce:

1. As an authorized user ([email protected] / 12345678) open any post on the main page.
2. In another tab sign out.
3. On the first tab try to add a comment.

Both ways end in ActionController::InvalidAuthenticityToken exception.
This is also reproduced for any other POST requests from an unrefreshed page.

Devise 3.5.2, Rails 4.2.4

[drewhamlett]

Just in case anybody runs across this in Google(because I did). I used the domain: :all flag, and sign_out stopped working on production. I had two cookie sessions and I guess devise was only clearing one? Anyway removed domain: : all and everything is good again.

[eddroid]

I also resolved a similar Devise issue by unbundling the rails-api gem. Two different failures:

1. authenticity_tokens generated by form_for were invalid on POST sessions#new.
2. I had before_filter :authenticate_user! in ApplicationController. So there were no public pages (other than login). Even after a successful login POST, the session would remain empty and I'd be redirected to the login page again with a 401 Unauthorized.

Theory: rails-api (or something) is disabling the session, even in non ActionController:API-subclassed controllers. Since the token in the session needs to match the token in the form, token verification fails. The Rails source seems to indicate that if a session token comes back empty, a new random one is generated. This makes sense when rendering a form on a GET, but is unnecessary and confusing when handling POST/PUT/etc. The error isn't that the token doesn't match. The error is that, while your form has a token, the session doesn't, and your form's token doesn't match the one Rails just randomly generated.

[allpumpedup]

@drewhamlett suggestion of removing domain: :all flag worked for me.

[adrianoresende]

I have exactly the same of the first post problem, after switching to rails 5.
It solves cases removing rails-api but It has included native for Rails 5 and how to solve? =(

Rails 5.0.0.beta3
Devise 4.0.0.rc2 (support for Rails 5)

My error:

Started POST "/admin/sign_in" for 127.0.0.1 at 2016-03-22 12:08:56 -0300
Processing by Devise::SessionsController#create as HTML
  Parameters: {"utf8"=>"✓", "authenticity_token"=>"c2r8dL0baHl3NLUpW9s3fMoTcxuDaezGwSD2+2B4l7MHJJ0Hnwl4KTuowz1ewwSk6Hklqb/N+W40YJAa6YEBzw==", "user"=>{"email"=>"[email protected]", "password"=>"[FILTERED]", "remember_me"=>"0"}, "commit"=>"Entrar"}
  User Load (0.4ms)  SELECT  `users`.* FROM `users` WHERE `users`.`email` = '[email protected]' ORDER BY `users`.`id` ASC LIMIT 1
   (0.2ms)  BEGIN
  SQL (0.3ms)  UPDATE `users` SET `current_sign_in_at` = '2016-03-22 15:08:56', `sign_in_count` = 47, `updated_at` = '2016-03-22 15:08:56' WHERE `users`.`id` = 2
  SQL (0.4ms)  INSERT INTO `versions` (`item_type`, `item_id`, `event`, `object`, `created_at`, `object_changes`) VALUES ('User', 2, 'update', '---\nid: 2\nname: Adriano\nprofile: \nadmin: true\ncreated_at: 2016-03-21 23:51:39.000000000 Z\nupdated_at: 2016-03-22 15:08:49.000000000 Z\nemail: [email protected]\nencrypted_password: \"$ ... \"\nreset_password_token: \nreset_password_sent_at: \nremember_created_at: \nsign_in_count: 46\ncurrent_sign_in_at: 2016-03-22 15:08:49.000000000 Z\nlast_sign_in_at: 2016-03-22 15:08:49.000000000 Z\ncurrent_sign_in_ip: 127.0.0.1\nlast_sign_in_ip: 127.0.0.1\nphoto_file_name: \nphoto_content_type: \nphoto_file_size: \nphoto_updated_at: \ncreated_by: \nupdated_by: \n', '2016-03-22 15:08:56', '---\ncurrent_sign_in_at:\n- 2016-03-22 15:08:49.000000000 Z\n- 2016-03-22 15:08:56.000000000 Z\nsign_in_count:\n- 46\n- 47\nupdated_at:\n- 2016-03-22 15:08:49.000000000 Z\n- 2016-03-22 15:08:56.000000000 Z\n')
   (47.5ms)  COMMIT

Can't verify CSRF token authenticity

Redirected to http://localhost:3000/admin
Completed 302 Found in 186ms (ActiveRecord: 50.2ms)

Started GET "/admin" for 127.0.0.1 at 2016-03-22 12:08:56 -0300
Processing by Admin::PagesController#dashboard as HTML
Redirected to http://localhost:3000/admin/login
Filter chain halted as :require_login rendered or redirected
Completed 302 Found in 2ms (ActiveRecord: 0.0ms)

[chris357]

Rails 4 on chrome.

Findings:

1. Issue only occurs if user logs in, logs out, and then tries to log in again.
2. Clearing the cache (shift + cmd + r) fixes the issues temporarily.

Is it possible that Angular continues providing the old CSRF token instead of a new one and this causes the issue?

[ACPK]

@adrianoresende I'm also hitting this issue with Rails5. Did you find a solution?

[adrianoresende]

@ACPK I not found solution =/
I went back to the latest version Rails4

[adrianoresende]

@josevalim Why you do not reopen this issue? Because Rails5

[codeodor]

I'm also seeing it in Rails 5, for what it's worth.

[codeodor]

For those having issues on Rails 5, see https://github.com/plataformatec/devise/pull/4033/files

[vickodin]

In my case, all working fine (nginx + puma + rails 5 with turbolinks 5), even without previous advice.
But after ssl certificate installation, I have got the same error: Can't verify CSRF token authenticity.

I added the next line to the nginx config, as solution:
proxy_set_header X-Forwarded-Ssl on;

And have no errors now.
I used devise, but the problem is not in devise. The usual forms was also broken.

[lazybios]

@vickodin I have same problem even if I remove devise from gemfile. Thank you for you tips about nginx.

[elkhan]

My issue with CSRF token related to paper_trail gem. There is a before_action :set_paper_trail_whodunnit I moved it below protect_from_forgery and configure_permitted_parameters then it started working. Hope it helps someone

[rdetert]

I was seeing this issue just now and it was related to me using Heroku + Cloudflare. I had the option set for "Enforce HTTPS for this URL" on Cloudflare. I've turned it off and it now works, but now I have to figure out what I'm going to do about SSL.

[holoiii]

@rdetert Were you able to figure out a solution? I am running into something similar - Heroku + Cloudflare (with their free flexible SSL) causes this issue. I am also on Rails 5

[rdetert]

@holoiii Yes, though I didn't spend a ton of time testing different scenarios. What I ended up doing was this:
1) Add the Expedited SSL Add On from Heroku
2) Change Cloudflare SSL from Flexible to Full
3) Force SSL in ApplicationController ( force_ssl if: :ssl_configured? )

Heroku cannot use apex domains so Expedited SSL will make you use https://www.mydomain.com, however, running with Cloudflare, it works fine using https://mydomain.com

Seems to work.

[pudiva]

+1 for

proxy_set_header X-Forwarded-Ssl on;

on rails 5 with nginx and ssl. Note that it worked for some people, whiel other would get authenticity_token error. And i was getting strange redirection behaviour too1

I don't use devise btw...

[mmatusSVK]

Thanks to vickodin,
for rails 5 with nginx is needed not only to prependprotect_from_forgery, but also set up
proxy_set_header X-Forwarded-Ssl on; in nginx site config.

[unkrich]

I was able to solve this problem after quite a lot of troubleshooting. I am using cloudflare with heroku. The fix was to switch Cloudflare's SSL from Flexible to Full. Then everything worked. That simple.
Note that I am using the 'beta'-ish feature of Heroku's paid dynos which allow you to upload an SSL certificate for free rather than the SSL Endpoint plugin (if this matters).

[corps]

Another potential cause worth mentioning: sessions not saving. I had a problem in which my form was generating a csrf token, and it was being sent and received by the server correctly, but it was never matching the token in the session because a new one was being regenerated every request due to a session issue.

[santhoshdevadiga]

I have the same problem but I am not using the device.
In application controller added 'protect_from_forgery' to fix CSRF issue.

To reproduce
Step 1 : Login Page opened in 2 tabs (Tab1 and Tab2)
Step 2: From tab1 logged in and logged out
Step 3: From tab2 I tried to log in then I got below because token destroyed from tab1 logout request

Processing LoginController#login (for 70.71.248.213 at 2016-11-05 14:37:03) [POST]
  Parameters: {"authenticity_token"=>"sobCryvXTgoi29Ifwb88nJicHY+3jmiybWvXWwfghQw=", "commit"=>"Login", "controller"=>"login", "password"=>"[FILTERED]", "os_info"=>"Windows", "action"=>"login", "username"=>"test", "browser_info"=>"Mozilla an unknown version"}

ActionController::InvalidAuthenticityToken

The Same issue is happening for Ajax post request in another tab3 (opened another page before logout from tab1).

Do we have any solution to fix this issue?

[muhammadn]

I have this problem (with Rails 5 and nginx) but proxy_set_header X-Forwarded-Ssl on; is a partial solution at least when i am using facebook OAuth login with Omniauth (and devise) with error like:

Can't verify CSRF token authenticity.

The solution is to use proxy_set_header X-Forwarded-Proto $scheme; instead of proxy_set_header X-Forwarded-Ssl on;

[rusllonrails]

@pdbradley thanks bro, your suggestion works perfect!

[paulewetzel]

Yep, proxy_set_header X-Forwarded-Proto $scheme; worked for me as well. I was just about to throw a TV out a 2nd story window, and now I can watch it instead....thanks!
location @unicorn {
proxy_pass http://unicorn;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_redirect off;
}

[janospapp]

Thank you guys! I've been struggling for days with authenticity token failure in chrome (in firefox it worked properly). After adding "proxy_set_header X-Forwarded-Proto $scheme;" to nginx config the problem is solved. I might messed up the config file when setting up ssl. Big thanks!!

[jarvisjohnson]

Following on from Cloudflare SSL comments above (@rdetert). If you are not using Heroku, so you aren't able to access an automatic SSL addon, you need to add an actual certificate on your nginx server manually.

Here's how I set it up on Digital Ocean:

Generate a TLS cert from cloudflare (free, just below the SSL flexible/full/strict area).

On the server (as root):

• add the certs: {app_name}_cert.cert & {app_name}_key.key to /home/{your-app-name}
• Change /etc/nginx/sites-available/{your-app-name} to include:

server {
        listen 80;
        listen 443;

        ssl     on;
        ssl_certificate         /home/{app_name}/{app_name}_cert.pem;
        ssl_certificate_key     /home/{app_name}/{app_name}_key.key;
        ...
}

Set Cloudflare SSL settings to Full(strict) to force Cloudflare to use your server certs

Finally, configure config/environments/production.rb : config.force_ssl = true

[Raja-Sharma]

Rails 5.1, aws elastic beanstalk with cloudfront.

Had the same error and tried everything here to no avail. Fixed it by changing cloudfront behavior settings. Set "Forward Cookies" to "all" from the default "none (Improves Caching)" in Distribution Settings > Behavior > (select behavior) > Edit.

[inem]

I recently caught the same problem.

This commit caused it:

Looks fine, but turns out it is a bad idea to access current_user in before_action in ApplicationController

Devise controllers are still controllers, and are inherited from ApplicationController.

So I tried to access current user in before_action, before devise finished its protect_from_forgery stuff.

The fix was to put protect_from_forgery before my action

[abpaul]

Faced this issue recently.
The error was appearing from the fact that one of our new layout files was a missing its csrf_meta_tags. So, for anyone else facing this issue, you might want to check there too! :smile:

[lostphilosopher]

I had this problem, for me it was nothing to do with Devise. It was Rails5 + Heroku + CloudFlare as explained here: http://til.obiefernandez.com/posts/875a2a69af-cloudflare-flexible-ssl-mode-breaks-rails-5-csrf.

"Turn Cloudflare SSL to Full mode. Problem solved."

[czeisser]

I was experiencing this problem too. It turned out that the prepend: true option for protect_from_forgery was being overwritten.
I was using a gem that also declared protect_from_forgery but without the prepend option so it defaulted to false. (In my case auto_session_timeout gem was the culprit.)
To fix this I moved my protect_from_forgery after the auto_session_timeout in the ApplicationController.

  class ApplicationController < ActionController::Base
  ...

  auto_session_timeout Rails.configuration.session_timeout_length

  #has to be after auto_session_timeout so that prepend will not be overwritten.
  protect_from_forgery with: :exception, prepend: true

[ruvaleev]

For me the problem was solved when wrote this in my application_controller.rb

class ApplicationController < ActionController::Base
protect_from_forgery with: :exception
check_authorization :unless => :devise_controller?

Another order of strings above was the reason of exception. Hope it'll help somebody.

[GuanglinDu]

I ran across this problem after I switched back and forth between the development and production environment on the same machine with browser Firefox. The 2 data sets are quite different. It took me 2 days to find out that it was caused by the Firefox cache. After the cache was cleared, Rails (4.2.11.1 & Ruby 2.2.5) functions properly. The lesson learned: never mix up the development and production environment on the same machine.

[clst]

I also came across this problem. After verifying that it worked fine on all other machines I tried I got suspicious.

Turns out Server 2016's Internet Explorer needs to have the Rails site added to "Trusted Sites" then it magically starts working. I have not investigated further.

[cruznunez]

i came across the problem and had nothing to do with Devise. My solution was different than the ones here.

I have two modal forms. It seemed like the 1st one was working and the 2nd one wasn't. I checked the authenticity tokens on them and they are different per form. I grabbed the authenticity token from the metatag and made that the value of the authenticity token hidden field for the 2nd form.

Tried it and it fixed it. Here's the coffescript:

editNoteModal = ->
  $('[href="#edit-note"]').click ->
    # code

    modal = $ '#edit-note'

    # code
    # code
    # code

    token = $('meta[name="csrf-token"]').attr('content')
    authTokenField = modal.find '[name=authenticity_token]'
    authTokenField.val token

$(window).on 'turbolinks:load', editNoteModal

[camilova]

This error was the browser's cache for me. I was working on two different projects, and both were on localhost:3000. When I came back to the first project after work on the another, I could not log in any more due wrong verification token, then I looked on the Chrome resources and there was a coockie from the another project. I have removed the wrong cookie, but it did not work, then I delete all the data of the browser through its configuration menu, and all is working get!

Before my solution I tried with a private window, on wich all worked, so I came to the idea of the browser's cache, that finally was the solution.

[Arish-theGalaxyBea]

The simplest solution for the problem is do standard things in your controller or you can directly put it into ApplicationController

class ApplicationController < ActionController::Base
protect_from_forgery with: :exception, prepend: true
end