Nous aurions besoin de clarification concernant le paramètre système AUTH_PROVIDERS, et plus précisément l’usage (ou non) du champ redirect_uri.
Dans notre cas, nous avons retiré le redirect_uri de la configuration dans le cadre d’un changement d’URL :
nous avions deux URLs actives simultanément, et le fait de supprimer ce champ nous a permis d’avoir une authentification plus dynamique, fonctionnelle sur les deux URLs sans devoir maintenir plusieurs configurations.
Fonctionnellement, cela semble bien marcher dans la majorité des cas.
En revanche, lorsque nous avons beaucoup d’activité batch, nous rencontrons ponctuellement l’erreur suivante :
SIMPLICITE|ERROR||http://mla-api-5b7cb899dc-ggvph:8080||ERROR|system|
com.simplicite.webapp.servlets.OAuth2Servlet|doGet||
Unknown OAuth2 state
Nos questions sont donc :
Le retrait de redirect_uri dans AUTH_PROVIDERS est-il officiellement supporté / recommandé ?
Est-ce que ce type de configuration peut entraîner des problèmes de gestion de l’état OAuth2 (state), notamment sous forte charge ou lors d’exécutions batch parallèles ?
Existe-t-il une bonne pratique pour gérer plusieurs URLs (ou un changement d’URL) sans provoquer ce type d’erreur ?
Merci d’avance pour vos retours et éclaircissements.
Avant tout il convient de commencer par vous mettre à jour car la révision 5.3.52 que vous utilisez date d’octobre 2024 et est totalement obsolète car en retard de presque 600 commits vs la révision actuelle de la v5 (5.3.81).
Il n’est vraiment pas possible d’apporter du support correctement avec un tel retard, sans parler des risques que vous prenez en vous privant des correctifs - notamment les correctifs de sécurité - apportés depuis 1 an et demi.
Ensuite, j’avoue ne pas être sûr de comprendre ce que signifie votre point sur les URLs, ni ce que vous entendez par “authentification plus dynamique”, ni ce que signifie concrètement dans votre cas une “activité batch” (= il faudrait nous préciser la manière dont vous exécutez ces traitements “batch” afin qu’on puisse voir en quoi cela pourrait avoir un rapport avec les procédures d’ident/authent)
En tout cas ne pas indiquer de redirect URI explicite est possible et résultera dans l’utilisation de la redirect URI par défaut à savoir ServletTool.getBaseRequestURL(request) + "/oauth2callback"
Dans une configuration usuelle (et particulièrementsi vous avez plusieurs instances/noeuds déployés sur des URLs de base différentes), c’est à priori la bonne stratégie moyennant, bien sûr, que le reverse proxy positionne les headers HTTP qui vont bien pour que le ServletTool.getBaseRequestURL retourne bien la bonne URL publique de l’instance.
PS: A noter qu’avec les révision récentes (backporté en 5.3.68 s’agissant de la v5) il est possible d’utiliser les substitutions de variables d’environnement [ENV:...] dans les paramètres système ce qui peut aussi permettre de gérer de la variabilité
Merci pour la réponse et les clarifications apportées sur le fonctionnement du redirect_uri par défaut et la configuration côté proxy.
Nous avons bien noté le retard de version : une montée vers la dernière révision 5.3 est prévue dans un premier temps, puis nous viserons également une migration vers la v6 dans un second temps.
De notre côté, nous poursuivons les investigations afin de mieux comprendre l’apparition ponctuelle de l’erreur, notamment en lien avec la charge et nos traitements batch.