Rails, REST Architecture and HTML 5: Cross domain

问题:

While working on a project to make our site HTML 5 friendly, we were eager to embrace the new method for Cross Domain requests (no more posting through hidden iframes!!!). Using the Access Control specification we begin setting up some tests to verify the behaviour of various browsers.

The current Rails RESTful architecture relies on the four HTTP verbs: GET, POST, PUT, DELETE. However in the Access Control spec, it dictates that non-simple methods (PUT, DELETE) require a pre-flight request using the HTTP verb OPTIONS. In addition during testing we discovered that Firefox 3.5.8 pre-flight POST requests as well.

My question is this. Is anyone aware of any project for the Rails framework working to address the issue? If not, any opinions about the best strategy to support the OPTIONS method, since it has to support the routes for all the POST, PUT, DELETE methods?

回答1:

I released a Gem a couple of days ago that implements CORS support via a Rack Middleware:

http://github.com/cyu/rack-cors

Regarding preflight CORS requests, I couldn't get preflight requests working in Chrome (through simple CORS requests work fine). Searching around the Internets suggests that it might not be supported. I've asked questions in the Chrome forum about this, but haven't heard a response yet.

回答2:

This is from Spine js documentation

CORs Rails integration

Let's create a cor method, which will add some of the request access control headers to the request's response.

Add the following to app/application_controller.rb:

before_filter :cor

def cor
  headers["Access-Control-Allow-Origin"]  = "js-app-origin.com"
  headers["Access-Control-Allow-Methods"] = %w{GET POST PUT DELETE}.join(",")
  headers["Access-Control-Allow-Headers"] = %w{Origin Accept Content-Type X-Requested-With X-CSRF-Token}.join(",")
  head(:ok) if request.request_method == "OPTIONS"
end

Although Access-Control-Allow-Origin takes a wildcard, I highly recommend not using it as it opens up your app to all sorts of CSRF attacks. Using a whitelist is much better and more secure.

The Access-Control-Allow-Headers section is important, especially the X-Requested-With header. Rails doesn't like it if you send Ajax requests to it without this header, and ignores the request's Accept header, returning HTML when it should in fact return JSON.

It's worth noting that jQuery doesn't add this header to cross domain requests by default. This is an issue that Spine solves internally, but if you're using plain jQuery for CORs, you'll need to specify the header manually.

jQuery.ajaxSetup({
  headers: {"X-Requested-With": "XMLHttpRequest"}
});

Some browsers send an options request to the server first, to make sure the correct access headers are set. You'll need to catch this in Rails, returning a 200 status with the correct headers. To do this, add the following to your application's config/routes.rb file:

match '*all' => 'application#cor', :constraints => {:method => 'OPTIONS'}

That's it, you're all set up for Cross Origin Requests with Spine!

回答3:

I hacked rails to support the options method. I posted this on the rails list, but it never made it past the list.

GitHub Gist: Rails XHR2 / CORS / OPTIONS support

ctrl+f to find the lines that have #Options - those are the only ones I changed.

And here's an example implementation | and another