Cross-Origin Resource Sharing (CORS) is a mechanism by which a web application can access resources defined in another domain. Browsers for example, rely on this standard for allowing cross origin requests.
The CORS policy complies with Cross-Origin Resource Sharing W3C Recommendation 16 January 2014. From API Manager, you can apply the policy, the default policy configuration considers the API to be a public resource. If not, removing the Public Resource check will enter the extended CORS configuration.
|You must specify the default group before specifying another one. The Default group is not a fallback in the normal sense of a default. In this case, it is only the first group you configure for CORS.|
Important: The CORS policy cannot be ordered. This isn’t a technical limitation, but rather by design. No OPTIONS request can reach the backend if CORS is configured, as this request is treated as a Preflight according to the CORS-compliant RFC.
In Mule Runtime 4.0, the CORS Interceptor is a element in the HTTP Listener configuration. To be consistent, its configuration is the same as in the policy. Use this feature when the Mule Runtime has not been started with API Gateway capabilities and CORS functionality is needed.
|Beware that in this scenario, altering the configuration will force an application redeploy.|
The CORS configuration structure may change whether it is configured as a public resource or for a selected group of origins. The structure of the latter option is:
<http:listener-interceptors> <http:cors-interceptor allowCredentials="optional boolean value (true/false)"> <http:origins> (collection of origins) <http:origin url="http://origin.com" accessControlMaxAge="integer value"> <http:allowed-methods> <http:method methodName="method 1"/> ... <http:method methodName="method n"/> </http:allowed-methods> <http:allowed-headers> <http:header headerName="header 1"/> ... <http:header headerName="header n"/> </http:allowed-headers> <http:expose-headers> <http:header headerName="header 1"/> ... <http:header headerName="header n"/> </http:expose-headers> </http:origin> </http:origins> </http:cors-interceptor> </http:listener-interceptors>
The public resource configuration looks like this:
<http:listener-interceptors> <http:cors-interceptor allowCredentials="optional boolean value (true/false)"> <http:origins> <http:public-resource/> </http:origins> </http:cors-interceptor> </http:listener-interceptors>
If you cannot implement CORS for your API, another possible solution to an unreachable API is to disable the same-origin restrictions in your browser.
Each browser handles these restrictions in a unique way and tips, tricks, and plugins are available on the internet.
Make sure you understand the potential security implications of changing browser security settings. You should only use these options for testing on your own web pages because the browser can become vulnerable to malicious scripts and other potential threats.
Open a new Terminal window, paste the following line, and then press Enter:
open -a Google\ Chrome --args --disable-web-security.
Open a new Command Prompt window, navigate to the location of the Chrome executable (Chrome.exe), paste the following line, and then press Enter: