Nach einem heutigen Rebuild mit 3.3.3 (kürzlich veröffentlichte neueste stabile Version) funktionierte SSO nicht mehr. Angemeldete Benutzer sind vorerst in Ordnung, aber neue Sitzungen beenden den SSO-Flow mit dem Fehler:
Account login timed out, please try logging in again.
Die Aktivierung von verbose discourse connect logging zeigt:
Verbose SSO log: Nonce is incorrect, was generated in a different browser session, or has expired
Allerdings hat sich an unserem SSO-Flow in den letzten Jahren nichts geändert. Die Uhren zwischen den Servern sind synchron.
Andererseits haben wir kürzlich auf 3.3.3 (von 3.3.2) aktualisiert, was Sicherheitsfixes im Zusammenhang mit Discourse Connect enthält, die damit zusammenhängen könnten.
Unwahrscheinlich relevant, aber der Rebuild diente dazu, ein CDN zu aktivieren. Aber ich habe bereits alle diese Änderungen rückgängig gemacht und das SSO-Problem besteht weiterhin.
Irgendwelche Tipps, wie man das weiter debuggen kann?
Nach mehreren Neuerstellungen konnte ich SSO wieder zum Laufen bringen, indem ich es auf v3.3.2 zurückgesetzt habe. Es scheint also, dass etwas in v3.3.3 eingeführt wurde, das die SSO-Unterstützung beeinträchtigt hat.
Ich habe mir einen git diff v3.3.2 v3.3.3 kurz angesehen und nichts Auffälliges bemerkt, aber es gibt Änderungen, die sich auf Discourse Connect beziehen.
Ich vermute jedoch, dass dies mehr Leute betreffen wird, wenn sie auf 3.3.3 umsteigen und Benutzersitzungen ablaufen und nicht erneuert werden können. Vielleicht lohnt es sich, dass jemand, der den Code kennt, ihn genauer untersucht, insbesondere den SSO-Flow? /cc @sam
PS: Ich bin mir nicht sicher, ob es relevant sein könnte: Ich hatte vor über einem Tag auf 3.3.3 aktualisiert, aber die Probleme scheinen erst nach einem Neuerstellung über die Konsole vor einigen Stunden aufgetreten zu sein (um ein CDN zu aktivieren, aber die Rückgängigmachung hat SSO nicht behoben).
Ja, in dem Sinne, dass die meisten Leute den Tests-bestanden-Zweig ausführen, aber nein in dem Sinne, dass es die neueste Version im stabilen Zweig ist, die diese Woche veröffentlicht wurde: 3.3.3: Security and maintenance release
Es ist ein Versuch, aber generieren Sie die Nonce in einer anderen Browsersitzung, zum Beispiel indem Sie die SSO-Anfragen vom Backend Ihrer Anwendung aus stellen, anstatt Benutzer über Browser-Redirects den SSO-Prozess durchlaufen zu lassen?
Es gibt eine versteckte Website-Einstellung namens discourse_connect_csrf_protection, die standardmäßig aktiviert ist. Um SSO-Anfragen von außerhalb der Benutzersitzung zuzulassen, muss sie deaktiviert werden.
Ich gehe davon aus, dass diese Einstellung in Version 3.3.2 vorhanden war, aber möglicherweise wurde sie später hinzugefügt.
Nicht der Fall – wir haben eine ziemlich einfache Implementierung dessen, was in Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso) beschrieben wird, indem wir den Weiterleitungen folgen. Es funktioniert seit einigen Jahren reibungslos und wir haben nichts daran geändert.
Obwohl wir keine ungewöhnlichen SSO-Dinge tun, habe ich das trotzdem versucht, indem ich sie in der Rails-Konsole deaktiviert habe, und alles, was es für mich getan hat, war, die Fehlermeldung zu entfernen. In dem Sinne, dass, wenn der SSO-Anbieter zu Discourse zurückgeleitet wurde, anstelle des Fehlers Account login timed out, please try logging in again. keine Meldung (Fehler oder anderweitig) angezeigt wurde – aber leider immer noch abgemeldet.
Ich greife hier auch nach Strohhalmen, da dies ziemlich seltsam ist. Ich denke, die Tatsache, dass das Problem bei der anfänglichen Aktualisierung auf 3.3.3 über die Weboberfläche nicht auftrat, sondern erst (~36h) später nach einem Konsolen-Neubau, könnte ein Hinweis sein, aber ich weiß nicht genug über die Unterschiede zwischen den beiden.
Ich habe erneut auf 3.3.3 hochgestuft und das Problem trat sofort wieder auf. Ein Zurückwechseln auf 3.3.2 ließ SSO wieder funktionieren.
Ich vermute, dass das Problem hier nicht die DiscourseConnect-Sicherheitskorrektur ist, sondern die Nginx-Änderung. Auf tests-passed mussten wir am Donnerstag eine Nachbesserung vornehmen, da sie in einigen Umgebungen Probleme verursachte, und ein anderer Benutzer auf Github bemerkte CSRF-Probleme.
Ich freue mich, berichten zu können, dass dies den Trick gemacht hat!
Ich weiß es zu schätzen, dass Sie sich die Zeit genommen haben, sich das anzusehen, besonders am Wochenende und da sowohl stable als auch SSO etwas nischenhaft sind, aber hoffentlich wird es auch anderen helfen. Danke!
Ich werde die PR im Auge behalten, bis sie zusammengeführt wird.
