• Home
  • Getting Started
  • Documentation
  • API References
  • Downloads
  • Support
Verivo
DevCenter
  • Welcome, Anonymous
  • |
  • Log in
  1. 1.0.1 Documentation
  2. Installing and Configuring the Akula Server
  3. Configuring the Akula Server
  4. Allow Cross Origin Requests in a Browser App
Printable version    

Documentation 1.0.1

Related Topics

Page: Allow Cross Origin Requests in a Browser App
Page: App Property Management REST API
Page: Remote Data Access from JavaScript Clients
Page: Using the Client SDKs
Page: Handling Exceptions and Errors
Page: Synchronous and asynchronous requests
Page: Configuring the Client Development Environment
Page: Working With the Request
Page: Getting HTTP Query String Parameters
Page: Getting Request Path Parameters
Page: Getting HTTP Headers
  

Labels

  • administration
  • javascript
  • cors
  • http_request

Documentation Downloads

  • Installing and Configuring Akula
  • Building Akula Apps
  • Release Notes

All Versions

Latest Official Version (2.5)
Version 3.0 Beta
Version 2.5
Version 2.1
Version 2.0
Version 1.5
Version 1.0.1
Your Rating: Thanks for voting! Please Wait Please Wait Results: PatheticBadOKGoodOutstanding! 2 rates
Define Akula Server Administrators      Configure Logging
Documentation Version 1.0.1
NOTE: You are currently viewing version 1.0.1 of the Akula documentation.

View the latest 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. 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:

PropertyUse
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_supportedMethodsA 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.
 
Define Akula Server Administrators      Configure Logging
  • Last edited by mhorn@verivo.com on 2013-10-24 18:50:10.0

  • Privacy Policy | Legal Information
    © Copyright 2014, Verivo Software, Inc. All Rights Reserved.