Connexion : L'accès est interdit

Avec Relution 26.4.0, le serveur d’application interne est passé d’Undertow à Tomcat. Si le reverse proxy (par exemple nginx ou Traefik) s’exécute sur un serveur différent de celui de Relution, cela peut entraîner l’erreur suivante lors de la connexion :

Le journal du serveur Relution affiche alors une entrée ERROR correspondante avec l’indication TLS required.

Cause #

Pour qu’une connexion soit possible, la liaison entre le reverse proxy et Relution doit remplir deux conditions simultanément :

1. Le reverse proxy doit communiquer avec Relution depuis une adresse IP considérée comme interne. Par défaut, seules les plages IPv4 privées 10.x.x.x, 172.16.x.x–172.31.x.x et 192.168.x.x, ainsi que localhost, sont considérées comme internes.
2. L’en-tête X-Forwarded-Proto doit être envoyé par le reverse proxy avec la valeur https.

Ce n’est que si les deux conditions sont remplies que Tomcat considère la connexion entrante comme sécurisée par TLS. Si le reverse proxy s’exécute sur un serveur distinct avec sa propre adresse IP (externe), la première condition n’est déjà plus remplie. Si l’en-tête X-Forwarded-Proto est en plus, ou à la place, manquant ou incorrect, la connexion n’est pas non plus reconnue comme sécurisée. Dans les deux cas, Relution interrompt la connexion avec TLS required dans le journal du serveur, tandis que le navigateur affiche le message L'accès est interdit.

Confirmer la cause (optionnel) #

Pour confirmer la cause, la journalisation DEBUG du composant Tomcat concerné peut être activée. Pour cela, ajouter l’entrée suivante au niveau supérieur du fichier application.yml :

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

Une nouvelle tentative de connexion doit ensuite être effectuée. Si une entrée telle que la suivante apparaît alors dans le journal, l’adresse IP du reverse proxy est la cause : la requête n’est pas considérée comme fiable.

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

Si cette entrée n’apparaît pas mais que l’erreur persiste, la cause est plutôt l’en-tête X-Forwarded-Proto manquant ou incorrect, voir Solution →.

Solution #

Selon celle des deux conditions de la section Cause qui n’est pas remplie, l’une des deux adaptations suivantes est nécessaire — les deux si besoin.

Déclarer l’IP du reverse proxy comme fiable #

Pour que Relution accepte les requêtes du reverse proxy, son adresse IP doit être explicitement déclarée comme proxy interne fiable. Pour cela, ajouter l’entrée suivante au niveau supérieur du fichier application.yml :

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

<IP-du-proxy> doit être remplacé par l’adresse IP réelle du reverse proxy, avec les points échappés, par exemple 194\.95\.62\.71. Pour plusieurs serveurs proxy, d’autres IP peuvent être ajoutées, chacune séparée par |.

Le fichier application.yml contient généralement déjà d’autres entrées, par exemple pour l’administrateur système, l’URL externe ou la connexion à la base de données. La nouvelle entrée server constitue une clé de premier niveau distincte, à côté du bloc relution existant, et non un sous-élément de celui-ci — même si une section également nommée server existe sous relution (avec, par exemple, externalURL). L’exemple suivant présente un fichier complet contenant les deux blocs :

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

relution:
  system:
    admin:
      password: %SYSTEM_ADMIN_PASSWORD%
      email: %SYSTEM_ADMIN_EMAIL%
  server:
    externalURL: %EXT_HOSTNAME_URL%
  database:
    type: mariadb
    # Adjust hostname in the url if the database runs outside docker compose
    url: jdbc:mariadb://mariadb/relution?useServerPrepStmts=true
    username: relution
    password: %MYSQL_PASSWORD%

Définir l’en-tête X-Forwarded-Proto #

Le reverse proxy doit en outre transmettre à Relution l’en-tête X-Forwarded-Proto avec la valeur https. Le bloc location / de la configuration nginx doit pour cela contenir la ligne suivante :

proxy_set_header X-Forwarded-Proto $scheme;

Cette ligne est déjà incluse dans le modèle standard relution-nginx.conf. En cas de configuration de reverse proxy personnalisée ou modifiée, ou si un autre proxy se trouve en amont, il convient de vérifier que l’en-tête est correctement défini et n’est pas écrasé par un proxy en amont.

Après avoir adapté le fichier application.yml ou la configuration du reverse proxy, le service ou le conteneur Relution (et, le cas échéant, le reverse proxy) doit être redémarré pour que la modification prenne effet.

Remarques complémentaires #

• Ce problème concerne en premier lieu les installations dans lesquelles le reverse proxy ne s’exécute pas sur le même hôte que Relution.
• Les installations Relution à partir de la version 26.4.0 sont concernées.
• Le message L'accès est interdit est un message d’erreur générique, affiché dans le portail pour de nombreuses requêtes rejetées par le serveur. La solution décrite dans cet article ne s’applique que si le journal du serveur affiche en plus l’entrée ERROR TLS required.
• Voir aussi : Installation Docker : Nginx comme alternative à Traefik →