Ich arbeite an einer WordPress-Website, die mit einem Discourse-Forum verbunden ist und ungefähr 200.000 Benutzer hat.
Mithilfe der Plugins OAuth Single Sign On - SSO (OAuth client) und WP-Discourse verbinden wir die Beiträge von WP mit Discourse und lassen die Benutzer sich in WP mit ihrer WP-Benutzerinstanz anmelden, die sie dann auch bei Discourse anmeldet.
Nun ist ein Problem aufgetreten, immer wenn wir die Discourse-Einstellungen so setzen, dass keine Anmeldung erforderlich ist.
Dies sind unsere Schritte:
Der Benutzer meldet sich bei WordPress an.
Der Benutzer klickt auf einen Link, der zu Discourse führt (ein Thema, ein beliebiger Link, der zu Discourse führt).
==> Der Benutzer sieht nun Discourse so, als wäre er nicht angemeldet! Aber er ist angemeldet, sobald er sich bei WordPress angemeldet hat!
Nun klickt der Benutzer auf die Discourse-Anmeldung oder auf einen beliebigen Thema-Link.
Die Seite wird neu geladen und der Benutzer ist nun authentifiziert!
Uns wurde mitgeteilt, dass dies erwartet wird und dass wir Folgendes tun müssen:
Wenn der Benutzer angemeldet ist, müssen alle Links, die von WordPress zu Discourse führen, wie folgt aussehen: https://unsere-discourse-instanz.com/session/sso?return_path={ORIGINALE URL, AUF DIE WIR IN DISCOURSE VERWEISEN, wie eine Thema-URL oder Ähnliches}
Wenn ein Benutzer abgemeldet ist, dürfen wir direkt auf die {ORIGINALE URL, AUF DIE WIR IN DISCOURSE VERWEISEN, wie eine Thema-URL oder Ähnliches} verlinken, z. B. https://unsere-discourse-instanz.com/t/thema-slug
Ich vermute stark, dass dies der falsche Ansatz zur Lösung dieses Problems ist, weil:
Was ist, wenn ein Benutzer, während er bei Discourse angemeldet ist, eine Thema-URL kopiert und diese URL mit jemandem teilt, der ebenfalls bei WP/DIscourse angemeldet ist? Sie erhalten denselben Fehler wie oben in Nr. 2, da kein solcher URL-Suffix angehängt wird.
Warum muss sich ein angemeldeter Benutzer zu session/sso?return_path= weiterleiten lassen? Was ist die technische Begründung und Logik dahinter?
Warum wird das behoben, sobald der Benutzer die Seite neu lädt (ein Thema lädt, sich anmeldet usw.)?
Warum ist dies nicht weiter dokumentiert, wenn es der tatsächliche erwartete Ansatz wäre?
Warum würde dies nicht in der API erwähnt werden, wo wir jede Thema-URL aus Discourse abrufen können, und nirgends steht, dass angemeldete Benutzer nicht sofort auf den Inhalt zugreifen können und zuerst seltsame Neuladungen durchführen müssen oder dass wir seltsame URL-Parameter anhängen müssen, die tatsächlich nichts konvertieren?
Ich würde eine maßgebliche Meinung dazu sehr schätzen, weil ich überhaupt nicht davon überzeugt bin, dass dies das erwartete Verhalten ist!
Wenn ja, möchte ich Folgendes anfragen:
Warum dies tatsächlich notwendig ist und
was geplant ist, diesbezüglich zu tun (denn das ist sicherlich nicht ideal, siehe Punkt 1 meiner Gründe, warum dies nicht erwartet werden sollte)
Wenn Sie möchten, dass Ihre Benutzer automatisch zum Anmelden weitergeleitet werden, wenn sie einen beliebigen Pfad in Ihrem Forum aufrufen, müssen Sie die Einstellung login required aktivieren. Dies ist tatsächlich das erwartete Verhalten.
Auch wenn es sich immer noch seltsam anfühlt, habe ich die Weiterleitung zu session/sso?return_path= beim Benutzer-Login in WP vorgenommen.
Der Rückgabepfad, den ich festgelegt habe, ist der Referrer von WP (falls vorhanden) oder die WP-Homepage.
Das funktioniert hervorragend und stellt sicher, dass der Benutzer in beiden Instanzen angemeldet ist.
Ich musste die Einstellung in Discourse aktivieren, um „jeden Rückgabepfad“ zuzulassen, da Discourse standardmäßig „externe“ Rückgabepfade nicht zulässt.
Sehen Sie ein Problem bei der Aktivierung dieser Einstellung?
Vielen Dank nochmals für die freundliche Antwort und die „offizielle“ Bestätigung sowie den Dokumentationslink!
Normalerweise rate ich Kunden davon ab, eine solche automatische Weiterleitung vorzunehmen. Ich verstehe, warum Sie dies als Problem empfinden, es ist ein nicht ungewöhnliches Gefühl, aber der Standardansatz funktioniert für viele Websites, die so groß oder größer als Ihre sind, einwandfrei, und die automatische Weiterleitung funktioniert in einigen Szenarien möglicherweise nicht, was zu einer schlechten Benutzererfahrung führt.
Das von Ihnen erwartete „einmal anmelden, überall automatisch anmelden“ funktioniert bei miteinander verbundenen Diensten wie Meta (z. B. bei Facebook anmelden und Sie sind bei Instagram angemeldet) manchmal, da es sich um zentral verwaltete Plattformen handelt (obwohl selbst zentralisierte Dienste manchmal auf die gleiche Weise funktionieren, wie DiscourseConnect es tut).
Im Gegensatz dazu haben Sie es hier mit unabhängigen Open-Source-Software-Frameworks (d. h. WordPress und Discourse) zu tun. Sie können so eingerichtet werden, dass sie effektiv so funktionieren, wie Sie es erwarten, aber es erfordert spezifische kundenspezifische Arbeiten, die Ihren spezifischen Anwendungsfall berücksichtigen. Es wird niemals so funktionieren wie ein Authentifizierungssystem wie DiscourseConnect, das Tausende verschiedener Anwendungsfälle bedient.
Nein, mit der Einschränkung, dass ich die Prämisse, sie zu benötigen, in Frage stellen würde. Aber ohne weitere Informationen sehe ich kein Problem bei der Verwendung.
Könnte dies ein ungültiges Redirect-Risiko sein, wie hier beschrieben?
Ich kann sehen, wie „jeder Rückgabewert zugelassen“ tatsächlich überallhin umleitet.
Aber ich bin mir nicht sicher, ob dies wirklich ein Risiko wäre, da keine sensiblen Daten in oder an diese Redirect-URL weitergegeben werden.
Entschuldigung, das wäre eine Abweichung davon, Ihnen Ratschläge zu einem sensiblen Teil Ihrer Einrichtung zu geben, ohne sie selbst gesehen zu haben oder eine definierte Beziehung zu Ihnen zu haben.
Insbesondere angesichts der Größe Ihres Forums und der geltenden Vorschriften empfehle ich Ihnen, spezifischen, fundierten Rat zu dieser Frage einzuholen.
Ein Discourse-Forum aktiviert die Einstellung in Discourse, um „jeden Rückgabepfad“ zuzulassen.
Das bedeutet, dass Sie jetzt Ihr-Discourse.tld/session/sso?return_path=BELIEBIG besuchen können.
BELIEBIG kann eine externe URL sein.
Somit eröffnet sich eine Sicherheitslücke, zumindest könnte ein Phishing-Versuch inszeniert werden:
Eine bösartige Website erstellt einen Button mit der Aufschrift „Besuchen Sie die fantastische Community!“
Der Link des Buttons ist Ihr-Discourse.tld/session/sso?return_path=ZURÜCK ZUR BÖSARTIGEN SEITE
Der Benutzer klickt auf den Button, meldet sich in der Community an, was ihn zurück zur BÖSARTIGEN SEITE führt.
Dort hat der bösartige Akteur eine Seite implementiert, die genau wie die Community aussieht und sagt: „Beim Einloggen ist etwas schiefgelaufen, bitte versuchen Sie es erneut.“
Der Benutzer sendet ein gut aussehendes Login-Formular, das dem Aussehen der Community entspricht.
Hat der bösartige Akteur jetzt die Anmeldedaten abgefangen?
Daher sollte die Einstellung „jeder Rückgabepfad“ wahrscheinlich niemals für eine Website verwendet werden, auf der sich Benutzer anmelden, es sei denn, jeder einzelne Benutzer weiß genau, worauf er achten muss.
Würden Sie dieses Risiko auch sehen?
Warum könnten Discourse-Entwickler, die Plugins/Code erstellen, der mit dieser Einstellung interagieren kann, nicht einen Hinweis geben, ob dies „ja, kein Problem“ oder „auf keinen Fall“ ist?
Es gibt nicht viele Dinge, die sich in diesem URL-Parameter ändern können. Er ist entweder da oder nicht, er erlaubt entweder externe oder nicht.
Vielleicht stoße ich in einen Bereich vor, in den ich mich nicht einmischen sollte, im Sinne von „hier keine Sicherheitsprobleme diskutieren“? Das würde ich natürlich verstehen, viele Plattformen erlauben es nicht, offen über potenzielle Sicherheitsprobleme zu sprechen, die nicht klar definiert sind, wenn sie aktiviert werden
Ich glaube, Sie haben Ihre eigene Frage bereits beantwortet.
Da die Valenz von Einstellungen davon abhängt, wie sie verwendet werden, sind sie tatsächlich Einstellungen und nicht nur „Funktionen“. Wenn es eine einfache Antwort auf Ihre Frage gäbe, gäbe es die Einstellung gar nicht erst.
Ich schätze, diese etwas juristische Antwort ist frustrierend. Aber Sie benötigen eine Beratung, die auf Ihren Anwendungsfall zugeschnitten ist und die ich Ihnen hier nicht geben kann.
