Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't verify CSRF token authentication with Android Devices #2851

Closed
elricstorm opened this issue Jan 30, 2014 · 5 comments
Closed

Can't verify CSRF token authentication with Android Devices #2851

elricstorm opened this issue Jan 30, 2014 · 5 comments

Comments

@elricstorm
Copy link

https://gist.github.com/elricstorm/8708994

I posted the log, the application controller methods for debugging, my routes, and my sessions controller.

I tried to use:

skip_before_filter :verify_authenticity_token, :only => :create

which will not work.

If I use:

skip_before_filter :verify_authenticity_token, :if => Proc.new { |c| c.request.format == 'text/html' }

then it works. I debugged and found that the request from the droid device was text/html. So, I added a skip_before_filter for the request format and that seemed to fix the problem.

However, I'm not sure this is a great fix down the road. Any advice? Also the same issue happens if a guest tries to register through devise. I had to create a custom users registrations controller and place the skip_before_filter on that too.

Keep in mind, this only happens with a droid device.

The user agent for the device is showing:

USERAGENT: Mozilla/5.0 (Linux; U; Android 4.0.3; en-us; ADR6425LVW 4G Build/IML74K) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30

So far my tests have shown:

  • All html browsing using same request format text/html work work by default with no changes
  • All iphone models browsing using same request format text/html work by default with no changes
  • All iPad models browsing using same request format text/html work by default with no changes

I only have one droid model that I can test with. The model is an HTC Rezound. It fails by default and the only way it passes registration or sessions is if I place the skip_before_filter with the request.format check in. The standard skip_before_filter with a bypass on the create method doesn't do it.

@josevalim
Copy link
Contributor

Did you change the router to use your controller?

@elricstorm
Copy link
Author

I fixed the routing yesterday and closed the previous ticket believing everything to be fixed. I opened this ticket because it houses accurate information now and all logging and test criteria. I didn't want to cause confusion. :) Once I corrected the routing, I still received the csrf_meta bug even after using skip_before_filter on the create method.

I couldn't figure out why bypassing the create method wouldn't work because the log clearly shows that it's hitting the create method. I had to put the other skip_before_filter using the request.format instead in order to get this to work which seems awkward and not very clean.

Likewise, the same scenario happens when someone tries to register using a droid device through devise. I ended up having to create a Users::Registrations controller and adding the skip_before_method using request.format text/html in order to get things to work. Because this is happening on registrations, it doesn't appear to be session related as we had previously discussed.

I'm using the latest Devise, latest Rails, and Thin server. I just updated the gist to show you the routes.rb file as well. The first question is why does the skip_before_filter not work on the create method and the request.format does?

@latortuga
Copy link
Contributor

Can you try with a different browser (e.g. Chrome or Firefox) on your droid?

Additionally, your log output does not specify the verb of the request that was being processed which would be useful. It's typically in the line before you pasted, something like this:

Started POST "/your/route" for 127.0.0.1 at 2014-01-01 10:10:10 -0500

@elricstorm
Copy link
Author

Sorry about that. It is:

Started POST "/users/sign_in" for xxx.xxx.xxx.xxx at 2014-01-29 15:59:44 -0500

I'll see if I can test a different browser.

@josevalim
Copy link
Contributor

We are waiting for more information. Please notice a very similar issue was closed this week: #2849

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants