• Migration Topics
  • Integration
  • Csvconnector
  • Concepts
  • Best Practices
    • Reverse Proxy for HIRO Desktop Development
  • Api
  • ActionHandler

Enabling local app development for HIRO Desktop

The HIRO API adheres to common web security standards. For browser-based applications, the HTTPS calls and response contain various security-related header attributes according to web security best practices.

A HIRO Desktop application is typically hosted on the HIRO server, served from the same URL (https://core.arago.co) as the HIRO API. During local application development, the application might be launched and tested locally on the developer’s PC. In such a case, the web security header attributes would indicate to the web browser that the requests are coming from a wrong origin and would block the application. These checks need to be bypassed for local application development.

Installing a local reverse proxy

It is recommended to use a local reverse proxy to modify the header attributes, so that the application runs in the browser correctly during development. In general, any reverse proxy can be used, given that it supports modification of HTTPS header attributes. As an example, we show below how this can be done with nginx. Feel free to use another reverse proxy instead.

Installation of nginx as reverse proxy: 1. Download the current (either mainline or stable) nginx version for your operating system from http://nginx.org/en/download.html 1. Unzip the nginx archive (zip or tar.gz) on your local PC 1. Modify the nginx.conf file in the “conf” sub folder as stated below 1. Run nginx locally (e.g. run “start nginx.exe” on Windows) 1. Now you can the configured local URL (e.g. “http://localhost:5080/” as graph URL in your HIRO Desktop app

In the example below, the URL http://localhost:5080 is forwarded to https://core.arago.co. The 'Access-Control-Allow-Origin' header attribute is set to '*' to let the browser accept the API responses. Please note that the “/_g” location needs a slightly different configuration to support websocket connections.

nginx reverse proxy configuration
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;

    server {
        listen       5080;
        server_name  localhost;

		location / {
			proxy_pass https://core.arago.co ;
			add_header 'Access-Control-Allow-Origin' '*' always;
			proxy_hide_header 'Access-Control-Allow-Origin';
		}

		location /_g {
			proxy_pass https://core.arago.co/_g ;
			proxy_hide_header 'Access-Control-Allow-Origin';
			proxy_http_version 1.1;
			proxy_set_header Upgrade $http_upgrade;
			proxy_set_header Connection "Upgrade";
		}
    }
}

Alternative: deactivate CORS check in browser

It is recommended to use the reverse proxy method described above. If for some reason it is not possible or not desired to run a local reverse proxy, there is a workaround available to temporarily deactivate the CORS check in your web browser via a plugin. For security reasons, we recommend using a second browser for this method, so that only the application under development is run without active CORS check. For example, if your main browser is Chrome, you may use Fire-fox to locally test the application, or vice versa. You may use, for example, the “CORS Everywhere” plugin for Firefox. As you can see in the screenshot in Figure 1, you may (and should) limit the plugin to a whitelist of URLs. Also the plugin is by default switched off after opening the web browser; it needs to be activated by pressing a button. At the next browser restart, the plugin is inactive again.

Screenshot of "CORS Everywhere" Firefox plugin settings
Figure 1. Screenshot of "CORS Everywhere" Firefox plugin settings
CORS browser plugin is disabled by default when the browser is opened
Figure 2. CORS browaer plugin is disabled by default when the browser is opened