Wir hoffen, eine Community zu haben, in der man nur als Teil unseres Produktregistrierungsprozesses ein Konto erhält, aber wir möchten den Inhalt des Forums sichtbar machen, damit Leute, die versuchen, sich über Google selbst zu helfen, ein entsprechendes Ergebnis erhalten können, während sie nicht authentifiziert sind. (auch damit wir möglicherweise einige SEO-Ziele für unsere Inhalte erreichen können)
Ist das möglich oder ist es ein Wunschtraum? Es scheint, dass ich nicht der Erste bin, der diese Frage stellt oder diese Produktfähigkeit wünscht.
Das Problem ist also, dass einige Benutzer bei Ihrem Cognito angemeldet sind und Sie nicht möchten, dass sie einen Anmeldedialog erhalten, wenn sie versuchen zu antworten? Ich dachte, dass dies bei Discourse Connect das Standardverhalten sei.
Sie können die Website für anonyme Benutzer und Google öffnen.
In einer idealen Welt wäre ein Benutzer, der Discourse betrachtet und ein Konto hat, jederzeit angemeldet, damit wir alle seine Ansichtsdaten erfassen können. Ich werde dafür sorgen, dass ein Produktbenutzer, der auf einen Link im Produkt klickt, um die Community anzuzeigen, authentifiziert wird, ebenso wie alle Links, die der Benutzer nur sehen sollte, wenn er woanders authentifiziert ist (z. B. die Kontoseite).
Wenn ein Benutzer jedoch versucht, sich über Google selbst zu helfen, und in der Community landet, können wir diese Daten nicht erfassen, bis er versucht, direkt mit der Community zu interagieren, auch wenn er woanders in unserem System authentifiziert ist. Es scheint, dass die einzige Möglichkeit, dies zu lösen, darin besteht, die Einstellung login_required zu aktivieren, die, wenn ich das richtig verstehe, die Website effektiv privat macht.
Danke. Das wusste ich nicht. Ich bin ein CM, der versucht, alle Feinheiten von drei separaten Produkten zu verstehen, und es raubt mir den Verstand, die Einzelheiten für jedes einzelne zu erfassen! Erwarten Sie ein paar weitere Beiträge von mir, um alles zu klären, und ich danke Ihnen für Ihre Geduld.
Im Allgemeinen wird das unmöglich sein (wie können Sie feststellen, ob ein anonymer Benutzer ein Konto hat, ohne ihn aufzufordern, sich anzumelden?). Es sollte jedoch möglich sein, zu erkennen, ob ein Benutzer bereits eine aktive Sitzung auf Ihrer SSO-Website hat.
Dieses Thema ist ziemlich alt, aber ich denke, das Prinzip sollte immer noch gelten. Grundsätzlich fügen Sie eine URL mit entsprechender CORS-Unterstützung hinzu, die eine JSON-Antwort zurückgibt, die angibt, ob der Benutzer eine aktive Sitzung hat. Fügen Sie dann etwas JavaScript zu Ihrem Discourse-Theme hinzu, das diese URL abfragt und den SSO-Prozess auslöst, wenn eine aktive Sitzung besteht.
Ich fürchte, die allgemeine Antwort ist immer noch weitgehend dieselbe wie beim letzten Mal.
Die Spezifikation, über die ich sprach, ist OpenID Connect Session Management. Leider wird diese iframe-basierte Lösung immer weniger nützlich, da viele Browser standardmäßig Drittanbieter-Cookies blockieren. Sie funktioniert jetzt nur noch zuverlässig, wenn Ihr Identitätsanbieter und Discourse denselben ‘Origin’ haben.
Wie @simonk sagte, könnte es je nach Ihrem Identitätsanbieter möglich sein, etwas Benutzerdefiniertes über eine Theme-Komponente zu implementieren, aber mir ist keine allgemeine Lösung bekannt, die wir selbst zu Discourse hinzufügen könnten.
Sie haben absolut Recht, dass das Klicken auf „Antworten“ den Anmeldevorgang auslöst. Und wenn DiscourseConnect (oder ein anderer Single-Login-Anbieter) verwendet wird, wird das Discourse-Anmeldefenster übersprungen
Ich glaube jedoch, dass der Ersteller des Beitrags möchte, dass sich die Leute automatisch anmelden, ohne dass sie auf „Antworten“ oder „Anmelden“ klicken müssen. Mit dieser Art von Einrichtung wäre es für Benutzer nahtlos, zwischen der Hauptseite und der Community zu wechseln. Wir haben dies für einige Kunden erreicht, aber dies waren maßgeschneiderte Implementierungen, die nicht einfach verallgemeinert werden können.
Als Beispiel für einen Ansatz: Wenn sich Ihr Forum auf forum.example.com befindet und Ihre Hauptseite auf example.com, darf das Forum Cookies von example.com lesen. Ein Theme-Komponente kann also auf die Existenz eines Cookies prüfen und etwas wie folgt tun:
const cookie = require("discourse/lib/cookie").default;
if(cookie('name_of_example_com_auth_cookie') && !api.getCurrentUser()){
// Der Benutzer hat einen Auth-Cookie für example.com. Er ist dort mit ziemlicher Sicherheit
// angemeldet, also führen wir den Auth-Flow aus
window.location = "https://forum.example.com/auth/oidc"
}
(Hier gelten verschiedene Bedingungen. z. B. darf der Cookie nicht http_only sein, darf kein host-only Cookie sein usw.)
Das ist tatsächlich der Fall. Es ist gut zu wissen, dass es möglich ist, aber kundenspezifisch.
Da ich auch nicht wusste, dass ein Benutzer, der auf Antworten klickt, den Anmeldedialog je nach Implementierung überspringt, werden viele meiner Bedenken von vornherein entkräftet. Das ist die größte Eintrittsbarriere, die ich vermeiden möchte, und ich bin froh, dass sie implementiert werden kann.
Natürlich möchte der Datennerd in mir die ideale Version, und es ist möglich, dass wir danach streben. Zu wissen, dass es vorerst möglich ist, reicht aus. Nochmals vielen Dank an alle für Ihre Zeit.
