Hilfe bei der Fehlerbehebung für mein Discourse SSO

Unterstützung
1

Hallo, ich hoffe, ich kann hier etwas Unterstützung erhalten. Mein SSO funktioniert diese Woche nicht mehr. Ich dachte, ich hätte gestern alles repariert (es hat funktioniert, ich schwöre :slight_smile: Hinweis: Ich habe mir die „Neuen Benutzer“ von gestern und heute angesehen, und an beiden Tagen gab es neue Benutzer (nachdem ich es repariert hatte), jetzt ist es wieder kaputt…). Leider funktionieren die von mir vorgenommenen Änderungen heute nicht.

Problem: Benutzer können keine neuen Konten erstellen, und Benutzer, die sich abmelden, können sich nicht wieder anmelden.

Ich habe festgestellt, dass mein Discourse-Server bei folgenden Routen 400-Fehler meldet:

403: GET : discourse-url/users/by-external/USER-ID.json?
Hinweis: Ich habe kürzlich in der API-Dokumentation festgestellt, dass diese Route nicht existiert? (obwohl sie funktioniert hat). Es sieht so aus, als wäre die Route: https://discourse.example.com/u/by-external/{external_id}.json

404: POST: discourse-url/admin/users/sync_sso?

Der Grund, warum das ?-Zeichen am Ende steht, ist, dass ich in einer Funktion, die URLs generiert, ein optionales Parameterfeld habe. Bei diesen beiden Routen werden alle Daten im Formular-Body oder in den Headern gesendet.

Ich verwende die folgende Bibliothek.

Was ich aktualisiert habe (und was ich dachte, das Problem zu lösen):

Bei allen meinen Anfragen habe ich den Api-Key und den Api-Username als Query-Parameter gesendet. In den letzten Monaten habe ich in meinem Admin-Bereich eine Warnung bemerkt, dass ich veraltete Header in meinen Anfragen verwende. Dieser Link führte mich zu diesem Beitrag, und die wichtigsten Details sind hier:

:warning: Veraltungswarnung!
Am 6. April 2020 haben wir die Unterstützung für alle Authentifizierungsmethoden außer HTTP-Headern eingestellt (mit Ausnahme einiger RSS-, E-Mail-Empfangs- und ICS-Routen). Das bedeutet, dass API-Anfragen, die api_key und api_username in den Query-Parametern oder im HTTP-Body enthalten, bald nicht mehr funktionieren werden. Bitte sehen Sie sich das unten stehende cURL-Beispiel an, um Ihre API-Anfragen so zu aktualisieren, dass sie die HTTP-Header zur Authentifizierung verwenden.

Ich habe alle meine Anfragen aktualisiert. Jetzt enthalten alle meine Anfragen den Api-Key und den Api-Username im Header, und der Content-Type ist auf multipart/form-data gesetzt.

Wenn jemand Ratschläge geben kann, worauf ich mich bei der Fehlersuche konzentrieren sollte, wäre ich sehr dankbar. Ich bin zu fast 100 % sicher, dass dies am Ende meines Arbeitstages gestern noch funktioniert hat. Ich konnte mich in mein Konto ein- und ausloggen und neue Konten erstellen.

Bitte lassen Sie mich wissen, wenn Sie weitere Informationen benötigen. Danke!

2

[quote=“sda, post:1, topic:155639”]
Ich habe alle meine Anfragen aktualisiert. Jetzt enthalten alle meine Anfragen den api_key und api_username im Header, und der Inhaltstyp ist auf „multipart form data

3

@simon, danke für die Antwort! Leider habe ich meinen Beitrag nicht gut dokumentiert. Ich verwende in meinen Anfragen bereits - und nicht _.

4

Um das Debugging zu starten, gehen Sie auf die Seite mit den Einstellungen Ihrer Discourse-Website und suchen Sie nach „sso“, um alle Ihre SSO-Einstellungen zu erhalten. Stellen Sie sicher, dass die Einstellungen „enable sso“, „sso url“ und „sso secret“ korrekt sind. Aktivieren Sie dann die Site-Einstellung „verbose sso logging“. Mit dieser aktivierten Einstellung werden einige zusätzliche Log-Einträge zu den Fehlerprotokollen Ihrer Website hinzugefügt (zu finden unter Admin / Logs / Error Logs).

Versuchen Sie, sich über SSO einzuloggen. Überprüfen Sie dann Ihre Fehlerprotokolle, um zu sehen, ob sie Ihnen Details zum Problem liefern. Wenn Sie nichts Nützliches sehen, öffnen Sie den Web-Inspector Ihres Browsers auf der Registerkarte „Network“ und aktivieren Sie das Kontrollkästchen „Preserve log“. Überprüfen Sie die getätigten Anfragen.

Sollten Sie sich beim Versuch, das Problem zu beheben, von Ihrer Website aussperren, können Sie als Administrator-User SSO umgehen, indem Sie zu /u/admin-login gehen und Ihre E-Mail-Adresse in das Formular eingeben. Ihnen wird eine E-Mail mit einem Login-Link zugesendet.

5

@simon, danke für den Tipp! Ich habe mir die Logs angesehen, bin aber nicht so erfahren im Lesen davon. Ich bekomme zwei verschiedene Arten von Warnungen und einen Fehler:

Hier ist die Warnung, die ich häufig bekomme:

Verbose SSO log: Started SSO process add_groups: admin: moderator: avatar_force_update: avatar_url: bio: card_background_url: email: external_id: groups: locale: locale_force_update: logo

Hier ist der Fehler:

Job exception: The difference between the request time and the current time is too large.

Wenn ich versuche, mich unter einem Testbenutzer auf meiner Seite einzuloggen, von dem ich mich bei Discourse ausgeloggt habe, erscheint in meinem Netzwerk-Panel Folgendes:

503 Service Unavailable: GET- https://my-site/auth/discourse_sso?sso=XXXX&sig=xxxx

Leider stoße ich hier auf eine Sackgasse und weiß nicht weiter.

6

Ich denke, diese Fehlermeldung stammt von Amazon S3. In diesem Thema finden Sie möglicherweise nützliche Details zur Behebung des Problems: Backups have started failing due to server time being wrong. Weitere Informationen finden Sie hier: https://stackoverflow.com/questions/4770635/s3-error-the-difference-between-the-request-time-and-the-current-time-is-too-la.

7

@simon danke für die Hilfe! Die Zeit auf meinem Server war nicht synchronisiert, das habe ich korrigiert, und jetzt funktionieren meine Backups wieder!

Jetzt bekomme ich sporadisch einen neuen Fehler:

Im Log-Bereich erhalte ich zufällig folgende Warnungen (ich habe sie nur zweimal erhalten):

MaxMindDB (/var/www/discourse/vendor/data/GeoLite2-City.mmdb) konnte nicht gefunden werden: No such file or directory @ rb_sysopen - /var/www/discourse/vendor/data/GeoLite2-City.mmdb

und

MaxMindDB (/var/www/discourse/vendor/data/GeoLite2-ASN.mmdb) konnte nicht gefunden werden: No such file or directory @ rb_sysopen - /var/www/discourse/vendor/data/GeoLite2-ASN.mmdb

Ich recherchiere gerade, wie ich dieses Problem beheben kann. Ich habe versucht, meine App neu zu erstellen, bin mir aber nicht zu 100 % sicher, ob der Neuaufbau erfolgreich war. Ich bekomme weiterhin zufällig die Fehlermeldung „MaxMindDB konnte nicht gefunden werden“ sowie die zuvor aufgetretenen 400- und 503-Fehler.

8

Ich habe den größten Teil des frühen Morgens damit verbracht, daran zu arbeiten, und habe nicht viel Fortschritt gemacht. Ich glaube, ich habe die MaxMindDB-Fehler beseitigt (sie waren zuvor sporadisch und inkonsistent; ich konnte sie in den letzten 3 Stunden nicht mehr reproduzieren), und ich habe meine App mehrmals erfolgreich neu aufgebaut.

Hier ist, wo die SSO-Pipeline abbricht:

  • Ein Benutzer besucht Discourse.
  • Da keine aktive Sitzung vorhanden ist, wird der Benutzer zu discourse/session/sso_login weitergeleitet.
  • Der Benutzer wird zu my-site/discourse_sso?sso=XXXX&sig=XXXX weitergeleitet.
  • Wenn die vorherige Route meiner Seite aufgerufen wird, sende ich eine GET-Anfrage an /users/by-external/userId.json.
    • Dies liefert einen 403 Forbidden-Fehler.
  • Unmittelbar danach wird eine POST-Anfrage an /admin/users/sync_sso gesendet.
    • Dies führt zu einem 404 "No route matches [POST] /admin/users/sync_sso-Fehler.
  • Schließlich gibt meine Seite eine 503 Forbidden-Meldung zurück (ich muss einige der Fehlermeldungen auf meiner Seite noch bereinigen).

Ich habe das Gefühl, dass der Fehler auf der Seite der Rails-Anwendung liegt (korrigiert mich bitte, falls ich falsch liege). Ein Grund für diese Annahme ist, dass am Freitagabend alles funktionierte. Es gibt Beweise dafür, da sich zwischen Freitagabend und Samstag einige neue Benutzer angemeldet haben (und das Anmelden oder Erstellen eines neuen Benutzers war das, was kaputt war). Wie ich in früheren Beiträgen erwähnt habe, dachte ich, ich hätte alles behoben, doch als ich am Samstag mit der Arbeit begann, stellte ich fest, dass es erneut nicht funktionierte.

9

Ich bin mir nicht sicher, warum Sie Anfragen an /users/by-external/<external_id>.json und /admin/users/sync_sso senden. Der übliche Ablauf wäre, den Benutzer einfach zu /session/sso_login weiterzuleiten, wobei die SSO-Nutzdaten als Abfrageparameter in der URL übergeben werden. Weitere Details dazu, wofür die Route sync_sso verwendet wird, finden Sie hier: Sync DiscourseConnect user data with the sync_sso route.

Eine Anfrage an /users/by-external/<external_id> mit einer external_id, die noch keinem Discourse-Benutzer zugeordnet ist, sollte einen 404-Fehler (nicht gefunden) zurückgeben. Wenn die external_id einem Discourse-Benutzer zugeordnet ist, sollte dieser Benutzer zurückgegeben werden.

10

@simon, Die Anfrage an /users/by-external/USER-ID.json dient dazu, zu prüfen, ob der Benutzer bereits ein Konto auf meinem Discourse hat. Wird ein Benutzer mit dieser ID gefunden, wird er über eine PUT-Anfrage an /admin/groups/groupId/members.json den für meine Seite relevanten Discourse-Gruppen hinzugefügt oder daraus entfernt und anschließend auf my-discourse/session/sso_login umgeleitet.

Falls der Benutzer kein Konto hat, wird dieses über einen POST-Request an /admin/users/sync_sso erstellt. Nachdem der Benutzer angelegt wurde (und den richtigen Discourse-Gruppen hinzugefügt wurde), wird er auf my-discourse/session/sso_login umgeleitet.

Ich werde mich darum kümmern und die von dir aufgeführten Dokumentationen erneut durchgehen (vielen Dank!). Dieser Ablauf läuft seit Anfang 2015 ohne jegliche Probleme (und Discourse sowie die SSO-Option waren für uns ein so wertvolles Werkzeug!), es ist also seltsam, dass er in der vergangenen Woche plötzlich nicht mehr funktioniert.

11

@simon Ich schätze deine Hilfe wirklich sehr! Ich habe das Problem behoben. Der von uns verwendete Api-Username wurde letzte Woche irgendwann „deaktiviert