Login: Access is forbidden

With Relution 26.4.0, the internal application server was switched from Undertow to Tomcat. If the reverse proxy (e.g. nginx or Traefik) runs on a different server than Relution itself, this can result in the following error during login:

The Relution server log shows a corresponding ERROR entry with the message TLS required.

Cause #

For a login to succeed, the connection between the reverse proxy and Relution must satisfy two conditions at the same time:

1. The reverse proxy must communicate with Relution from an IP address classified as internal. By default, only the private IPv4 ranges 10.x.x.x, 172.16.x.x–172.31.x.x and 192.168.x.x, as well as localhost, are considered internal.
2. The X-Forwarded-Proto header must be sent by the reverse proxy with the value https.

Only when both conditions are met does Tomcat treat the incoming connection as secured by TLS. If the reverse proxy runs on a separate server with its own (external) IP address, the first condition is already not met. If the X-Forwarded-Proto header is missing or incorrect in addition to or instead of this, the connection is likewise not recognized as secure. In both cases, Relution aborts the login with TLS required in the server log, while the browser shows the message Access is forbidden.

Confirming the cause (optional) #

To confirm the cause, DEBUG logging for the relevant Tomcat component can be enabled. To do this, add the following entry at the top level of the application.yml:

logging:
  level:
    org.apache.catalina.valves.RemoteIpValve: DEBUG

Afterwards, a new login attempt should be made. If an entry like the following then appears in the log, the reverse proxy’s IP address is the cause: the request is not classified as trustworthy.

DEBUG ... ina.valves.RemoteIpValve: Skip RemoteIpValve for request /api/device/v1/currentDevice/actions/next with originalRemoteAddr '<external-IP-of-the-proxy>' []

If this entry does not appear but the error still occurs, the missing or incorrect X-Forwarded-Proto header is the cause instead, see Solution →.

Solution #

Depending on which of the two conditions from the Cause section is not met, one of the following two adjustments is required — both if necessary.

Trust the reverse proxy’s IP address #

For Relution to accept the reverse proxy’s requests, its IP address must be explicitly registered as a trusted internal proxy. To do this, add the following entry at the top level of the application.yml:

server:
  tomcat:
    remoteip:
      internal-proxies: '<proxy-IP>|127\.\d{1,3}\.\d{1,3}\.\d{1,3}|0:0:0:0:0:0:0:1|::1'

<proxy-IP> must be replaced with the actual, dot-escaped IP address of the reverse proxy, e.g. 194\.95\.62\.71. For multiple proxy servers, additional IPs can be added, each separated by |.

Set the X-Forwarded-Proto header #

In addition, the reverse proxy must forward the X-Forwarded-Proto header with the value https to Relution. The location / block of the nginx configuration must contain the following line for this:

proxy_set_header X-Forwarded-Proto $scheme;

This line is already included in the default relution-nginx.conf template. When using a custom or modified reverse proxy configuration, or if there is an additional proxy in front of it, check whether the header is set correctly and is not overwritten by an upstream proxy.

After adjusting the application.yml or the reverse proxy configuration, the Relution service or container (and, if applicable, the reverse proxy) must be restarted for the change to take effect.

Temporary workaround #

If the reverse proxy configuration cannot be adjusted right away, the check for a secure connection can also be temporarily disabled on the server side. To do this, add the following entry at the top level of the application.yml:

relution:
  server:
    jwt-secure-flag-enabled: false

Additional notes #

• This issue primarily affects installations where the reverse proxy does not run on the same host as Relution.
• Relution installations from version 26.4.0 onwards are affected.
• The message Access is forbidden is a generic error message that is shown in the portal for a wide variety of requests rejected by the server. The solution described in this article only applies if the server log additionally shows the ERROR entry TLS required.
• See also: Docker installation - Optional: nginx →