Nous utilisons une app Service Azure pour déployer une nouvelle plaftorme ou sera hébergée notre application simplicité. Nous sommes au courant qu’il existe une commande pour forcer l’écriture de l’url du server : -e SERVER_URL=<a custom public URL>, cependant cette Url custom n’apparait pas dans la barre. A la place il est indiqué l’Url de l’appService Azure, dont le nom n’est pas digeste, comme si cette commande ne fonctionnait pas.
Actuellement nous faisons la modification de l’adresse à la main, en mappant l’url de l’AppService avec notre adresse custom dans le dns, ce qui implique beaucoup de modifications non automatisées.
Existe-t-il une variable configurable simplicité qui pourrait outre-passer la commande docker et résoudre notre problème de nom d’url ? Sinon est-ce que cette commande à évolué avec les versions?. Nous sommes en 5.2.26
Dans une configuration nominale il n’y a pas besoin de forcer une URL “publique”, c’est le rôle du reverse proxy de la transmettre à Tomcat (ce qui, au passage, permet d’exposer l’application sur plusieurs URLs).
Il faudrait donc d’abord comprendre pourquoi votre reverse proxy ne fait pas son travail.
Ensuite seulement, s’il n’y pas de solution nominale (i.e. transparente pour Simplicité), il reste la possibilité d’indiquer une URL “en dur” à Simplicité pour que celui-ci l’utilise dans les cas où il doit faire des redirects ou autre.
Il y a plusieurs mécanismes pour cela, notamment le fait de positionner la variable d’environnement SERVER_URL sur le container Docker, ce qui se traduit par le positionnement de la property JVM -Dapplication.url au démarrage de Tomcat.
Il y a peut être des cas particuliers où cette URL forcée n’est pas prise en compte. J’aurais donc besoin que vous me décriviez très précisément à quelle moment l’URL se substitue.
Pour cela le bon outil c’est la console de votre navigateur, dans l’onglet “Network” en traquant de près les redirects HTTP dans les réponses, ex:
Mais j’insiste sur le fait que forcer une URL est un “dirty workaround” qui compense forcément un pb de configuration de votre infrastructure, ce n’est donc pas la bonne solution au problème.
Est-ce possible de savoir quelles headers sont utilisés pour calculer les URL ?
Host ou X-Forwarded-Host ?
Puisque que quand on se rend sur example-host.fr, cela nous redirige vers wa-<app_service_name>.azurewebsites.net sachant que les fowards headers sont bien passés…
Je travaille avec @ewencodes et ClementRudelle sur cette problématique
En complément de la question posée par @ewencodes (à laquelle la réponse nous sera très utile pour comprendre le fonctionnement de Simplicité à ce niveau), voici quelques compléments d’infos sur pourquoi nous en venons envisager cette solution.
Nous utilisons des App Services Azure + un Azure App Gateway comme reverse proxy.
Or, by design, l’App Service Azure doit recevoir ses requêtes avec le header “host” en “wa-<app_service_name>.azurewebsites.net”
Il y a bien un mécanisme de “custom domain” pour utiliser un nom de domaine au choix sur un App Service, mais elle n’est pas adaptée pour être utilisée derrrière un reverse proxy (cela nous oblige à plusieurs opérations manuelles, alors que nous déployons en “infra-as-code”)
Nous sommes donc pris entre le “marteau” App Service et “l’enclume” Simplicité, qui semble calculer les URL de son contenu à partir des headers dans la requête (mais reste à éclaicir lesquels, comme demandé par Ewen)
La bonne solution est donc à chercher du coté du marteau, j’imagine que vous avez fait la demande à Azure pour vous aider à simplifier les choses dans votre cas d’utilisation particulier.
En attendant, coté enclume nous offrons la possibilité d’indiquer une URL “publique” via les divers mécanismes (var env, argument JVM, param système).
Historiquement ça servait uniquement à faire connaitre l’URL publique à des processus background (ex: tâches cron) qui n’étant pas appelés via HTTP ne pouvaient pas la retrouver tous seuls.
Ensuite, cette valeur a été progressivement utilisée dans d’autres cas de construction d’URLs , mais pas dans tous les cas.
C’est là où j’ai besoin de savoir exactement à quel moment un redirect bascule sur l’URL non souhaitée dans votre cas. Cf. mon post précédent c’est à tracker dans la console du navigateur.
Un autre partenaire nous a récemment sollicité (sur une catégorie privée du forum) au sujet du redirect_uri de la connexion via OpenIDConnect vs un reverse proxy qui ne faisait pas non plus son boulot correctement. Dans son cas c’était un pb de port public non transmis par le reverse proxy mais ça doit aussi être applicable à un pb de hostname.
Est-ce que ce ne serait pas ce cas là aussi pour vous ? Je veux dire que le “redirect” qui vous envoie sur une URL non souhaitée c’est celle de retrour suite à une authent externe OIC ?
Auquel cas la solution est de mettre aussi un redirect_uri en dur dans la conf du provider (dans le param système AUTH_PROVIDER)
Le moment où nous avons le problème est la redirection de example.com/ui/ vers example.com/oauth2callback?redirect_uri= qui lui nous redirige vers le fqdn de l’app service (wa-…azurewebsites.net) alors qu’il devrait nous rediriger vers example.com/oauth2callback.
Dans notre cas, l’url de redirect_uri est le fqdn de l’App Service. (wa-…azurewebsites.net).
Pour ce qui est de SERVER_URL, même placé Simplicité utilise toujours le fqdn de l’App Service pour calculer les URL (qui provient sûrement du header Host).
PS : Dans votre exemple, vous redéfinissez le header Host ce qui ne doit pas être fait sachant que ce header sert a savoir le hostname requêté.
Il faut donc déterminer précisément à quel moment une URL n’est pas construite comme vous le voudriez
On va donc commencer par là => quel type d’ident / authent utilisez vous ?
Mais si vous êtes en ident/authent externe, c’était mon hypothèse, relisez une de mes réponse précédente c’est sans doute par là que ça se passe, je cite:
Auquel cas la solution est de mettre aussi un redirect_uri en dur dans la conf du provider (dans le param système AUTH_PROVIDER )
