Fix by adding more headers in Nginx (X-Forwarded-Ssl on, X-Forwarded-Port 443 and X-Forwarded-Host hostname)

I also ran into this issue. I'll describe it differently to help with future searches.

Submission of any form to Nginx proxying to a Puma unix socket running a Rails 5.0.0.beta1 app responds with:

Can't verify CSRF token authenticity

and throws:

ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken)

even though the App's CSRF is set up correctly. The app works in development (puma or thin, without Nginx), and worked in Nginx/Puma/Rails-4.2. I don't know if this is specific to using Puma, but seems like the same problem could exist with other servers (unicorn, passenger, etc.)

I don't know if this behavior change is an error or intended.

I can confirm @tpbowden's solution worked for me as well. In my nginx configuration, I setup the app to proxy to puma listening on a unix socket. Here are the relevant parts of the configuration.

upstream myapp {
  server              unix:///path/to/puma.sock;
}
...
location / {
  proxy_pass        http://myapp;
  proxy_set_header  Host $host;
  proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header  X-Forwarded-Proto $scheme;
  proxy_set_header  X-Forwarded-Ssl on; # Optional
  proxy_set_header  X-Forwarded-Port $server_port;
  proxy_set_header  X-Forwarded-Host $host;
}

The issue isn't related to Puma and would happen to any web server running behind a reverse proxy which isn't passing the correct headers through. The way I managed to figure out how this issue was being caused was by following the error down the stack trace.

The root of the issue is the code in request.origin == request.base_url, which compares the Origin header's value against the base_url which is build up by a Rack::Response. There are 3 parts to this value, the scheme, the host and the port. All three of these are calculated based on a series of headers which not present by default when using a reverse proxy.

You can follow the source for Rack::Request#base_url here and it will become clear by looking in your web logs which headers are missing.

I've just done a bit more research and it is definitely the intended behaviour. It can be disabled in your app config using config.action_controller.forgery_protection_origin_check = false. It is enabled by default however.

@tpbowden Did you find a solution that doesn't disable forgery protection in the end? I think I'm facing the same problem and really struggling to make 'clean' progress.

Yes the problem was not passing enough headers through my reverse proxy (nginx) for Rails/Rack to determine whether the request was originally made using https or not (since it was already decrypted by the time it hit Rails)

ahh, so how did you find out what was missing...and how did you add the missing headers? Thanks so much for the quick reply!

If you look at @afair's comment above he was referenced a correct Nginx config, you just need to add the x-forwarded headers related to ssl. I figured out which ones were missing by digging though the source code of Rack's request object to find out how it determine's the protocol of the request.

Alas @afair's config doesn't work for me. Moreover, my logs have been annoyingly sparse since adding my Puma config (but that's another story.)
Thanks anyway, I'll think on it.

I narrowed my issue down to nginx not playing well with 2 virtual hosts running at the same time. I'm trying to run a staging VPS and a production VPS using jwilder's nginx-proxy.
Everything works fine using the standard generated conf file when only staging OR production is running. However I run into the ActionController::InvalidAuthenticityToken errors on form submissions when both are running at once.
I haven't solved it yet, but thought I'd leave this here in case anyone else follows a similar trail of blunders.

Thanks @tpbowden and @afair I was desperatly trying to make any sense of this oddly failing CSRF protection... then I found this issue 👍

Many thanks @tpbowden and @afair, you've made my day!

@afair You, Sir, have saved a lot of my time. Thank you.

Thanks @tpbowden! You made my day!
This helped! Yeah! ;)

Thanks so much :
I was missing this line :
proxy_set_header X-Forwarded-Proto $scheme;

@afair fixed my problem! thank you!

My problem was similar, using heroku and cloudflare, solution was:

Make sure you have working SSL and HTTPS on Heroku (or wherever you're serving your Rails application.) Turn Cloudflare SSL to Full mode. Problem solved.

from: http://til.obiefernandez.com/posts/875a2a69af-cloudflare-flexible-ssl-mode-breaks-rails-5-csrf

@Onumis Thank so much! I turn Cloudflare SSL to Full mode and fixed the problem.

For those using Apache, this worked for me:

RequestHeader set X-Forwarded-Proto "https"

I also ran into this issue. I'll describe it differently to help with future searches.

Submission of any form to Nginx proxying to a Puma unix socket running a Rails 5.0.0.beta1 app responds with:

Can't verify CSRF token authenticity

and throws:

ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken)

even though the App's CSRF is set up correctly. The app works in development (puma or thin, without Nginx), and worked in Nginx/Puma/Rails-4.2. I don't know if this is specific to using Puma, but seems like the same problem could exist with other servers (unicorn, passenger, etc.)

I don't know if this behavior change is an error or intended.

I can confirm @tpbowden's solution worked for me as well. In my nginx configuration, I setup the app to proxy to puma listening on a unix socket. Here are the relevant parts of the configuration.

upstream myapp {
  server              unix:///path/to/puma.sock;
}
...
location / {
  proxy_pass        http://myapp;
  proxy_set_header  Host $host;
  proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header  X-Forwarded-Proto $scheme;
  proxy_set_header  X-Forwarded-Ssl on; # Optional
  proxy_set_header  X-Forwarded-Port $server_port;
  proxy_set_header  X-Forwarded-Host $host;
}

Thank you so much. Worked for me too.

Thanks so much :
I was missing this line :
proxy_set_header X-Forwarded-Proto $scheme;

Also works without the socket thing:

upstream rails_app {
  server app:3000;
}

...
server {
  ...
  location @rails {
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP  $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_redirect off;
    proxy_pass http://rails_app;
  }
}

Thank you so much buddy it's worked for me.
location @rails { proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_redirect off; proxy_pass http://rails_app; }

My problem was similar, using heroku and cloudflare, solution was:

Make sure you have working SSL and HTTPS on Heroku (or wherever you're serving your Rails application.) Turn Cloudflare SSL to Full mode. Problem solved.

from: http://til.obiefernandez.com/posts/875a2a69af-cloudflare-flexible-ssl-mode-breaks-rails-5-csrf

Thank you, I love you :)

If you are using Dokku and facing this problem, check out this awesome guide https://okhlopkov.com/cloudflare-certificates-dokku/

I'm using Aliyun load balance which is called SLB for my two other application servers. My application servers started at port 3000 and the application server didn't set up ssl.

When the user access my website by https, SLB redirect the request to application server with http. So now we have the issue:
the origin is https, but the request base url is http

The solution for this is to make sure when SLB redirect request to application server we should provided the proxy header: X-Forwarded-Proto

I think the header missing is the root cause for this case.

My problem was similar, using heroku and cloudflare, solution was:

Make sure you have working SSL and HTTPS on Heroku (or wherever you're serving your Rails application.) Turn Cloudflare SSL to Full mode. Problem solved.

from: http://til.obiefernandez.com/posts/875a2a69af-cloudflare-flexible-ssl-mode-breaks-rails-5-csrf

Thank you. this solved the issue for me as well 🙏

usando o proxy reverso do apache é adicionar

RequestHeader set X-Forwarded-Proto "https"