Configure for CORS

Depending on the REST client you're using, you may or may not need to configure for Cross-Origin Resource Sharing (CORS). You only need to configure for CORS if you're using a client developed in a browser-based programming language, such as JavaScript. Such clients can complete requests or access REST APIs only within the context of a web page in a browser.

Why Use CORS?

Simply put, CORS is a set of rules that defines the way a server and a browser talk to each other and whether or not it's safe to do so across different domains. As a specification, CORS provides a standard way to implement cross-domain requests that can be used in all browsers.

All browsers enforce the same-origin policy. This policy permits scripts contained in one web page to access data in another, but only if both web pages originate from the same domain. As a result, clients developed in browser-based programming languages that run in one domain cannot retrieve resources from another domain.

How You Configure CORS in Oracle Cloud

To enable CORS in Oracle Applications Cloud, you must set profile option values for the CORS headers using the Manage Administrator Profile Values task in the Setup and Maintenance work area.

The following table lists the supported CORS headers, and the profile option values that you can set for each header.

CORS Header	Purpose	Profile Option Name (Profile Option Code)	Profile Option Values
Access-Control-Allow-Origin	Provides a comma-separated list of trusted origins from which a client application can access resources.	Allowed Domains (ORACLE.ADF.VIEW.ALLOWED_ORIGINS)	Valid values for allowed origins: URL of the specific origin. For example, http://www.exampledomain.com Comma-separated list of origins. For example, http://www.exampledomain.com, http://us.example.com, http://software.example.com An asterisk (*) that allows access to resources from all origins. Empty (no value set), that prevents access to resources from any origin. Note: You must set a value for this header to enable CORS.
Access-Control-Max-Age	Specifies how long the response to a preflight request is cached.	CORS: Access-Control-Max-Age (CORS_ACCESS_CONTROL_MAX_AGE)	Default value for caching preflight request is 3600 seconds.
Access-Control-Allow-Methods	Provides a comma-separated list of permitted HTTP methods in a request.	CORS: Access-Control-Allow-Methods (CORS_ACCESS_CONTROL_ALLOW_METHODS)	Default values for allowed methods are OPTIONS, HEAD, GET, POST, PUT, PATCH, DELETE.
Access-Control-Allow-Headers	Provides a comma-separated list of permitted HTTP headers in a request.	CORS: Access-Control-Allow-Headers (CORS_ACCESS_CONTROL_ALLOW_HEADERS)	Default values for allowed headers are Accept, Accept-Encoding, Authorization, Cache-Control, Content-Encoding, Content-MD5, Content-Type, Effective-Of, If-Match, If-None-Match, Metadata-Context, Origin, Prefer, REST-Framework-Version, REST-Pretty-Print, Upsert-Mode, User-Agent, X-HTTP-Method-Override, and X-Requested-By.
Access-Control-Allow-Credentials	Specifies whether a client application can send user credentials with a request.	CORS: Access-Control-Allow-Credentials (CORS_ACCESS_CONTROL_ALLOW_CREDENTIALS)	Valid values: True, to enable sending credentials with the request. False, which is the default value, to disable sending credentials with the request.

You can configure CORS HTTP headers to enable a client application running in one domain to retrieve resources from another domain using HTTP requests. If, for example, your client application retrieves resource X from the REST API server A, then your client application sends an HTTP request to retrieve resource Y from REST API server B. To allow this cross-server request from the client application, you must configure the Access-Control-Allow-Origin header in server B. Otherwise, the request fails.

To learn more about how to configure CORS headers, see the implementation guide for the appropriate Oracle Applications Cloud service on Oracle Help Center.