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. To do so, you specify the list of sites allowed to access the Akula Server across origins. This technique is referred to as Cross-Origin Resource Sharing (CORS).

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 properties to specify a list of sites allowed to access the Akula serve 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 `true`, it indicates that the actual request can be made using credentials, such as cookies, HTTP authentication, and client-side SSL certificates. If `false`, the actual request is made without credentials. 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 `X-Ak-Session-Id` and should be included in the list of supported headers.
`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 isClientProperty, overridable, and type attributes for the cross origin request properties. Do not modify the isClientProperty, overridable, and type attributes of an "akula_" app property from their default values. The Akula Server has an internal representations of these attributes that will not be valid (or respected) if the attributes are changed.

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 Defining App Properties.

To allow any site to make a request to the Akula Server using any HTTP method, use the following settings:

0 Comments

Hide/Show Comments

You must log in to comment.

Documentation 1.0.1

Related Topics

Labels

Documentation Downloads

All Versions

Allow Cross Origin Requests in a Browser App

Cross origin request to the Akula Server

Configuring cross origin requests

0 Comments