DiscourseConnect einrichten – Offizielles Single-Sign-On für Discourse (sso)

Discourse · 25. Februar 2014 um 08:30

DiscourseConnect ist eine Kernfunktion von Discourse, mit der Sie „Single Sign-On (SSO)“ konfigurieren können, um die gesamte Benutzerregistrierung und -anmeldung von Discourse vollständig auf eine andere Site auszulagern. Verfügbar für unsere Pro-, Business- und Enterprise-Hosting-Kunden.

(Februar 2021) „Discourse SSO“ heißt jetzt „DiscourseConnect“. Wenn Sie eine alte Version von Discourse verwenden, heißen die Einstellungen unten sso_... statt discourse_connect_....

Das Problem

Viele Sites, die sich mit einer Discourse-Site integrieren möchten, wollen die gesamte Benutzerregistrierung auf einer separaten Site halten. In einem solchen Setup sollten alle Anmeldevorgänge auf diese andere Site ausgelagert werden.

Was ist, wenn ich SSO in Verbindung mit einer bestehenden Authentifizierung nutzen möchte?

Die Absicht hinter DiscourseConnect ist es, die Discourse-Authentifizierung zu ersetzen. Wenn Sie einen neuen Anbieter hinzufügen möchten, sehen Sie sich bestehende Plugins an, wie zum Beispiel: Discourse VK Authentication (vkontakte)

Aktivierung von DiscourseConnect

Um DiscourseConnect zu aktivieren, müssen Sie drei Einstellungen ausfüllen:

enable_discourse_connect: Muss aktiviert sein (globaler Schalter).
discourse_connect_url: Die externe URL, zu der Benutzer weitergeleitet werden, wenn sie sich anmelden möchten.
discourse_connect_secret: Ein geheimer String, der zum Hashen von SSO-Payloads verwendet wird. Stellt sicher, dass die Payloads authentisch sind.

Sobald enable_discourse_connect auf true gesetzt ist:

Das Klicken auf „Anmelden“ oder das Avatar-Bild leitet Sie auf /session/sso um, was wiederum die Benutzer mit einer signierten Payload auf discourse_connect_url weiterleitet.
Benutzern wird nicht erlaubt, ihr „Passwort zu ändern“. Dieses Feld wird aus dem Benutzerprofil entfernt.
Benutzer können die Discourse-Authentifizierung (Benutzername/Passwort, Google usw.) nicht mehr verwenden.

Was ist, wenn ich es versehentlich aktiviere?

Siehe: Log back in as admin after locking yourself out with read-only mode or an invalid SSO configuration

Implementierung von DiscourseConnect auf Ihrer Site

Discourse verwendet E-Mail-Adressen, um externe Benutzer Discourse-Benutzern zuzuordnen, und geht davon aus, dass externe E-Mails sicher sind. WENN SIE E-MAIL-ADRESSEN NICHT VOR DEM SENDEN AN DISCOURSE VALIDIEREN, IST IHRE SITE EXTREM ANFÄLLIG!

Alternativ, wenn Sie darauf bestehen, nicht validierte E-Mails zu senden, STELLEN SIE SICHER, dass Sie require_activation=true setzen. Dies erzwingt, dass alle E-Mails von Discourse validiert werden. WIR RATEN IMMER NOCH DRINGEND DAVON AB, DIESES VORZUGEN. Wenn Sie also mit dieser Einstellung fortfahren, gehen Sie ein erhebliches Risiko ein.

Discourse leitet Clients mit einer signierten Payload auf discourse_connect_url um (angenommen, discourse_connect_url ist https://somesite.com/sso):

Sie erhalten eingehenden Verkehr mit folgendem Format:

https://somesite.com/sso?sso=PAYLOAD&sig=SIG

Die Payload ist ein Base64-kodierter String, der eine Nonce und eine return_sso_url enthält. Die Payload ist immer eine gültige Query-String.

Zum Beispiel, wenn die Nonce ABCD ist, lautet der rohe Payload:

nonce=ABCD&return_sso_url=https%3A%2F%2Fdiscourse_site%2Fsession%2Fsso_login. Dieser rohe Payload ist Base64-kodiert.

Der aufgerufene Endpunkt muss:

Die Signatur validieren: Stellen Sie sicher, dass der HMAC-SHA256 von PAYLOAD (unter Verwendung von discourse_connect_secret als Schlüssel) gleich dem sig ist (sig ist hex-kodiert).
Die erforderliche Authentifizierung durchführen.
Einen neuen URL-kodierten Payload mit mindestens nonce, email und external_id erstellen. Sie können auch zusätzliche Daten angeben. Hier ist eine Liste aller Schlüssel, die Discourse versteht:
- nonce sollte aus der Eingabe-Payload kopiert werden.
- email muss eine verifizierte E-Mail-Adresse sein. Wenn die E-Mail-Adresse nicht verifiziert ist, setzen Sie require_activation auf „true“.
- external_id ist ein beliebiger String, der für den Benutzer eindeutig ist und sich nie ändert, auch wenn sich seine E-Mail, sein Name usw. ändern. Der vorgeschlagene Wert ist die „id“-Zeilennummer Ihrer Datenbank.
- username wird zum Benutzernamen auf Discourse, wenn der Benutzer neu ist oder SiteSetting.auth_overrides_username gesetzt ist.
- name wird zum vollständigen Namen auf Discourse, wenn der Benutzer neu ist oder SiteSetting.auth_overrides_name gesetzt ist.
- avatar_url wird heruntergeladen und als Avatar des Benutzers festgelegt, wenn der Benutzer neu ist oder SiteSetting.discourse_connect_overrides_avatar gesetzt ist.
- avatar_force_update ist ein boolesches Feld. Wenn es auf true gesetzt ist, zwingt es Discourse, den Avatar des Benutzers zu aktualisieren, unabhängig davon, ob sich avatar_url geändert hat oder nicht.
- bio wird zum Inhalt der Bio des Benutzers, wenn der Benutzer neu ist, seine Bio leer ist oder SiteSetting.discourse_connect_overrides_bio gesetzt ist.
- title setzt den Titel des Benutzers.
- website setzt die Website des Benutzers in seinem Profil.
- location setzt den Standort des Benutzers in seinem Profil.
- profile_background_url wird heruntergeladen und als Profilhintergrund des Benutzers festgelegt, wenn der Benutzer neu ist oder SiteSetting.discourse_connect_overrides_profile_background gesetzt ist.
- card_background_url wird heruntergeladen und als Kartenhintergrund des Benutzers festgelegt, wenn der Benutzer neu ist oder SiteSetting.discourse_connect_overrides_card_background gesetzt ist.
- locale setzt die Spracheinstellung des Benutzers, wenn der Benutzer neu ist und SiteSetting.allow_user_locale aktiviert ist.
- locale_force_update ist ein boolesches Feld. Wenn es zusammen mit locale auf true gesetzt ist, erzwingt es die Aktualisierung der Spracheinstellung für bestehende Benutzer (erfordert SiteSetting.allow_user_locale).
- Zusätzliche boolesche Felder („true“ oder „false“) sind: admin, moderator, suppress_welcome_message, logout.
Den Payload Base64-kodieren.
Einen HMAC-SHA256-Hash des Payloads berechnen, wobei discourse_connect_secret als Schlüssel und der Base64-kodierte Payload als Text verwendet wird.
Zurück auf die return_sso_url mit einem sso- und sig-Query-Parameter umleiten (http://discourse_site/session/sso_login?sso=payload&sig=sig).

Discourse validiert, dass die Nonce gültig ist, und wenn ja, verfallen sie sofort, sodass sie nicht erneut verwendet werden kann. Anschließend versucht es:

Den Benutzer anzumelden, indem es nach einer bereits verknüpften external_id im SingleSignOnRecord-Modell sucht.
Den Benutzer anzumelden, indem die bereitgestellte E-Mail verwendet wird (Aktualisierung der external_id) (es sei denn, require_activation = true).
Ein neues Konto für den Benutzer zu erstellen (E-Mail, Benutzername, Name) und die external_id zu aktualisieren.

Sicherheitsbedenken

Die Nonce (Einmal-Token) verfällt automatisch nach 30 Minuten. Das bedeutet, dass der Benutzer, sobald er auf Ihre Site weitergeleitet wird, 30 Minuten Zeit hat, sich anzumelden oder ein neues Konto zu erstellen.

Das Protokoll ist sicher gegen Replay-Angriffe, da die Nonce nur einmal verwendet werden kann. Die Nonce ist an die aktuelle Browsersitzung gebunden, um CSRF-Angriffe zu verhindern.

Festlegung der Gruppenmitgliedschaft

Wenn die Option discourse connect overrides groups angegeben ist, berücksichtigt Discourse die durch Kommas getrennte Liste der Gruppen, die in groups übergeben werden.

Neben groups können Sie die Gruppenmitgliedschaft auch in Ihrer SSO-Payload mit den Attributen add_groups und remove_groups angeben, unabhängig von der Option discourse connect overrides groups.

add_groups ist eine durch Kommas getrennte Liste von Gruppennamen, für die wir sicherstellen, dass der Benutzer Mitglied ist.
remove_groups ist eine durch Kommas getrennte Liste von Gruppennamen, für die wir sicherstellen, dass der Benutzer kein Mitglied ist.

Referenzimplementierung

Discourse enthält eine Referenzimplementierung der SSO-Klasse:

github.com/discourse/discourse

lib/discourse_connect_base.rb

main

# frozen_string_literal: true

class DiscourseConnectBase
  class ParseError < RuntimeError
  end

  class PayloadParseError < ParseError
  end

  class SignatureError < ParseError
  end

  ACCESSORS = %i[
    add_groups
    admin
    avatar_force_update
    avatar_url
    bio
    card_background_url
    confirmed_2fa

This file has been truncated. show original

Eine triviale Implementierung wäre:

class DiscourseSsoController < ApplicationController
  def sso
    secret = "MY_SECRET_STRING"
    sso = DiscourseApi::SingleSignOn.parse(request.query_string, secret)
    sso.email = "user@email.com"
    sso.name = "Bill Hicks"
    sso.username = "bill@hicks.com"
    sso.external_id = "123" # eindeutige ID für jeden Benutzer Ihrer Anwendung
    sso.sso_secret = secret

    redirect_to sso.to_url("http://l.discourse/session/sso_login")
  end
end

Übergang zu und von Single Sign-On.

Solange der Parameter require_activation im Anfrage-Payload nicht auf true gesetzt ist, vertraut das System den vom Single Sign-On-Endpunkt bereitgestellten E-Mails. Das bedeutet, dass, wenn Sie in der Vergangenheit ein bestehendes Konto auf Discourse mit deaktiviertem DiscourseConnect hatten, DiscourseConnect dieses einfach wiederverwendet und die Erstellung eines neuen Kontos vermeidet.

Wenn Sie DiscourseConnect jemals deaktivieren, können Benutzer ihre Passwörter zurücksetzen und wieder Zugriff auf ihre Konten erhalten.

Beispiel aus der Praxis:

Gegeben sind folgende Einstellungen:

Discourse-Domain: http://discuss.example.com
DiscourseConnect-URL: http://www.example.com/discourse/sso
DiscourseConnect-Geheimnis: d836444a9e4084d5b224a60c208dce14
E-Mail validiert: Nein (fügen Sie require_activation=true zum Payload hinzu)

Benutzer versucht, sich anzumelden

Nonce wird generiert: cb68251eefb5211e58c00ff1395f0c0b
Roher Payload wird generiert: nonce=cb68251eefb5211e58c00ff1395f0c0b
Payload wird Base64-kodiert: bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGI=
Payload wird URL-kodiert: bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGI%3D
HMAC-SHA256 wird auf dem Base64-kodierten Payload generiert: 1ce1494f94484b6f6a092be9b15ccc1cdafb1f8460a3838fbb0e0883c4390471

Schließlich wird der Browser weitergeleitet zu:

http://www.example.com/discourse/sso?sso=bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGI%3D&sig=1ce1494f94484b6f6a092be9b15ccc1cdafb1f8460a3838fbb0e0883c4390471

Am anderen Ende

Payload wird mit HMAC-SHA256 validiert. Wenn die Signatur nicht übereinstimmt, wird der Prozess abgebrochen.
Durch Umkehren der oben genannten Schritte wird die Nonce extrahiert.

Benutzer meldet sich an:

name: sam
external_id: hello123
email: test@test.com
username: samsam
require_activation: true

Nicht signierter Payload wird generiert:

nonce=cb68251eefb5211e58c00ff1395f0c0b&name=sam&username=samsam&email=test%40test.com&external_id=hello123&require_activation=true

Die Reihenfolge ist nicht wichtig, Werte sind URL-kodiert.

Payload wird Base64-kodiert:

bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGImbmFtZT1zYW0mdXNlcm5hbWU9c2Ftc2FtJmVtYWlsPXRlc3QlNDB0ZXN0LmNvbSZleHRlcm5hbF9pZD1oZWxsbzEyMyZyZXF1aXJlX2FjdGl2YXRpb249dHJ1ZQ==

Payload wird URL-kodiert:

bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGImbmFtZT1zYW0mdXNlcm5hbWU9c2Ftc2FtJmVtYWlsPXRlc3QlNDB0ZXN0LmNvbSZleHRlcm5hbF9pZD1oZWxsbzEyMyZyZXF1aXJlX2FjdGl2YXRpb249dHJ1ZQ%3D%3D

Base64-kodierter Payload wird signiert:

3d7e5ac755a87ae3ccf90272644ed2207984db03cf020377c8b92ff51be3abc3

Browser leitet weiter zu:

http://discuss.example.com/session/sso_login?sso=bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGImbmFtZT1zYW0mdXNlcm5hbWU9c2Ftc2FtJmVtYWlsPXRlc3QlNDB0ZXN0LmNvbSZleHRlcm5hbF9pZD1oZWxsbzEyMyZyZXF1aXJlX2FjdGl2YXRpb249dHJ1ZQ%3D%3D&sig=3d7e5ac755a87ae3ccf90272644ed2207984db03cf020377c8b92ff51be3abc3

Synchronisierung von DiscourseConnect-Datensätzen

Sie können den POST-Admin-Endpunkt /admin/users/sync_sso verwenden, um einen DiscourseConnect-Datensatz zu synchronisieren. Übergeben Sie denselben Datensatz, den Sie auch an den DiscourseConnect-Endpunkt übergeben würden; die Nonce spielt keine Rolle.

Wenn Sie admin/users/sync_sso von einer anderen Site aus aufrufen, müssen Sie einen gültigen Admin-api_key und einen gültigen api_username in den Kopfzeilen der Anfrage angeben. Weitere Details zur Struktur der Anfrage finden Sie unter Sync DiscourseConnect user data with the sync_sso route.

Löschen von DiscourseConnect-Datensätzen

Wenn sich Ihre external_id-Werte von Ihrem DiscourseConnect-Anbieter geändert haben (vielleicht haben Sie den Generierungsalgorithmus geändert oder es ist ein anderer Endpunkt), können Sie sicher alle bestehenden Datensätze über die Rails-Konsole entfernen:

SingleSignOnRecord.destroy_all

Abmelden von Benutzern

Sie können den POST-Admin-Endpunkt /admin/users/{USER_ID}/log_out verwenden, um bei Bedarf jeden Benutzer im System abzumelden.

Um den Endpunkt zu konfigurieren, zu dem Discourse bei der Abmeldung weiterleitet, suchen Sie nach der Einstellung „logout redirect“. Wenn hier keine URL festgelegt ist, werden Sie zurück zur in discourse connect url konfigurierten URL weitergeleitet.

Benutzer nach `external_id` suchen

Benutzerprofildaten können über den Endpunkt /users/by-external/{EXTERNAL_ID}.json abgerufen werden. Dies gibt eine JSON-Payload zurück, die die Benutzerinformationen enthält, einschließlich der user_id, die mit dem log_out-Endpunkt verwendet werden kann.

Bestehende Implementierungen

Das discourse_api-Gem kann für SSO verwendet werden. Schauen Sie sich den SSO-Code im examples-Verzeichnis an, um eine grundlegende Implementierung zu sehen.
Unser WordPress-Plugin erleichtert die Konfiguration von SSO zwischen WordPress und Discourse. Details zur Einrichtung finden Sie auf der SSO-Registerkarte der Optionsseite des Plugins.

Zukünftige Arbeiten

Wir möchten mehr Referenzimplementierungen für SSO auf anderen Plattformen sammeln. Wenn Sie eine haben, posten Sie sie bitte in der Dev / SSO-Kategorie.

Erweiterte Funktionen

Sie können benutzerdefinierte Benutzerfelder übergeben, indem Sie den Feldnamen mit custom prefixieren. Zum Beispiel kann custom.user_field_1 verwendet werden, um den Wert des UserCustomField mit dem Namen user_field_1 festzulegen.
Sie können avatar_url übergeben, um den Benutzer-Avatar zu überschreiben (SiteSetting.discourse_connect_overrides_avatar muss aktiviert sein). Avatare werden zwischengespeichert, also übergeben Sie avatar_force_update=true, um sie zu aktualisieren, wenn die URL gleich ist. Derzeit können Sie keine leere URL übergeben, um den Avatar des Benutzers zu deaktivieren.
Standardmäßig wird die Willkommensnachricht an alle neuen Benutzer gesendet, die über SSO erstellt wurden. Wenn Sie dies unterdrücken möchten, können Sie suppress_welcome_message=true übergeben.
Um Ihre Discourse-Instanz als DiscourseConnect-Anbieter zu konfigurieren, siehe: DiscourseConnect als Identity Provider verwenden.

Debugging Ihres DiscourseConnect-Anbieters

Um das Debugging von DiscourseConnect zu unterstützen, können Sie die Site-Einstellung verbose_discourse_connect_logging aktivieren. Durch Aktivieren dieser Einstellung werden ausführliche Diagnoseinformationen in IHRESITE.com/logs angezeigt. Stellen Sie sicher, dass Sie das Kästchen warnings am Ende von IHRESITE.com/logs aktivieren.

Wir protokollieren eine Warnung in den Logs mit einem vollständigen Dump der SSO-Payload:

Jedes Mal, wenn der DiscourseConnect-Prozess gestartet wird, protokollieren wir eine Warnung im Log mit einem vollständigen Dump der DiscourseConnect-Payload.
Jedes Mal, wenn ein Benutzer den DiscourseConnect-Vorgang nicht abschließen kann (aufgrund abgelaufener Nonce oder IP-Sperre).

Müssen Sie Benutzeranmeldungen automatisieren? Siehe Auto-provisioning user accounts when SSO is enabled

dennisjbr · 30. August 2024 um 22:19

Hallo, ich kann nirgends etwas finden, aber welches Protokoll wird hier verwendet? Gehen wir von OAuth2 aus? Die Parameter scheinen nicht übereinzustimmen, und ich erhalte eine Fehlermeldung vom Anbieter, dass er anscheinend einen sso=-Parameter akzeptiert? Hilfe!

Danke

simon · 31. August 2024 um 10:49

DiscourseConnect ist die Implementierung von SSO durch Discourse. Es verwendet kein Standardprotokoll.

Wenn es Ihnen nichts ausmacht, PHP-Code anzusehen, gibt es hier eine Beispielimplementierung: wp-discourse/lib/sso-provider/discourse-sso.php at main · discourse/wp-discourse · GitHub.

Ja, das wird nicht funktionieren. Wenn Sie einen OAuth2-Anbieter haben, den Sie zur Authentifizierung von Benutzern verwenden möchten, schauen Sie sich das Plugin Discourse OAuth2 Basic an.

dennisjbr · 31. August 2024 um 18:26

Danke @simon. Ist der PHP-Code auch ein Provider und kein Consumer? Ich habe auch einen OIDC-Provider gesehen, der funktionieren könnte, sowie einen “Mittelsmann”-Provider im Plugin-Bereich.

Wenn der SSO-Provider nicht standardmäßig ist, für wen/was ist er dann gedacht, wenn er nicht mit anderen zusammenarbeitet?

Nochmals vielen Dank!

simon · 31. August 2024 um 21:30

Der Code, auf den ich verwiesen habe, dient zur Verwendung von WordPress als Authentifizierungsanbieter für Discourse.

Das WordPress-Plugin ermöglicht es WordPress auch, als DiscourseConnect-Client verwendet zu werden: wp-discourse/lib/sso-client at main · discourse/wp-discourse · GitHub.

Ich bin mir nicht sicher, was die Motivation für die Hinzufügung einer benutzerdefinierten SSO-Implementierung zu Discourse war. Ich vermute, es gab dafür einen geschäftlichen Grund.

Ein Vorteil ist, dass er es einer externen Website ermöglicht, eng in Discourse integriert zu werden. Zum Beispiel können alle hier aufgeführten Benutzerattribute während des Authentifizierungsprozesses mit Discourse synchronisiert werden: discourse/lib/discourse_connect_base.rb at 7b89fdead98606d4f47ceb0a1d240d0f6e5f589e · discourse/discourse · GitHub.

Er ermöglicht auch die Verwendung von Websites, die nicht als OAuth2- oder OpenID Connect-Anbieter konfiguriert sind, zur Authentifizierung von Benutzern auf Discourse.

Der Nachteil ist, dass benutzerdefinierter Code auf der Seite des Authentifizierungsanbieters hinzugefügt werden muss.

eric_wa · 10. September 2024 um 20:11

Hallo, ich bin neugierig, welche Probleme es gibt, E-Mail-Adressen auf einer externen Website, die SSO anbietet, nicht zu verifizieren. Ermöglicht dies nur automatisiertes Spamming? Oder gibt es andere Überlegungen? Warum wird nicht empfohlen, dass Discourse die E-Mail-Verifizierung übernimmt, wenn die externe Website dies nicht tut?

Vielen Dank für zusätzliche Einblicke.

simon · 12. September 2024 um 05:24

Das schlimmste Szenario, das mir bekannt ist, erfordert diese Bedingungen:

E-Mail-Adressen werden auf der externen Website nicht verifiziert
require_activation=true ist in der SSO-Nutzlast nicht gesetzt
Es gibt bereits Konten auf der Discourse-Website, denen kein SingleSignOnRecord zugeordnet ist (der Kontoinhaber hat sich nie mit SSO bei Discourse angemeldet)

In diesem Fall könnte sich jemand auf der externen Website mit der E-Mail-Adresse eines Discourse-Benutzers registrieren, der sich nie mit SSO angemeldet hat. Dies würde es dem nicht verifizierten Konto von der externen Website ermöglichen, das Discourse-Konto zu übernehmen, das dieselbe E-Mail-Adresse verwendet. Dies wäre besonders besorgniserregend, wenn es sich um ein Administratorkonto bei Discourse handeln würde.

Es wird empfohlen, dass Discourse die E-Mail-Verifizierung handhabt, wenn die externe Website dies nicht tut:

Es gibt jedoch ein paar Gründe, warum es besser ist, die E-Mail-Verifizierung auf der externen Website durchzuführen:

Benutzer zu zwingen, die Bestätigungs-E-Mail von Discourse zu erhalten, fügt Reibung hinzu, wenn Benutzer sich zum ersten Mal bei Discourse anmelden. (Realistisch gesehen muss diese Reibung irgendwo stattfinden – entweder auf Discourse-Seite oder auf der Seite der externen Website.)
Discourse gleicht keine vorhandenen Discourse-Konten mit externen Anmeldungen anhand der E-Mail-Adresse ab, wenn require_activation in der SSO-Nutzlast auf true gesetzt ist. Dies ist ein Problem, wenn Sie DiscourseConnect aktivieren, nachdem einige Konten auf Discourse durch Registrierung mit Benutzername/Passwort erstellt wurden. Es ist auch ein Problem, wenn Sie aus irgendeinem Grund jemals SingleSignOnRecord-Einträge auf Discourse löschen müssen. Discourse erstellt keine neuen SingleSignOnRecord-Einträge automatisch, wenn sich Benutzer wieder bei Discourse anmelden.

eric_wa · 12. September 2024 um 15:07

Danke, @simon – das ist sehr hilfreich!

GregorSondermeier · 17. Dezember 2024 um 12:53

Hallo, ich habe eine Frage zum groups-Feld in der SSO-Nutzlast.

Werden automatisierte Gruppen (wie Administratoren, Moderatoren und die Vertrauensstufen) ebenfalls überschrieben? Oder werden sie beibehalten?

Firepup650 · 17. Dezember 2024 um 13:02

Nein! Wenn die Beschreibung dieser Einstellung richtig ist, werden nur manuelle Gruppen davon betroffen sein.

GregorSondermeier · 18. Dezember 2024 um 06:33

Weißt du was… Ich habe das Wort „manuell“ in der Beschreibung nicht gesehen. Klingt vielversprechend für meinen Anwendungsfall, ich werde es ausprobieren und mich wieder melden.

probablykasper · 21. Dezember 2024 um 07:24

Als ich das las, dachte ich, ich müsste die Signatur direkt aus der Base64-kodierten Nutzlast generieren. Mir war nicht bewusst, dass man sie aus den UTF-8-Bytes generieren muss. Könnte das verdeutlicht werden?

martyn_thomas · 26. Dezember 2024 um 13:29

Ich habe mit DiscourseConnect herumgespielt – die Dokumentation ist großartig, danke.
Ich bin jedoch auf ein paar Hindernisse gestoßen, bei denen ich hoffe, Hilfe/Klärung zu bekommen.

Wir möchten, dass sich Benutzer mit ihrem Discourse-Login bei WordPress anmelden können (das funktioniert einwandfrei ) – jedoch.

Ist es möglich, einen WordPress-Benutzer über die Discourse-Registrierung zu erstellen (wenn ein Benutzer ein Discourse-Benutzerkonto erstellt, wird automatisch ein WordPress-Konto/Profil für ihn erstellt, damit er sich bei WordPress anmelden kann)?
Ist es möglich, WordPress-Benutzergruppen und Discourse-Gruppen zu synchronisieren?
Wenn ein Benutzer sowohl ein WordPress- als auch ein Discourse-Benutzerkonto hat, kann DiscourseConnect diese verknüpfen – gibt dem WordPress-Konto aber nicht die Benutzergruppen der Discourse-Gruppen mit demselben Namen und umgekehrt (und was ist, wenn Gruppen nicht denselben Namen haben – wie kann ich DiscourseConnect sagen, dass es dem Benutzer die Benutzergruppe „Testing Group“ geben soll, wenn der Benutzer die Discourse-Gruppe „Group for Testing Things“ hat)?

Was fehlt mir?

Jagster · 26. Dezember 2024 um 15:25

Ich kenne die Antwort nicht, aber…

Seien Sie damit vorsichtig. Es ist irgendwo ungesetzlich und wird weithin als schlechte Praxis angesehen (außerhalb der Website-Besitzer, natürlich ), da dies ohne Zustimmung und Wissen des Benutzers geschehen würde und gleichzeitig Daten woandershin verschoben würden.

Sicher, das ist etwas im Graubereich und im Grunde macht Google das zum Beispiel.

Aber… warum? Beschränken Sie die Anmeldung auf der WordPress-Seite nur auf Discourse SSO und leiten Sie Benutzer zur Kontoerstellung an Discourse weiter, und das war’s. Aber soweit ich weiß, können Sie Benutzerkonten nicht sofort automatisch synchronisieren. Und warum sollten Sie, denn mit SSO geschieht dies, wenn ein Benutzer es benötigt.

martyn_thomas · 26. Dezember 2024 um 16:06

In unserem Szenario (als Mitgliederorganisation)

WordPress wird zur Verwaltung von Abonnements und zum Kauf von Artikeln im WordPress-Store verwendet, und wir verwenden Benutzergruppen, um zu verwalten, was ein Mitglied in der Organisation tun kann.
Discourse ist unser Forum/unsere Online-Community, und wir verwenden Gruppen, um zu steuern, auf welche Bereiche von Discourse ein Benutzer Zugriff hat.

Derzeit muss ein neues Mitglied ein WordPress-Konto einrichten (und sein Abonnement usw. einrichten) und auch ein Discourse-Konto einrichten. Benutzergruppen-Discourse-Gruppen werden manuell verwaltet/synchronisiert.

Ich versuche, eine Lösung zu finden, bei der ein neuer Benutzer die Einrichtung einmal durchführt, um beide Konten zu erstellen, und Benutzergruppen-Discourse-Gruppen automatisch synchronisiert werden. Ich bin sicher, dass ich die Gruppensynchronisierung mit APIs usw. lösen kann. Es ist die Einrichtung mehrerer Benutzerkonten, die ich lösen/verhindern möchte.

simon · 27. Dezember 2024 um 08:06

Es scheint, als ob Sie Discourse als SSO-Anbieter für WordPress verwenden. Dieser Ansatz wird hier beschrieben: Discourse als Identitätsanbieter verwenden (SSO, DiscourseConnect). Das Discourse WordPress-Plugin bietet Optionen, entweder WordPress als SSO-Anbieter für Discourse zu verwenden oder Discourse als Identitätsanbieter für WordPress zu verwenden. Die Verwendung desselben Namens für beide Ansätze führt zu einiger Verwirrung.

Ich wäre versucht, WordPress in diesem Fall als Identitätsanbieter zu verwenden. Mit diesem Ansatz erstellen Benutzer Konten auf Ihrer WordPress-Website und melden sich dann mit ihren WordPress-Anmeldedaten bei Discourse an. Eine Sache, die Sie bei diesem Ansatz beachten sollten, ist, dass Benutzer sich nur über WordPress bei Discourse anmelden können. Es ist nicht möglich, ein Discourse-Konto zu erstellen, ohne bereits ein WordPress-Konto zu haben. Ich denke, das ist die richtige Einrichtung, wenn Sie Discourse mit einer WordPress-Mitgliederseite integrieren.

Wenn WordPress als Identitätsanbieter für Discourse verwendet wird, gibt es einige Hilfsfunktionen, die nützlich sind, um die Discourse-Gruppenmitgliedschaften von Benutzern basierend auf ihrer Aktivität in WordPress festzulegen. Diese Funktionen sind hier beschrieben: Gruppenmitgliedschaft in Discourse mit WP Discourse SSO verwalten.

Zurück zu Ihrer ursprünglichen Frage:

Es ist eine Weile her, seit ich mir den DiscourseConnect Client-Code des WordPress-Plugins angesehen habe, aber ich denke, was Sie fragen, ist mehr oder weniger die Art und Weise, wie dieser Code funktionieren soll. Wenn ein Benutzer ein Discourse-Konto hat, muss er nur auf den Link “Durch Discourse anmelden” in WordPress klicken, und ein Konto wird für ihn erstellt.

Dies wäre technisch möglich, wenn Sie WordPress als DiscourseConnect-Client verwenden, aber es sei denn, etwas hat sich geändert, können Sie die Methoden add_user_to_discourse_group und remove_user_from_discourse_group nicht verwenden, die in der von mir verlinkten Dokumentation beschrieben sind. Sie müssten etwas wie die Einrichtung eines Discourse Webhooks einrichten, der ausgelöst wird, wenn ein Benutzer zu einer Discourse-Gruppe hinzugefügt wird, und dann etwas Code in WordPress hinzufügen, um diesen Webhook zu verarbeiten. Um Gruppen von WordPress nach Discourse zu synchronisieren, müssten Sie einen API-Aufruf an Discourse machen, um die Gruppen eines Benutzers zu aktualisieren, wenn es eine Änderung in WordPress gab. Etwas, das ziemlich einfach zu erreichen wäre, wenn Sie WordPress als DiscourseConnect-Anbieter verwenden, könnte etwas komplizierter sein, wenn Sie WordPress als DiscourseConnect-Client verwenden.

Jagster · 27. Dezember 2024 um 08:48

Außer wenn eine benutzerdefinierte Anmeldung verwendet wird, wie es normalerweise bei WooCommerce/Mitgliedschaften/LLM der Fall ist, die diese Schaltfläche anzeigen und die ausschließliche Verwendung von Discourse SSO als Anbieter nicht standardmäßig erfolgt und etwas benutzerdefinierte Arbeit erfordert.

simon · 28. Dezember 2024 um 08:32

Es gibt ein paar mögliche Probleme, eines im Zusammenhang mit Caching und ein anderes im Zusammenhang mit Login-Weiterleitungen, die von einigen Plugins hinzugefügt werden. Jeder, der auf diese Probleme stößt, sollte sie in der Kategorie Support > WordPress ansprechen. Sie sind normalerweise leicht zu lösen.

GregorSondermeier · 9. Januar 2025 um 07:54

Ich habe ganz vergessen, zurückzumelden: Tatsächlich funktioniert es genau wie beschrieben, nur manuelle Gruppen sind betroffen.

Michael_Liu · 21. März 2025 um 05:20

Hallo @simon,
Ich glaube, ich brauche wirklich Hilfe bei der 404-Antwort meines POC-Explorers dieser SSO-Funktion. Ich arbeite seit einem ganzen Tag an diesem Problem, kann aber immer noch nicht herausfinden, was das Problem ist. Ich konnte

discourse_connect aktivieren
die discourse_connect_url auf https://localhost:4200/login setzen
discourse-connect secret: 20’s (1) 1111111111111111111 um es einfach zu halten

dann auf meiner Login-Seite meiner Angular-App habe ich diese Anfrage mit dem folgenden Code gesendet:

aber ich habe die Antwort 404 nicht gefunden erhalten.

Nach meinem Verständnis sollte beim Senden einer POST-Anfrage an den Endpunkt admin/users/sync_sso, wenn der Benutzer nicht in Discourse existiert, ein neuer Benutzer basierend auf der user_id und der E-Mail erstellt werden. Das zurückgegebene Ergebnis sollte ein Benutzerobjekt sein und kein leeres Objekt mit dem Statuscode 404.
Ich habe auch das Protokoll überprüft, es lieferte keine relevanten Informationen für diese fehlgeschlagene Antwort.

Vielen Dank im Voraus!

Thema		Antworten	Aufrufe
Use Discourse as an identity provider (SSO, DiscourseConnect) Integrations sso , discourseconnect , how-to	143	50555	9. November 2024
Configure single sign-on (SSO) with WP Discourse and DiscourseConnect Administrators wordpress , discourseconnect , sso , video , how-to	19	6122	24. November 2025
DiscourseConnect Provider Questions WordPress	38	2982	5. Oktober 2023
Integration into custom auth system where emails are not unique? SSO email	40	1462	6. Juni 2024
Merging existing Discourse and WP user lists WordPress	37	3178	28. Mai 2019