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
- 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 - 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. Some headers for CORS are are listed here (source: Wikipedia):
Request headers
- Origin
- Access-Control-Request-Method
- Access-Control-Request-Headers
Response headers
- Access-Control-Allow-Origin
- Access-Control-Allow-Credentials
- Access-Control-Expose-Headers
- Access-Control-Max-Age
- Access-Control-Allow-Methods
- Access-Control-Allow-Headers
Preflight Request and Chrome Browser
Generally, there are no challenges with the preflight requests. But under certain security policies, Chrome is forced to send preflight requests to the server. This is totally legit, as the response from the RESTPP is a JSON application header (Content-Type: application/json). This header disqualifies the GET method (on RESTPP) to bypass the OPTIONS request.
To detect this case, you should run a curl command and see if that works, it should. Try ‘echo’, a built in endpoint.
curl -X GET http://yourtgserver:9000/echo -i
The response will tell you if the issue is with the browser/application or the TigerGraph server. An OK request should show you newly added headers.
“OK response” above proves, anyone that bypasses the preflight is working fine. Next step is to see if the OPTIONS header is enabled on the Nginx (default shouldn’t be)
curl -X OPTIONS http://yourtgserver:9000/echo -i
This will expose the issue: {“version”:{“edition”:”enterprise”,”api”:”v2",”schema”:7},”error”:true,”message”:”Endpoint is found for url = /echo but there is no corresponding ‘OPTIONS’ method for such endpoint, please check the method of this url.”,”code”:”REST-1000"}
Now all we need to do is allow OPTIONS on TigerGraph’s Nginx server; this will make the preflight work for Chrome (or Fiddler). We need changes in ngconf* files. I can’t put it here as the solution is too generic and may have performance impact if used in a wrong way. Please, reach out to the author, or the TigerGraph Chat (www.tigergraph.com) to get the workaround.
For more on the subject reach out to our developer community ; more developer blogs available here. Follow Author : Twitter , LinkedIn
