Working with TigerGraph REST API and CORS (Cross Origin Resource Sharing)

Blog >
Working with TigerGraph REST API and CORS (Cross Origin Resource Sharing)

Every web browser follows the “Same-Origin Policy” to maintain system security, and reduce the possibilities of attack by malicious web scripts. Under the same-origin policy, a web page can only access the scripts that originate from the same domain, hostname, and port number. In simple words,

A webpage from ‘a.com’ can access scripts/resources from a.com/* but not from b.com, a.a.com, a.com:1111/

This policy is less restrictive for legacy web resources like images, but is full-on for fonts, javascripts, json loading, REST API calls, etc.

In TigerGraph’s context (Fig 1), any front end application, say D3, Power BI, Tableau or any other that would like to connect with RESTPP (the TigerGraph customized REST server) has to set up CORS headers for the “Same-Origin Policy” violations.

Let us look at a D3 application (browser based) trying to connect with a TigerGraph Cluster running on a different subdomain. Any attempt to connect, load and parse a JSON response from the Tigergraph REST API will lead to the following error (Fig 2) because an ‘Access-Control-Allow-Origin’ header is not present on the requested resource.

To overcome this challenge we need to change the header request from the Nginx server shipped with TigerGraph. The Nginx web server is included in and is used by the Tigergraph Platform (list of tigergraph core components).

Simple Example

1. The browser sends the OPTIONS request with an Origin HTTP header to the Tigergraph Nginx containing the domain that served the parent page:

Origin: http://www.example.com

2. If the headers are set correctly on Nginx, then TigerGraph service may respond with:

➡ An Access-Control-Allow-Origin (ACAO) header in its response indicating which origin sites are allowed. For example:
Access-Control-Allow-Origin: http://www.example.com
Since www.example.com matches the parent page, the browser then performs the cross-origin request.

➡ An Access-Control-Allow-Origin (ACAO) header with a wildcard that allows all domains:
Access-Control-Allow-Origin: *

➡ An error (Fig 2) if the server does not allow a cross-origin request

Adding Headers to Nginx Response

STEP 1: Call gadmin with command “gadmin –configure nginx.headers”

STEP 2: If you have no previous headers set you will be prompted with blank headers so type in {“Access-Control-Allow-Origin”: “*”}

Nginx.Headers[]: {“Access-Control-Allow-Origin”: “*”}

Test, and save these changes to TigerGraph configuration.

Here, you are giving access to any host to connect receive resources from the Nginx server. Alternately, you can allow only named origins, based on your security requirements, e.g. {“Access-Control-Allow-Origin”: “http://www.example.com“}

STEP 3: Apply Configuration Changes: “gadmin config-apply”

STEP 4: Restart Nginx: “gadmin restart nginx”

STEP 5: Execute the HTTP request using curl or a browser to verify your application can now access TigerGraph… Fig 3 or 4

This is an example of a simple CORS request. There can be ‘preflight’ requests, but they won’t differ in header settings for TigerGraph’s Nginx. Some headers for CORS are are listed here (source: Wikipedia):