2

I trying to send a remote form to a different subdomain (example.domain.com) from the one of the form (domain.com), but i keep getting the warn WARNING: Can't verify CSRF token authenticity in the log, and inspector in chrome tells me that the status of the request is (canceled), with the type application/x-www-form-urlencoded.

This is the form: button_to "Follow", follow_users_url(subdomain: post.user_username_slug), remote: true

When i remove the remote: true, i got the result i was hopping for. Also, when a try to use the same form in the same subdomain of the action (example.domain.com), i got the correct result.

I found a way to share the cookies in all subdomains (domain: :all in session_store.rb), but i can't found a way to share the token in Ajax requests.

I'm using Rails 3.1.3, Ruby 1.9.3 and jQuery 1.7.1.

Anyone can help me, please?

Edit:

The problem seems to related to CORS. Now i'm trying to find a minimum friction solution to make this (Asynchronous) cross subdomains requests work.

Leandro Maioral
  • 23
  • 1
  • 5

2 Answers2

3

In your POST paramaters, include the field "authenticity_token" with the value returned by the helper *form_authenticity_token*. (It has nothing to do with cookies).

Edit I think you're hitting up against the Same-Origin Policy, which prevents javascript from domain A from communicating with domain B (also applies to subdomains). There is an "override" for this called CORS, which the domain you are talking to must implement.

So assuming you have control over both domain A and B, you can work around this limitation. This explains why "normal" requests work while ":remote => true" requests don't. (The CSRF token error is probably inaccurate.) Here's an article about setting up CORS in Rails (domain B, in my example).

bioneuralnet
  • 5,283
  • 1
  • 24
  • 30
  • Looking in the source code of the page, there is already a authenticity_token field being generated for the `button_to`. `
    `     – Leandro Maioral Jan 19 '12 at 18:15
  • I think your auth token is fine, and is an inaccurate error. Evidence points to this being a Same-Origin Policy violation. See my edit. – bioneuralnet Jan 19 '12 at 18:43
  • I will read the post and get back with the result. Thank you for now. – Leandro Maioral Jan 19 '12 at 18:50
  • I have read the post and understood the limitation. I just don't know how to implement a minimum friction solution for this. I will need to request across subdomains really often, with different controllers. – Leandro Maioral Jan 19 '12 at 19:27
  • I would suggest putting the two cors methods into your Application controller. Then you can just add the filters to specific controllers; shouldn't be too much duplication that way. As for your routes, I'm not sure if there's a way to create a generic "options" route. May be some good advice at http://www.codeodor.com/index.cfm/2011/7/26/Responding-to-the-OPTIONS-HTTP-method-request-in-Rails-Getting-around-the-Same-Origin-Policy/3387 or http://stackoverflow.com/questions/2858741/rails-rest-architecture-and-html-5-cross-domain-requests-with-pre-flight-reque – bioneuralnet Jan 19 '12 at 20:55
0

You can set the authenticity token in both controllers to be the same

I think it is

protect_from_forger :secret => 'long_secret_string'

If both controller use the same token you should be able to post across sub domains or other sites. You do open up some cross site scripting holes though

Rob Sutherland
  • 1,211
  • 12
  • 14