Méfiance : Discourse en tant que fournisseur OpenID Connect

Greffon Suppléments
12

J’espère avoir quelques avis d’experts sur les problèmes que je rencontre en essayant d’utiliser Discourse comme fournisseur SSO.

Mon objectif : Je configure Discourse pour gérer l’authentification d’une autre application (LibreChat). J’utilise la fonctionnalité standard du fournisseur DiscourseConnect, avec le service de pont OIDC distrust agissant comme client qui communique avec Discourse.

Le problème : Le flux SSO fonctionne parfaitement jusqu’à la toute dernière étape. L’utilisateur est correctement redirigé de mon application vers Discourse, et il peut se connecter avec succès à ses identifiants Discourse. Cependant, après la connexion, il est redirigé vers la page d’accueil de mon forum Discourse (/) au lieu de l’return_sso_url qui avait été fournie.

Là où je bloque (Ce que j’ai écarté) : J’ai passé beaucoup de temps à résoudre ce problème et j’ai confirmé qu’il ne s’agissait pas d’une simple erreur de configuration. J’ai définitivement écarté les points suivants :

  • Secrets : Les secrets du fournisseur Discourse Connect sont correctement configurés. J’utilise le domaine brut (par exemple, auth.my-site.com) sans aucun protocole, et la clé secrète correspond parfaitement à celle de mon service client.
  • Mode SSO : J’ai vérifié que activer le fournisseur Discourse Connect est coché, et que les paramètres incorrects de « Client SSO » sont désactivés.
  • Politiques utilisateur : Je me suis assuré que must_approve_users est désactivé, et que mon utilisateur de test est un administrateur avec un e-mail entièrement vérifié.
  • Plugins : J’ai désactivé tous les plugins tiers non officiels et reconstruit le conteneur, mais le problème persiste.

Les preuves clés : J’ai deux preuves définitives qui me laissent perplexe :

  1. Analyse du fichier HAR : J’ai capturé l’intégralité du flux réseau dans un fichier HAR. Il montre que la requête POST vers /session pour la connexion réussit. Le serveur répond immédiatement avec une redirection 302 Found, mais l’en-tête Location est systématiquement /. Cela prouve que Discourse abandonne intentionnellement la redirection SSO.
  2. Journal Rails vide : J’ai ensuite suivi le fichier production.log à l’intérieur du conteneur lors d’une tentative de connexion. Absolument rien n’est écrit dans le journal pendant ce processus. Cela me dit que Discourse ne considère pas cela comme une erreur ; c’est une action délibérée et silencieuse.

Ma question : Étant donné que la connexion réussit, mais que la redirection est incorrecte et qu’il n’y a aucune erreur dans les journaux, quelle politique interne de Discourse, vérification préalable ou paramètre caché pourrait l’amener à ignorer le return_sso_url et à rediriger vers la page d’accueil à la place ? J’ai l’impression d’avoir épuisé tous les paramètres standards.

Merci d’avance pour toute idée !