token_verifier.rb:34 ActionController::InvalidAuthenticityToken #8
Comments
|
@sikachu I will try to find the steps to reproduce. |
|
@ybakos sorry for the late reply, and thank you for your report. This gem actually hooks into Rails request stack by adding itself in One way to workaround this issue is to by creating a middleware that rescue # app/middlewares/rescue_from_invalid_authenticity_token.rb
class RescueFromInvalidAuthenticityToken
def call(env)
yield
rescue ActionController::InvalidAuthenticityToken
[302, {'Location' => "/sessions/new, 'Content-Type' => 'text/html'}, ['Invalid Authenticity Token']]
end
endThen insert it before config.middlewares.insert_before "RescueFromInvalidAuthenticityToken", OmniAuth::BuilderI have not tested the code above, but I hope I can give you some idea. |
|
I am having this issue as well. I realized this problem existed when I deployed the first time to my sandbox environment. Other developers weren't able to access the login links because of this. We found out that deleting cookies fixed the issue, but I don't want my users to delete their cookies when I release this to production. @sikachu Is your proposed workaround a safe solution? meaning this would still protect against csrf? Provider Gem: omniauth-rails_csrf_protection 0.1.2 How to reproduce: |
|
@mbenitezm yes, it should not compromise the security as we pretty much send user back to the start to initiate the flow again. I wonder what is the right way to work around this issue. Maybe having an option for you to specify how we should handle the bad token might be a good start ... |
This approach has issues with cookies. Ref: cookpad/omniauth-rails_csrf_protection#8
|
+1 Having the same issue |
|
For the record, I recently tried to upgrade my application from I'm using: 🕵️♂️ But I tried without this gem and saw that I was still getting CSRF errors (less visible though as maybe rescued differently). I followed rails 6 upgrade process which changes So that's one thing to look for if you end up having this error, I'm not sure why they made this change at it can break every form by default 🤷♂️, hopefully it'll help some people 👍 |
This sounds like a good idea. Adding another middleware seems a bit clunky. |
|
AFAICT this happens in between deploys. Most rails applications handle token errors in application controller, however this is a middleware, to it never reaches the controller (as @sikachu already mentioned). From the solutions I see described here, some mitigation strategy needs to be done at the rails level, so maybe this gem could rethink the approach and maybe implement the verification as a before_action instead of as a middleware? Because we already handle such errors there, and could treat it accordingly, while the extra-middleware approach is definitely clunky. Also conscious that this is built on top of omniauth and omniauth is itself a middleware, so not sure how to best approach this. |
|
Do you happen to be running the secure_headers gem? |
|
I just spent quite some time debugging this. In my case, I was following an auth0 tutorial that instructed to generate a link with Turns out that the path had to be "/auth/auth0" (slash in the beginning) for rails to correctly compare the path. Shrug. Maybe this helps someone else. Not sure if this is actually a Rails bug.. it seems at least little unfriendly. |
|
I was facing the same issue and i tried all the solutions given above but none of them worked for me. The issue was replicating whenever my cache was set to nil. Then I see the example app given by Auth0 and in that they were using cache_store in a different way inside development.rb I tried with and it worked for me. I dont know what is the difference between the two but it is working for me. |
|
@mindsublimes Can you please post a link to the example app that shows this config difference? |
|
@ybakos yeah definitely, here it is https://github.com/auth0-samples/auth0-rubyonrails-sample/tree/master/01-Login |
@jarthod that is very interesting. I feel like that's a bug in Rails if upgrading to Rails 6 switch your cache store to
Yep, that won't work as omniauth is hooking into rails at middleware level so we have to be at this level as well. I will have some time to working on the failure handling this week, and I'll cut a new version afterward. I'm going to keep this open for now as I want to hear more about the problem with the |
I used the classic So yeah maybe a little note about that in the Readme could help because the error message is clearly not obvious in this case but it'll boil down to: "make sure you have a session store that stores stuff" ^^. But people won't check the gem readme when they get this error I think, they'll just look it up online and find this issue that's why I added this comment here ;) Ideally if we can have a different error message for when the session store is simply returning nil maybe it could make it easier to lead people to the solution. |
Got it, thanks! And yes, I think document that the CSRF token will be stored in session would be useful ... so I'll add that. |
|
@pasih Thanku So much man! |
|
I had to set |
Thanks a lot to @pasih for providing the solution here: cookpad/omniauth-rails_csrf_protection#8
Thanks a lot to @pasih for providing the solution here: cookpad/omniauth-rails_csrf_protection#8
|
Thanks @sikachu, just to add to your code from here #8 (comment) I've tested this code in the wild (Rails 7) and it works:
class RescueFromInvalidAuthenticityToken
def initialize app
@app = app
end
def call(env)
@app.call(env)
rescue ActionController::InvalidAuthenticityToken
env["rack.session"]["flash"] = ActionDispatch::Flash::FlashHash.new(alert: "Invalid Authenticity Token.")
[302, {'Location' => "/sessions/new", 'Content-Type' => 'text/html'}, ['Invalid Authenticity Token']]
end
end |
|
+1 for changing |
|
When creating a form a csrf token is added to the form (suppose: token1) Remember: 'This token was generated in the begining by ActionController when a session is create'). When the request goes to the file token_verifier.rb of omniauth-rails_csrf_protection, there seems to be no session[:_csrf_token] present. Therefore it hits the ActionControlller of Rails and generate a new token (suppose token2). But the session stored has token1. The omniauth-rails_csrf_protection now checks rails' ActionController's verified_request? method and token2 doesn't match with token1. |
Please complete all sections.
Configuration
omniauth-rails_csrf_protection 0.1.22.6.5RailsHerokuExpected Behavior
Recent changes to csrf protection seem to cause a non-rescuable exception. Using
application_controller.rb:
I expect that ApplicationController can catch the exception, but it does not.
Actual Behavior
An exception is raised with the following stacktrace.
/GEM_ROOT/gems/omniauth-rails_csrf_protection-0.1.2/lib/omniauth/rails_csrf_protection/token_verifier.rb:34
URL: https://myapp/users/auth/google_oauth2
Steps to Reproduce
I apologize (!) but whatever I do in development or production, I can't seem to recreate this issue, but my end users in production can. I need to isolate exactly what they are doing and will post back.
The text was updated successfully, but these errors were encountered: