Some services don’t support CORS, but we can use NGINX to make CORS supported with this simple hack! To enable CORS on any service we need to have NGINX configured as a Reverse Proxy and have NGINX add a successful pre-flight response to the CORS pre-flight request. Read on to get this simple example to work.
CORS works on 3 levels: protocol, origin and port. That is if a browser is going to make a request to a server then the protocol, url and port must be the same as the page that the browser loaded. For example if from a page on the browser hosted on
http://lloydrochester.com then it would not be allowed since both the prototcol -
http instead of
https and port
80 instead of
lloydrochester.com. This is all assuming, that CORS isn’t enabled. When CORS is enabled we can get a lot of flexibility to allow clients to access back-ends many different origins.
Let’s first digress into the pre-flight request. The pre-flight request is sent by the client - think the browser here - to check to see if the server will allow it to make a request. If a service doesn’t support CORS then an unsuccessful response will be sent back from the pre-flight request. This is where NGINX comes in. We can have NGINX respond with a successful response for the pre-flight request and the browser will allow requests to go through to this service. This does require that the service is behind an NGINX reverse proxy.
Example NGINX Configuration to Allow for CORS
Let’s say we have a service that is running in Docker behind port 3000. When we go to a
/non-cors-service on this server we want CORS enabled. The example below will listen for the pre-flight request which is an
OPTIONS request and send a successful CORS response. The example will also add CORS headers of
Access-Control-Allow-Methods to all responses. These headers allow CORS on the requests after the pre-flight request. Read through the example as comments are put throughout.
The best way I’ve found to debug CORS is in the console of the browser. The network requests from the developer tools in some browsers won’t show the CORS errors, but the console will. For debugging the back-end on the NGINX side run the server but also use the
nginx -t command which will check for any configuration errors. Also, look in the logs when the server was started. Once you have the browser make requests you should see the headers set from the example above in the developer tools from the network.