Hopefully after a long struggle you’ve finally finished testing that awesome Rails API you were building and you need it cors enabled for the world to use it. Here’s how.
If we want to make our API available to other users, specifically those making API calls with JavaScript in the browser, we’ll need to enable CORS (cross-origin resource sharing) requests. Browsers implement the same-origin policy, a security measure that limits JavaScript in the browser to resources that come from the same domain. CORS is a protocol that allows browsers to communicate across domains.
Now that we’re building our own Rails APIs, we can decide whether we’ll allow CORS requests or not. If we want to allow all sources to communicate with our API, we’ll need CORS. On the other hand, if our application should only handle requests made by other server-side applications, we might choose to handle CORS requests differently (or not have them at all).
We can configure CORS in app/config/initializers. Initializers are run after an application's environment is loaded and are responsible for a number of tasks, including building our application's middleware. Our Rails application automatically uses rack-cors middleware to handle CORS. (A quick reminder: middleware acts as a bridge between our application and the server running our application; Rails is built on Rack middleware.)
Let’s take a look at the CORS initializer now. You’ll see the following commented-out code:
app/config/initializers/cors.rb
Rails.application.config.middleware.insert_before 0, Rack::Cors do
allow do
origins 'example.com' resource '*',
headers: :any,
methods: [:get, :post, :put, :patch, :delete, :options, :head]
end
end
This code is boilerplate for allowing CORS requests. Let’s go over a few key points.
First, we can specify which origins we’ll allow. For instance, if we change example.com to the wild card *, our application will allow all origins. (This is potentially very risky!) We can also choose to limit origins to a single domain, such as the domain where our client-side application is being hosted (if it's a different domain from the server).
In addition, we can limit which resources are made available to these origins (in this case, the wild card *means all resources are allowed) as well as which headers and methods we'll accept. For instance, we could provide only the [:get] method if we don't want other applications to post or otherwise make changes to our database.
If you leave the code in the cors.rb file commented-out, your application will not allow CORS. If the code isn't commented out, your API will allow CORS to the origins you specify.
Now that you know how CORS is configured in a Rails application, you can explore further customization on your own or simply leave it commented out. You don’t need to allow CORS to make requests from Postman, cURL or another Rails application, and you won’t be expected to configure CORS settings on your code review. However, if you try to make a request to your API from the browser with JavaScript, you’ll need to enable CORS.
