Misstrauen: Discourse als OpenID Connect-Anbieter

Plugin Extras
12

Ich hoffe, einige Expertenaugen auf die Probleme zu werfen, mit denen ich konfrontiert bin, während ich versuche, Discourse als SSO-Anbieter zu verwenden.

Mein Ziel: Ich richte Discourse ein, um die Authentifizierung für eine andere Anwendung (LibreChat) zu handhaben. Ich verwende die Standardfunktionalität des DiscourseConnect-Anbieters, wobei der OIDC-Bridge-Dienst distrust als Client fungiert, der mit Discourse kommuniziert.

Das Problem: Der SSO-Flow funktioniert perfekt bis zum allerletzten Schritt. Der Benutzer wird korrekt von meiner App zu Discourse weitergeleitet und kann sich erfolgreich mit seinen Discourse-Anmeldeinformationen anmelden. Nach der Anmeldung wird er jedoch zu meiner Discourse-Forum-Homepage (/) weitergeleitet und nicht zur angegebenen return_sso_url.

Wo ich feststecke (Was ich ausgeschlossen habe): Ich habe dies eine Weile lang behoben und bestätigt, dass es sich nicht um einen einfachen Konfigurationsfehler handelt. Ich habe Folgendes definitiv ausgeschlossen:

  • Secrets: Die discourse connect provider secrets sind korrekt konfiguriert. Ich verwende die reine Domain (z. B. auth.my-site.com) ohne Protokoll, und der geheime Schlüssel stimmt perfekt mit dem in meinem Client-Dienst überein.
  • SSO-Modus: Ich habe bestätigt, dass enable discourse connect provider aktiviert ist und die falschen “SSO Client”-Einstellungen deaktiviert sind.
  • Benutzerrichtlinien: Ich habe sichergestellt, dass must_approve_users deaktiviert ist, und mein Testbenutzer ist ein Administrator mit einer vollständig verifizierten E-Mail-Adresse.
  • Plugins: Ich habe alle nicht-offiziellen Plugins von Drittanbietern deaktiviert und den Container neu erstellt, aber das Problem besteht weiterhin.

Die wichtigsten Beweise: Ich habe zwei definitive Beweise, die mich ratlos machen:

  1. HAR-Datei-Analyse: Ich habe den gesamten Netzwerkfluss in einer HAR-Datei erfasst. Sie zeigt, dass die POST-Anfrage an /session für die Anmeldung erfolgreich ist. Der Server antwortet sofort mit einem 302 Found-Redirect, aber der Location-Header ist durchweg /. Dies beweist, dass Discourse den SSO-Redirect absichtlich abbricht.
  2. Leeres Rails-Log: Ich habe dann die Datei production.log im Container verfolgt, während ich einen Login versucht habe. Während dieses Vorgangs wird absolut nichts in das Log geschrieben. Das sagt mir, dass Discourse dies nicht als Fehler betrachtet; es ist eine bewusste, stille Aktion.

Meine Frage: Angesichts der Tatsache, dass die Anmeldung erfolgreich ist, aber der Redirect falsch ist und keine Fehler in den Logs vorhanden sind, welche interne Discourse-Richtlinie, Vorabprüfung oder versteckte Einstellung könnte dazu führen, dass die return_sso_url ignoriert und stattdessen zur Homepage weitergeleitet wird? Ich habe das Gefühl, dass ich alle Standardeinstellungen ausgeschöpft habe.

Vielen Dank im Voraus für alle Ideen!