Soweit ich weiß, wurde das gleiche Problem bereits zweimal erwähnt und es wurde behauptet, es sei 2018 (Discourse doesn't redirect to return_sso_url after user logs in on private site) und 2015 (Login redirect during sso provider login) behoben worden. Dennoch bin ich immer noch mit demselben Problem konfrontiert.
Wir haben in unserer Organisation eine Discourse-Instanz installiert. Da wir über eine eigene Benutzerkonten-Datenbank verfügen, nutzen wir unsere selbst entwickelte SSO-Login-Website, um Benutzern die Anmeldung bei Discourse zu ermöglichen, gemäß den Anweisungen unter Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso). Das funktioniert einwandfrei.
Darüber hinaus nutzen wir WordPress, Rocket Chat und eine selbst entwickelte Tornado-Webanwendung. Diese Anwendungen sind darauf angewiesen, dass Discourse als SSO-Anbieter fungiert.
Für WordPress verwenden wir wp-discourse. Für Rocket Chat und die Tornado-Webanwendung haben wir die Anweisungen unter Use Discourse as an identity provider (SSO, DiscourseConnect) befolgt.
Der Anmeldevorgang funktioniert einwandfrei, wenn der Benutzer bereits bei Discourse angemeldet ist. Wenn der Benutzer jedoch noch nicht bei Discourse angemeldet ist, funktioniert der Anmeldevorgang für keine der Dienste (z. B. WordPress, Rocket Chat oder die Tornado-Webanwendung) ordnungsgemäß. Wenn ein Benutzer versucht, sich bei WordPress, Rocket Chat oder der Tornado-Webanwendung anzumelden, wird er zu discourse.com/login weitergeleitet. Anschließend klickt der Benutzer auf die Anmeldeschaltfläche, woraufhin er zu unserer benutzerdefinierten SSO-Website weitergeleitet wird. Dort führt er eine Anmeldung durch, danach wird er zwar zu discourse.com weitergeleitet, aber nicht zum gewünschten Dienst (z. B. WordPress, Rocket Chat oder die Tornado-Webanwendung).
Nebenbei bemerkt: Die Funktion „Sync Logout with Discourse" von wp-discourse funktioniert nicht. Wenn sich ein Benutzer von WordPress abmeldet, bleibt er bei Discourse angemeldet.
Ich stecke seit mehreren Monaten, trotz mehrerer Discourse-Updates, in diesem Problem fest. Nun suche ich nach Hilfe. Bitte teilen Sie mir mit, falls weitere Details benötigt werden.
Meine aktuelle Workaround-Lösung besteht darin, den Benutzer nicht zu /session/sso_provider, sondern zu /session/sso?return_path=customurl weiterzuleiten. Der Nachteil ist, dass der Benutzer stets aufgefordert wird, sich anzumelden, selbst wenn er bereits bei Discourse angemeldet ist.