Using the Neuron® as a reverse proxy
From Build 2024-03-21 you can now use the Neuron® as a reverse proxy. Reverse proxies are defined in the gateway.config file. You can edit this file if you are connected to the Neuron® and have administrative privileges (i.e. receive notifications of important events on the Neuron®).
You setup a reverse proxy on the Neuron® by adding a Reverse Proxy node to the Web Server node:
Setup the reverse proxy, by providing the name of the local resource, that will be mapped to the remote web server. The remote domain points to the domain of the remote server. You can optionally add a remote folder if the content in question lies in a special sub-folder on the remote server. You also need to specify if encryption is to be used (i.e. HTTPS) when the Neuron® connectos to the remote web service, or if unecrypted communication is to be used (i.e. HTTP). Also provide the port number to use when connecting to the remote web service.
Note: Important to note here, is the checkbox is the proxy should be session-aware or not. If the reverse proxy is session-aware, it will also have access to the current user session with the Neuron®. If the user is logged in to the Neuron®, the proxy will therefore have access to this login-information. If the proxy finds such user information in the session, it generates a JWT-token for it, and fowards it to the remote web server in an Authorization: Bearer header. This allows the remote service to gain access to this login-information, and base its authorization evaluations on this login, instead of having to force the user to login separately for each remote web service that is being used. You can find more about this, in the article: Configuring Single Sign-On (SSO) on a Neuron®
Once the node has been configured properly, the gateway.config file and data source is updated accordingly.
Note: The reverse proxy is still not activated. You will need to restart the Neuron® for the reverse proxy to become activated.
Note 2: Be careful in your definition of reverse proxies, to avoid creating race conditions and infinite loops. If you want to crash your server, it’s easier to just shut it down.
Note 3: You can test the above reverse proxy, by navigating to https://lab.tagroot.io/labproxy/.
Note 4: Remote services that are to be accessed via a reverse proxy, needs to be developed correctly for this to be possible. The service must avoid use of absolute URIs or URI’s pointing to the remote web servers root folder (i.e. beginning using a / character). The client does not know the service is hosted on multiple web servers, and only sees the URI as provided by the remote web server. If the URI is absolute, or begins with a /, clicking on the link will navigate to a page that is no longer on the reverse proxy (most probably) since the remote web server does not know the local resource name of the reverse proxy. To solve this, always use relative URIs in remote services.
Note 5: On the other hand, a service that is designed not to be user behind a reverse proxy, should use absolute URIs or URIs beginning with a / characters, as this invalidates any future navigation. You can try the https://lab.tagroot.io/google/ reverse proxy, which forwards requests to Google. To solve this, you simply add multiple reverse proxy node definitions in gateway.config, one for each root resource you want to forward to the remote web server.