Das ist genau das, was ich mir auch vorgestellt habe.
Ich werde den Link zum Thema Category Group Review/Moderation einfügen, da ich ihn anfangs durch Suchen nur schwer finden konnte.
Ich habe immer Schwierigkeiten, Documentation in der Announcements Kategorie zu finden.
2 „Gefällt mir“
Ehrlich gesagt, ist das wahrscheinlich sowieso eine gute Idee. Administratoren haben ALLE Rechte (Backups herunterladen, Konfigurationsgeheimnisse einsehen/ändern, PII von Personen einsehen, Zugriff auf persönliche Nachrichten, …) und es ist am besten, diesen Kreis klein zu halten.
Es gibt viel Spielraum für „hohe Privilegien“, ohne volle Administratoren zu sein.
2 „Gefällt mir“
Vielen Dank euch beiden, ich wusste nicht, dass das eine separate Sache ist!
Vielen Dank für diese Klarstellung, ich wusste nicht, dass dies der Fall ist. Sie haben Recht, wir würden das jetzt, wo ich es weiß, definitiv einschränken.
Ich habe mir die Grenzen/Anforderungen angesehen und sie an mein Team weitergeleitet. Leider scheint es, dass wir trotzdem selbst hosten müssten. Das FOSS-Hosting, das Sie anbieten, ist sehr großzügig, wir passen einfach nicht in die Anforderungen.
Der größte Übeltäter sind die Seitenaufruflimits. 50.000 Seitenaufrufe pro Monat sind wahrscheinlich mehr als genug für die meisten FOSS-Projekte, aber wir generieren weitaus mehr Traffic. Allein unsere Hauptwebsite hat in den letzten 7 Tagen 1,87 Millionen Anfragen von 56.470 einzelnen Besuchern erhalten. Ich befürchte, dass wir bei dieser Rate leicht das Seitenaufruflimit erreichen werden.
Vielen Dank, dass Sie mich darauf aufmerksam gemacht haben!
4 „Gefällt mir“
Es wäre wahrscheinlich sinnvoll, einen Weg zu finden, damit umzugehen. Wenn Sie wissen, welche Benutzer auf Ihrem Server Discourse-Mitarbeiter (Administratoren oder Moderatoren) sind, legen Sie vielleicht das SSO-E-Mail-Feld für diese Benutzer auf ihre tatsächliche E-Mail fest. Alle doppelten E-Mail-Konten, die sie haben, erhalten die gefälschte E-Mail-Adresse.
Es gibt einige Fälle, in denen es nützlich ist, wenn Mitarbeiter E-Mails von Discourse erhalten können. Der erste Fall, auf den Sie wahrscheinlich stoßen werden, ist, dass Discourse eine /u/admin-login-Route für Mitarbeiter bereitstellt. Diese Route zeigt ein Formular an, das eine E-Mail-Adresse eines Mitarbeiters akzeptiert. Discourse sendet dann einen einmalig verwendbaren Anmeldelink an das Mitglied des Personals. Dies ist praktisch für die Einrichtung von SSO – wenn Sie sich bei der Einrichtung versehentlich aus der Website aussperren, können Sie sich wieder anmelden. Es ist auch nützlich, wenn es jemals ein Problem mit Ihrem Authentifizierungsserver gibt.
1 „Gefällt mir“
Ich stimme zu, und es ist etwas, worüber ich nachgedacht habe (aus Gründen außerhalb von Discourse). Das große Problem ergibt sich aus der Tatsache, dass normale Mitglieder Mitarbeiter werden können und auch geworden sind. Selbst wenn wir eindeutige E-Mails für Mitarbeiterkonten verlangen würden, könnten wir nicht garantieren, dass Benutzer diese haben, was zu Problemen führen würde, wenn ein Benutzer, dessen Konto eine doppelte E-Mail-Adresse hat, ein Mitarbeiter wird.
Nichtsdestotrotz, da nun klar ist, dass DiscourseConnect zuerst die eindeutige ID für Benutzersuchen verwendet und der Teil „Discourse verwendet E-Mails, um externe Benutzer mit Discourse-Benutzern abzugleichen“ des DiscourseConnect-Posts sich nur auf die Verknüpfung neuer SSO-Benutzer mit bestehenden Discourse-Konten bezieht, und mein Missverständnis, wie die Anmeldeaufforderung funktioniert, geklärt wurde, gibt es etwas, das uns tatsächlich daran hindert, einfach doppelte E-Mail-Adressen so zu senden, wie sie sind? Oder wird diese Einzigartigkeit streng durchgesetzt?
Ja. Ich habe einen Schritt in meiner Beschreibung des Login-Flows ausgelassen. Discourse versucht zuerst, den Benutzer anhand der external_id zu finden, dann versucht es, den Benutzer anhand seiner email zu finden. Wenn keiner gefunden wird, versucht Discourse, den Benutzer zu erstellen. So werden Ihre Benutzer zunächst bei Discourse registriert. Discourse erlaubt keine doppelten E-Mail-Adressen. Wenn also versucht wird, einen Benutzer mit einer E-Mail-Adresse zu erstellen, die bereits verwendet wird, gibt Discourse einen Fehler aus.
Sie müssen sicherstellen, dass die im Payload gesendeten E-Mails pro Benutzer eindeutig sind.
Verstanden, danke für die Klärung 
Ist es möglich, die E-Mail eines Benutzers zu einem späteren Zeitpunkt manuell zu aktualisieren? Da das Problem mit der Anmeldeaufforderung gelöst ist, könnte ich die Idee meines Teams umsetzen, die sie zuvor hatten, gefälschte E-Mails und einen von uns betriebenen SMTP-Server zu verwenden, der diese gefälschten E-Mails der echten E-Mail eines Benutzers zuordnet. Zum Beispiel würden wir die Discourse-E-Mail aller Benutzer auf etwas wie userid@example.com aktualisieren, das sich zuerst mit unserem SMTP-Server verbindet und die userid verwendet, um die echte E-Mail des Benutzers nachzuschlagen. Dies ist jedoch nichts, was wir in einiger Zeit fertig hätten, daher müssten wir die Discourse-E-Mails der Benutzer später aktualisieren, wenn möglich.
Ja. Dazu müssen Sie die Website-Einstellung auth overrides email aktivieren. Wenn diese Einstellung aktiviert ist, wird die Discourse-E-Mail eines Benutzers bei jeder Anmeldung mit der E-Mail-Adresse synchronisiert, die in der Auth-Payload enthalten ist (in Ihrem Fall die DiscourseConnect-Payload). Wenn sie nicht aktiviert ist, wird die E-Mail-Adresse des Benutzers bei der erstmaligen Erstellung des Kontos auf die E-Mail-Adresse in der Auth-Payload gesetzt, aber bei nachfolgenden Anmeldungen nicht aktualisiert.
Unter der Annahme, dass auth overrides email aktiviert ist, können Sie sie auch aktualisieren, ohne dass sich Benutzer anmelden müssen, indem Sie eine API-Anforderung an die Route sync_sso senden: Sync DiscourseConnect user data with the sync_sso route.
Sie könnten auch die E-Mail-Adressen der Benutzer per Massenupload von der Rails-Konsole der Website aus aktualisieren, aber (ich glaube) auf diese Weise wird eine Bestätigungs-E-Mail von Discourse an den Benutzer gesendet. Das funktioniert nicht mit gefälschten E-Mail-Adressen.
Vielleicht könnten Sie die E-Mails zunächst einfach auf etwas Aussagekräftiges setzen. Sobald Sie eine Discourse-Website eingerichtet haben, sollten Sie einige Tests durchführen, um zu sehen, welche E-Mail-Domains Discourse für gefälschte E-Mails akzeptiert. Aus dem Gedächtnis glaube ich, dass @invalid.com akzeptiert wird. Bei anderen Domains bin ich mir nicht sicher. Auf Ihrer Seite könnten Sie etwas wie <userId>@invalid.com der tatsächlichen E-Mail-Adresse des Benutzers zuordnen.
Sie waren unglaublich hilfreich, vielen Dank! Die API-Lösung ist das, was ich im Sinn hatte, aber zu wissen, dass sie sich selbst synchronisieren kann, funktioniert auch perfekt.
Das könnten wir tun, ja. Ich wollte zuerst versuchen, Plus-Adressierung zu verwenden, damit zumindest einige Benutzer von Anfang an E-Mails erhalten. Dann später auf unseren eigenen SMTP-Mapping-Server umstellen, um alle zu unterstützen, auch diejenigen, für die die Plus-Adressierung nicht funktionierte.
1 „Gefällt mir“
@simon @supermathie Ihr beide wart bisher unglaublich hilfreich, ich hoffe, ich kann ein wenig vom Thema des Threads abweichen und um weitere Hilfe bitten?
Ich habe Discourse auf einem lokalen Rechner zur Testung installiert, wobei ich Install Discourse for development using Docker als Leitfaden verwendet habe. Ich konnte keine anderen Anleitungen finden, wie man es für lokales Testen einrichtet? Das Wiki scheint nur Produktions-Setups zu behandeln, die die Einrichtung von Domain/DNS/SMTP erfordern. Wir wollten das Forum erst öffentlich zugänglich machen, wenn alles auf unserer Seite implementiert war, daher benötigten wir lokales Testen, bei dem nichts davon erforderlich war.
Ich habe es mit dieser Anleitung zum Laufen gebracht und das SSO auf einer lokalen Instanz unserer Seite implementiert, bin aber bisher auf 2 Probleme gestoßen:
- Die Weiterleitung an
return_sso_urlscheint nur halb zu funktionieren? In meinem Fall ist die URLhttp://localhost:3000/session/sso_login. Sie leitet zwar erfolgreich weiter, aber nach der anfänglichen Weiterleitung wird mirhttp://localhost:3000angezeigt, was einfach den FehlerRuntimeError: Discourse does not support compiling scss/sass files via Sprocketsanzeigt. Der einzige Thread, den ich zu diesem Fehler finden konnte, ist Error when building: discourse does not support compiling scss/sass files via sprockets, aber der schien nicht wirklich weiterzuführen. Der OP hat keine Lösung akzeptiert, und das Einzige, was passierte, war eine Frage nach RAM- und Swap-Größen (die Maschine, auf der dies läuft, hat 32 GB RAM und 2 GB Swap. Ich bezweifle also, dass dies das Problem ist?) avatar_force_updatescheint nicht beachtet zu werden? Oder zumindest nicht für Admin-Benutzer? Ich habediscourse connect overrides avatarin den Site-Einstellungen aktiviert und im SSO-Antwort-Payload sowohlavatar_urlals auchavatar_force_updategesetzt. Aber beim Einloggen in das Admin-Konto (das mit meinem externen Konto verknüpft ist) wird nicht mein externes Profilbild angezeigt? Ich kann sehen, dassexternal_avatar_urlkorrekt gesetzt wird, wenn ich die Daten des Admin-Benutzers über die API überprüfe, es scheint nur nicht in der Benutzeroberfläche verwendet zu werden?
Hier ist eine Liste von Installationsmethoden: Set up a local Discourse Development Environment?. Ich habe eine Nicht-Docker-Entwicklungsseite (unter Verwendung der Ubuntu-Anleitung). Wenn es für Sie möglich ist, denke ich, dass Sie mit dem Nicht-Docker-Ansatz die besten Ergebnisse erzielen werden. Einer der Gründe, warum ich ihn verwende, ist, dass ich mich nicht mit Netzwerkproblemen für API-Anfragen zwischen Discourse und anderen Anwendungen, die ich lokal entwickle, auseinandersetzen muss. Er ist auch schneller als Docker.
Das sollte es sein. Stellen Sie sicher, dass die Anwendung, auf der Sie die SSO-Payload generieren, den booleschen Wert true nicht in 1 umwandelt. Das ist ein häufiges Problem. Um dies zu umgehen, können Sie alle booleschen Werte in der SSO-Payload auf die Strings \"true\" oder \"false\" setzen. Discourse wird sie korrekt interpretieren. Überprüfen Sie das zuerst, um zu sehen, ob das das Problem ist. Es könnte auch etwas anderes sein. Der Code, der avatar_force_update behandelt, ist ziemlich komplex, aber lesbar: discourse/app/models/discourse_connect.rb at 187204705323b650d61ed25862eb1a0c733aa63c · discourse/discourse · GitHub.
Bearbeitung: Bezüglich des Problems mit booleschen Werten in der SSO-Payload ist es wohl genauer zu sagen, dass die Umgebung im Prozess der Generierung der SSO-Payload die booleschen Werte true/false in Strings umwandelt. Discourse erwartet die Strings \"true\" oder \"false\", andere Programmierumgebungen gehen möglicherweise anders damit um. Zum Beispiel:
PHP:
wp> strval(true)
=> string(1) "1"
im Gegensatz zu Ruby:
irb(main):001> true.to_s
=> "true"
Python (ich bin mir nicht sicher, wie Discourse damit umgeht):
>>> str(True)
'True'
2 „Gefällt mir“
Ich werde einen davon ausprobieren. Vielen Dank, dass Sie mich in diese Richtung gewiesen haben. Das ist jedoch ziemlich kontraintuitiv. Normalerweise suchen die Leute nach der Docker-Lösung als die “schnelle und einfache” Methode zur Einrichtung. Dies ist das erste Mal, dass mir empfohlen wurde, die Docker-Version zu vermeiden. Es wirft jedoch immer noch die Frage auf, warum dies bei der Docker-Version passiert? Die Verwendung einer anderen Installationsmethode, um das Problem zu umgehen, funktioniert vorerst, löst aber nicht das zugrunde liegende Problem.
Er wird definitiv nicht auf 1 gesetzt. Ich arbeite in JavaScript, und der boolesche Wert true wird immer in den String \"true\" umgewandelt:
String(true); // 'true'
(true).toString(); // 'true'
// Das ist es, was mein Code tatsächlich verwendet
querystring.stringify({
avatar_force_update: true
}); // 'avatar_force_update=true'
Ich habe noch nie mit Ruby gearbeitet, daher bin ich mir nicht sicher, wie weit ich tatsächlich damit komme, dies zu untersuchen. Aber auf den ersten Blick sehe ich keine Probleme? Ich habe jedoch überprüft, dass sowohl die relevante Einstellung im Discourse-Dashboard als auch in der SSO-Payload gesetzt sind:
Ich habe nicht getestet, ob ich das Bild eines Standardbenutzerkontos von etwas anderem als dem, womit das Konto erstellt wurde, ändern kann, aber als ich mich zum ersten Mal bei einem Standardbenutzerkonto angemeldet habe, hat Discourse den Avatar heruntergeladen und ihn wie erwartet angewendet. Das einzige Konto, das nicht aktualisiert wird, ist das Administratorkonto?
Um fair zu sein, in PHP würde man fast immer var_export verwenden, um die “echte” String-Darstellung einer Variablen zu erhalten, da es das gültige PHP zurückgibt, das benötigt wird, um diese Variable neu zu erstellen:
var_export(true); // true
1 „Gefällt mir“
Sehen Sie sich den Abschnitt DiscourseConnect an, der sich am Ende der Admin-Seite des Benutzers befindet. Dort gibt es eine Schaltfläche, auf die Sie klicken können, um die Werte der letzten SSO-Nutzlast anzuzeigen, die von Discourse empfangen wurde.
Sie können dieselben Informationen auch von der Rails-Konsole abrufen. Zum Beispiel:
>SingleSignOnRecord.last
# oder
>SingleSignOnRecord.where(external_id: 2)
Sie sollten die Website-Einstellung verbose discourse connect logging aktivieren. Dies fügt den Protokollen, die unter Admin / Protokolle / Fehlerprotokolle generiert werden, zusätzliche Details hinzu. Für das Avatar-Problem ist es möglich, dass die relevanten Protokolleinträge als normale Fehlerprotokolle und nicht als DiscourseConnect-Protokolle angezeigt werden.
Möglicherweise ist das Problem spezifisch für WordPress. Es gibt immer 1 für true und \"1\" für die String-Darstellung von true zurück.
1 „Gefällt mir“
Es ist die erwartete Nutzlast, und die URL des Profilbilds wird korrekt angezeigt:
Das Profilbild SOLLTE dieses sein:
Es wird jedoch immer noch angezeigt als:
Was mein Gravatar ist:
Wenn ich diese Einstellung nicht missverstehe oder wenn ich etwas anderes einstellen muss, habe ich die Einstellung aktiviert, um diese zu überschreiben:
Ich habe auch versucht, dies im Inkognito-Modus, in verschiedenen Browsern und durch Löschen des Browser-Cache durchzuführen, um ein Caching-Problem auszuschließen.
Ist das auf Ihrer lokalen Entwickler-Site?
Ich frage mich, ob das Hochladen des Avatars aus irgendeinem Grund fehlgeschlagen ist. Versuchen Sie, die Website-Einstellung verbose discourse connect logging zu aktivieren, sich dann abzumelden und wieder anzumelden. Es sollte mindestens eine Nachricht in den Protokollen geben, die sich auf den Avatar bezieht:
Möglicherweise gibt es einen weiteren Fehler im Zusammenhang mit dem fehlgeschlagenen Upload.
Falls Sie es noch nicht herausgefunden haben, bedeutet dies: „Sie müssen über den ember-cli-Proxy zugreifen und nicht direkt über einen Browser.“
Verwenden Sie bin/ember-cli -u, um ihn für die Entwicklung zu starten.
Ich habe Ihre Avatarsituation dupliziert:
vorher:
Login-Payload:
nachher:
aber:
Ich glaube, dies ist ein Fehler, bei dem Discourse die benutzerdefinierte Avatar-URL korrekt setzt, aber nicht von Gravatar zum benutzerdefinierten Bild wechselt.
Wenn ich einen neuen Benutzer erstelle:
funktioniert es sofort:
Daher vermute ich, dass dies durch ein Konto ausgelöst wird, das vor der Verwendung von DiscourseConnect einen Gravatar hat.
2 „Gefällt mir“
Ich habe es geschafft, die Ubuntu-Schritte zum Laufen zu bringen (nach einigem Tüfteln, da das Installationsskript mit Paketen und Software, die ich bereits installiert hatte, in Konflikt geriet). Das hat den ursprünglichen Fehler, den ich hatte, behoben, aber SSO funktioniert immer noch nur zur Hälfte. Anstelle des scss/sass-Fehlers gibt SSO jedes Mal Account login timed out, please try logging in again. aus. Das Klicken auf die Schaltfläche Login ein zweites Mal auf dieser Fehlerseite schließt die Anmeldung ab. Auf meiner Seite wurden keine Codeänderungen vorgenommen, nur die Art und Weise, wie Discourse ausgeführt wird.
Ich werde das alles auf die Eigenheiten der lokalen Ausführung schieben. Ich hoffe, dass eine Produktionsbereitstellung nicht die gleichen Probleme hat.
Dies schien bei der Docker-Version nichts zu bewirken. Das Skript wurde ohne Ausgabe beendet, und es schien auf der Discourse-Seite nichts wirklich zu passieren. Das widerspricht auch den Schritten im Docker-Leitfaden, was seltsam ist. Gibt es einen Grund, warum dies dort nicht erwähnt wird?
Es erscheint mir seltsam, dass die Docker-Methode diese Probleme zu haben scheint und dass der offizielle Rat darin besteht, Discourse nativ zu installieren (obwohl das Installationsskript nicht immer auf Anhieb funktioniert, da es Dinge wie die Verwendung von bashrc annimmt und versucht, potenziell widersprüchliche Versionen von bereits installierten Paketen zu installieren)? Sollte es vielleicht eine Warnung bezüglich der potenziellen Probleme mit allen verfügbaren Hosting-Versionen geben? Auf den ersten Blick ist nicht klar, welche die richtige ist, und typischerweise gehen die Leute davon aus, dass, wenn ein Docker-Build verfügbar ist, dieser die erste Wahl sein sollte.
Ich bin froh zu hören, dass ich nicht der Einzige bin! 
Fehler sind nie schön, aber ich bin froh, geholfen zu haben, diesen zu finden.
Das mag sein, aber Sie sollten DiscourseConnect problemlos lokal zum Laufen bringen können. Greifen Sie auf Discourse unter http://localhost:4200 zu? Es gibt ein seltsames (meiner Meinung nach) Problem, bei dem Discourse in einer lokalen Entwicklungsumgebung entweder unter localhost:4200 oder 127.0.0.1:4200 erreichbar ist. Ich würde mich an die Domain localhost halten. Sie wird als andere Sitzung als 127.0.0.1 behandelt.
Wie auch immer, das ist nur eine Vermutung, was vor sich geht. Stellen Sie sicher, dass Sie die Einstellung für die ausführliche Protokollierung aktivieren und die Protokolle auf Details überprüfen.
Die Installationsanweisungen sollten klarstellen, dass Sie das Skript nicht ausführen müssen. Sie können die Schritte des Skripts einfach nacheinander durchgehen, um sicherzustellen, dass alle Abhängigkeiten installiert sind.
Ja, das tue ich.
Die zuvor verlinkten machen das nicht klar. Ich ging zu Set up a local Discourse Development Environment? und wählte Install Discourse on Ubuntu or Debian for Development, da ich Ubuntu 22.04.3 verwende. Auf dieser Seite steht zwar, dass man nicht das gesamte Skript ausführen muss, aber in kleiner Schrift nach dem Teil, der die Benutzer anweist, es auszuführen.
Für mich war das nicht klar, da man beim Lesen der Anweisungen von oben nach unten natürlich davon ausgehen würde, dass man den aktuellen Schritt abschließen muss, bevor man fortfährt. Also habe ich mit dem Installationsskript gekämpft, nur das installiert, was ich brauchte, nur um dann nach Abschluss weiterzulesen und zu sehen, dass das die ganze Zeit beabsichtigt war und ich mich eigentlich mit nichts hätte auseinandersetzen müssen.
Diese Anmerkung nach den Anweisungen macht sie meiner Meinung nach definitiv nicht klar.
1 „Gefällt mir“
Es scheint, dass die Nonce (einmalige Zufallszahl) falsch ist? Ich sehe jetzt Folgendes in den Protokollen beim Anmelden:
Kann die Authentizität des CSRF-Tokens nicht überprüfen. 15:44 Uhr
Ausführliches SSO-Protokoll: SSO-Prozess gestartet add_groups: admin: avatar_force_update: avatar_url: bio: card_background_url: confirmed_2fa: email: external_id: failed: groups: locale: locale_force_ 15:44 Uhr
Ausführliches SSO-Protokoll: Nonce ist falsch, wurde in einer anderen Browsersitzung generiert oder ist abgelaufen add_groups: admin: avatar_force_update: true avatar_url: https://pretendo-cdn.b-cdn.net/mii/1424784 15:44 Uhr
Ausführliches SSO-Protokoll: SSO-Prozess gestartet add_groups: admin: avatar_force_update: avatar_url: bio: card_background_url: confirmed_2fa: email: external_id: failed: groups: locale: locale_force_ 15:44 Uhr
Ausführliches SSO-Protokoll: Benutzer wurde auf PN_Jon angemeldet add_groups: admin: avatar_force_update: true avatar_url: https://pretendo-cdn.b-cdn.net/mii/1424784406/normal_face.png bio: card_background_url: confirm 15:44 Uhr
MaxMindDB (/home/jon/discourse/vendor/data/GeoLite2-City.mmdb) konnte nicht gefunden werden: Datei oder Verzeichnis nicht gefunden @ rb_sysopen - /home/jon/discourse/vendor/data/GeoLite2-City.mmdb 15:44 Uhr
MaxMindDB (/home/jon/discourse/vendor/data/GeoLite2-ASN.mmdb) konnte nicht gefunden werden: Datei oder Verzeichnis nicht gefunden @ rb_sysopen - /home/jon/discourse/vendor/data/GeoLite2-ASN.mmdb 15:44 Uhr
Bei näherer Betrachtung scheint es daran zu liegen, dass die SSO-Umleitung nicht localhost verwendet. Sie leitet mich zurück zu 127.0.0.1. Wenn ich von der Verwendung von localhost auf die anfängliche Verwendung von 127.0.0.1 umstelle, ist das Problem behoben.