Allow Cross Origin Requests in a Browser App
For two sites to be considered to be matching, the protocol (such as HTTP), hostname, and port number must match.
The way the browser determines if the the cross-origin request is allowed is to send an HTTP OPTIONS request to the destination site. The destination responds to the OPTIONS request to indicate that the request is allowed or not.
Cross origin request to the Akula Server
Configuring cross origin requests
You can configure the Akula Server to allow cross origin requests by editing the AKULA_HOME/global/properties.xml file. This technique is referred to as Cross-Origin Resource Sharing (CORS). The Akula Server reads the properties.xml file at startup. Therefore, after editing this file, you have to restart the Akula Server.
To configure Akula for cross origin requests:
Edit the provided properties.xml file to allow license activation from CORS-enforcing clients by adding the type
X-Lic-Session-Idto the list of supported headers in the
- Specify the list of sites allowed to access the Akula Server across origins. In the properties.xml file, use the following predefined app properties to specify a list of sites that are allowed to access the Akula Server across origins:
To specify the list of sites allowed to access the Akula Server, edit the
AKULA_HOME/global/properties.xml file. The Akula Server reads the properties.xml file at startup. Therefore, after editing this file, you have to restart the Akula Server.
In the properties.xml file, use the following predefined app properties to specify a list of sites that are allowed to access the Akula Server across origins:
Used as part of a response to the HTTP OPTIONS request to determine if access to the requested origin is allowed. If
Note that GET requests are not validated. Therefore, if a request is made for a resource with credentials, and if this header is not returned with the resource, the response is ignored by the browser and not returned to web content.
A space-delimited list of sites allowed to access the Akula Server. Specify a value of "*" to allow any site to access the Akula Server.
A comma-delimited list of custom headers that are whitelisted by the Akula Server to allow browsers to access.
|A comma-delimited list of the allowed HTTP request methods to the Akula Server. Method include: GET, POST, PUT, DELETE, HEAD, OPTIONS, and PATCH.|
A comma-delimited list of custom headers that can be used in cross-origin requests. A cross-origin request fails if it contains a custom header that is not listed by this property.
Many HTTP requests to the Akula Server pass a token in the headers that identifies an authenticated user to the server. The name of the header is
Before a browser allows a cross-origin request, it first sends an HTTP OPTIONS request to the destination site to determine if the destination supports the request. The browser then caches the response from the destination.
This property specifies the time, in seconds, before the cached response is cleared and the browser has to make another OPTIONS request to the destination.
The example below shows the default values of the
The following example shows a properties.xml file that lists three sites that can access the Akula Server using the HTTP GET, POST, PUT, DELETE, and OPTIONS methods:
display attributes of the
<akula-property> tag are optional and default to null. The
overridable properties are optional and have a default value of
true. In this example, you specify
false so that the property is not sent to the client on log in, and set
true so that the property can be set for an app scope. For more information on these attributes, see Using App Properties.
To allow any site to make a request to the Akula Server using any HTTP method, use the following settings: