RESTWS-382 Access-Control-Allow-Origin in response headers is in the to-do list of my GSoC project. However as the use case is not well understood there, the issue is kind of in halt. So I thought it’s worth a discussion.
Say domain-a.com trying to call the OpenMRS api on domain-b.com. However the request will be blocked because of the same-origin policy followed by all modern browsers. Since CORS is not setup, no requests originating outside of domain-b (or port) will be permitted access.
In our case if domain-b (rest service) is willing to accept a request from domain-a, api service may response with the header:
Access-Control-Allow-Origin: domain-a.com
which tells the browser to allow cross origin requests from domian-a.
So IMO this is an essential feature to be added to the rest module. Though further explanation won’t be necessary, here are some sample requests to OpenMRS api and to an API that supports CORS (httpbin.org).
$ curl --verbose -H "Origin: http://example.com" http://localhost:8081/openmrs-standalone/ws/rest/v1/session
> GET /openmrs-standalone/ws/rest/v1/session HTTP/1.1
> Origin: http://example.com
< HTTP/1.1 200 OK
< Set-Cookie: JSESSIONID=426827D5C10EC3E4C5B2EE4EDBD4679A; Path=/openmrs-standalone/; HttpOnly
$ curl --verbose https://httpbin.org/get
> User-Agent: curl/7.38.0
> Host: httpbin.org
< HTTP/1.1 200 OK
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Credentials: true
Workaround is to add a CORS_Filter to Tomcat (suggested by @pascal). But this will permit universal access from all origins and is platform specific.
So the solution I believe is to add configuration option which let users specify list of allowed domains, similar to “.allowedips”. Then it would be a matter of adding “Access-Control-Allow-Origin” to response headers after doing a simple verification on the API backend.
I see this approach is being followed by many major API services (Atlasian, Amazon).
