Documentation 3.0 Beta
Related Topics

Labels
Documentation Downloads
All Versions
Beta Documentation Version 3.0
NOTE: You are currently viewing the Beta version 3.0 of the Akula documentation.
View the current version of this page or go to the current documentation home page. |
Allow Cross Origin Requests in a Browser App
A client app written using the Akula Client SDK for JavaScript runs in a browser on a mobile device. Browsers enforce a cross-origin policy which means that a script running on a page originating from one site is only allowed to access scripts on other pages originating from that same site. The script cannot access a script on a page originating from a different site.
![]() | For two sites to be considered to be matching, the protocol (such as HTTP), hostname, and port number must match. |
For example, you serve a web page containing JavaScript from the site http://publicSite.com. That page can then access scripts on other pages originating from http://publicSite.com. However, if the page attempts to access a script on a page located at http://myServer.com, the browser prohibits the request.
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
You can run into the cross-origin policy issue when using the Akula JavaScript SDK to write a client app that runs in a browser on a mobile device. For example, your environment deploys the Akula Server at http://myServer.com/akula. However, your public facing web site that serves the app is located at http://publicSite.com. Therefore, because of the cross-origin policy restrictions in a browser, the client app cannot access JavaScript served by http://myServer.com/akula.
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-Id
to the list of supported headers in theakula_cors_supportedHeaders
property.- 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:
Property | Use |
---|---|
akula_cors_allowCredentials | 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. |
akula_cors_allowOrigin | 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. |
akula_cors_exposedHeaders | A comma-delimited list of custom headers that are whitelisted by the Akula Server to allow browsers to access. |
akula_cors_supportedMethods | A comma-delimited list of the allowed HTTP request methods to the Akula Server. Method include: GET, POST, PUT, DELETE, HEAD, OPTIONS, and PATCH. |
akula_cors_supportedHeaders | 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 |
akula_cors_maxAge | 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:
The description
and display
attributes of the <akula-property>
tag are optional and default to null. The isClientProperty
and overridable
properties are optional and have a default value of true
. In this example, you specify isClientProperty
as false
so that the property is not sent to the client on log in, and set overridable
to 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: