Wir möchten Discourse in unsere bestehenden Systeme integrieren, um die Abhängigkeit von unserem Discord-Server für den Support zu verringern. Wir haben bereits ein eigenes Kontosystem eingerichtet und möchten dieses nach Möglichkeit wiederverwenden, um Reibungsverluste zu reduzieren. In unserem Fall müssen jedoch nicht die E-Mail-Adressen eindeutig sein, sondern nur die Benutzernamen. Es scheint, als ob Discourse davon ausgeht, dass E-Mails global eindeutig sind, was eine direkte Integration verhindert.
Ich habe mir DiscourseConnect angesehen, was vielversprechend schien, aber besagt:
Discourse verwendet E-Mails, um externe Benutzer Discourse-Benutzern zuzuordnen.
Dies würde in unserem Fall nicht funktionieren, da mehrere Konten dieselbe E-Mail-Adresse verwenden können (und auch tun).
Wir haben uns dann Discourse OAuth2 Basic angesehen, das auf den ersten Blick keine E-Mail erforderte:
Das einzige obligatorische Attribut ist id.
Später wird jedoch erwähnt, dass eine E-Mail-Adresse manuell eingegeben werden muss, wenn sie nicht von der OAuth-Quelle bereitgestellt wird:
Beachten Sie, dass ich den E-Mail-Pfad weggelassen habe: SoundCloud stellt keine E-Mail zur Verfügung, sodass der Benutzer diese bei der ersten Anmeldung bei Discourse angeben und verifizieren muss.
Wäre die Verwendung von Discourse in unserem Fall noch praktikabel? Dass Benutzer bei der ersten Anmeldung bei Discourse manuell eine E-Mail-Adresse angeben, wäre in unserem Fall in Ordnung, aber nur, wenn wir die Möglichkeit deaktivieren können, eine E-Mail-Adresse während des eigentlichen Anmeldevorgangs zu verwenden (wodurch nur Benutzername und Passwort erforderlich sind), da wir eine E-Mail nicht zuverlässig einem eindeutigen Benutzer zuordnen können. Die vollständige Deaktivierung im Anmeldeformular würde die Reibungsverluste auf unserer Seite reduzieren, da wir dies ohnehin nicht unterstützen würden und Benutzer davon abhalten möchten, es überhaupt zu versuchen.
Wir haben dies berücksichtigt, waren uns aber nicht sicher, wie es den OAuth-Flow beeinflussen oder die Anmeldung/Registrierung erschweren würde. Diese Art von Änderung wäre für den Benutzer unsichtbar, sodass er sich nicht anmelden könnte, es sei denn, er gibt diese geänderte E-Mail-Adresse ein. Unser aktueller Account-Server wäre sich dieser Änderungen ebenfalls nicht bewusst, sodass wir sie selbst dann nicht in unseren Aufzeichnungen finden könnten, wenn sie die geänderte E-Mail-Adresse eingeben würden?
Dies würde auch Benutzer brechen, die bereits E-Mail-Aliase verwenden, oder nicht?
Es sei denn, sie meldeten sich mit dem Benutzernamen an.
Wenn Sie E-Mail-Logins zulassen würden (was ich glaube, dass Sie mit DiscourseConnect nicht können), würde es einfach funktionieren, wenn sie einen E-Mail-Link erhalten hätten.
Sie müssten ihn darauf aufmerksam machen. Ich denke, das wäre Schritt eins.
Eine weitere unschöne Option wäre, nur dem “ersten” (wie auch immer das definiert wird) Benutzer die Anmeldung bei Discourse überhaupt zu gestatten.
Eine weitere unschöne Lösung wäre, die Benutzer in Ihrem System zu zwingen, eindeutige Adressen für jedes Konto zu erhalten.
Nun ja. Natürlich wäre das der Fall, und das ist es, was ich anstrebe. Ich suchte nach einer Lösung, die die Anmeldung mit einer E-Mail überhaupt nicht zulässt und die Benutzernamenanmeldungen als einzige Methode belässt. Es ist mir egal, ob der E-Mail-Support im Wesentlichen unterbrochen wird (keine E-Mail-Benachrichtigungen zum Beispiel), indem einfach völlig gefälschte E-Mails vom OAuth-Server ausgegeben werden. Aber das schafft Reibung, wenn die Möglichkeit, eine E-Mail zur Anmeldung zu verwenden, weiterhin besteht, da die Benutzer dies versuchen und scheitern würden.
Das würde uns im Wesentlichen zwingen, 2 separate E-Mails pro Benutzer zu verfolgen, was ebenfalls nicht wünschenswert ist und, wie von @supermathie erwähnt, nicht einmal mit allen Anbietern garantiert funktioniert und immer noch Reibung verursacht, da wir den Benutzern nun diese Forum-spezifische E-Mail-Adresse mitteilen müssten, an die sie sich erinnern müssen.
Ja, das würde technisch funktionieren. Aber aus offensichtlichen Gründen wäre es keine wirkliche Lösung, da es alle anderen davon abhalten würde, jemals dem Forum beizutreten.
Dies ist aus technischen Gründen nicht möglich. Der offensichtlichste Grund dafür ist, dass wir bereits Benutzer haben, die dieselbe E-Mail-Adresse wie andere Konten haben. Aber der größere Grund ist, dass wir dies einfach nicht tun können. Das Projekt, in das wir Discourse integrieren möchten, ist Pretendo Network, ein Server-Emulationsprojekt für Nintendo Network. Nintendo erlaubte seinem Kontosystem, E-Mail-Adressen wiederzuverwenden, und um die Server genau zu emulieren, müssen wir dies ebenfalls tun. Das Erzwingen eindeutiger E-Mails liegt einfach nicht in unseren Möglichkeiten.
Jemand in meinem Team schlug vor, dass wir unseren eigenen SMTP-Server betreiben, der die Zuordnung der gefälschten E-Mails für Discourse zu den tatsächlichen E-Mails unserer Benutzer übernimmt und die von Discourse gesendeten E-Mails auf diese Weise weiterleitet. Das würde funktionieren, ist aber offensichtlich mit höheren technischen Kosten für uns verbunden und löst immer noch nicht das Problem der Deaktivierung der E-Mail-Anmeldung und die oben genannten Reibungen, die in unserem Fall auftreten.
Es scheint, dass wir Discourse möglicherweise einfach forken oder eine andere Forum-Lösung verwenden müssen, um das zu tun, was wir brauchen.
Ich erinnere mich aus dem Gedächtnis, aber Sie können DiscourseConnect mit gefälschten, aber eindeutigen E-Mail-Adressen verwenden. Wenn Benutzernamen auf Ihrer Seite garantiert eindeutig sind, könnte die Implementierung recht einfach sein. Die E-Mail-Adresse könnte auf etwas wie username@invalid.com gesetzt werden.
Benutzer melden sich bei Ihrem System mit der Methode an, die sie derzeit verwenden. Ihr System generiert dann die SSO-Nutzlast mit der gefälschten E-Mail-Adresse.
Der Nachteil dieses Ansatzes ist, dass Sie E-Mails in Discourse deaktivieren müssten. Dies kann durch Setzen der Einstellung disable emails auf entweder yes oder non-staff (wenn Ihre Mitarbeiter eindeutige E-Mail-Adressen haben) erfolgen.
Sie könnten auch erwägen, E-Mail-Adressen mit einem Pluszeichen für Benutzer mit doppelten E-Mail-Adressen zu verwenden. Als ich das letzte Mal nachsah, betrachtete Discourse E-Mail-Adressen mit einem Pluszeichen als eindeutig. Stellen Sie einfach sicher, dass Sie die E-Mail-Adressen URL-codieren, bevor Sie sie in der DiscourseConnect-Nutzlast verwenden. Das Risiko hierbei ist, dass Benutzer, die doppelte E-Mail-Adressen haben und einen E-Mail-Server verwenden, der keine E-Mail-Adressen mit einem Pluszeichen unterstützt, keine E-Mails von Discourse erhalten, aber Ihre anderen Benutzer Discourse-E-Mails erhalten können.
Ja, aber nur in einem bestimmten Fall. Wenn ein Benutzer ein Discourse-Konto erstellt hat, bevor die Discourse-Website DiscourseConnect implementiert hat, versucht Discourse, vorhandene Benutzer der E-Mail-Adresse zuzuordnen, die sich in der DiscourseConnect-Nutzlast befindet. Wenn Sie eine neue Discourse-Website starten, wird dies kein Problem sein.
Ein weiterer Fall, in dem das Problem der E-Mail-Zuordnung auftrat, war, als aufgrund fehlerhaften Codes auf der Authentifizierungsanbieterseite die SSO-Datensätze auf der Discourse-Website beschädigt wurden. In diesem Fall konnte die Website alle SSO-Datensätze auf der Discourse-Seite löschen und Discourse dann die Benutzer bei der nächsten Anmeldung der SSO-Nutzlast-E-Mail-Adresse zuordnen lassen. Discourse generierte dann neue SSO-Datensätze für die Benutzer. Dies würde auch mit gefälschten E-Mail-Adressen funktionieren.
Die Logik bei der DiscourseConnect-Authentifizierung ist, dass Discourse zuerst versucht, den Benutzer anhand des Feldes external_id der Nutzlast zu finden. Wenn es keinen Benutzer findet, versucht es stattdessen, den Benutzer anhand des Feldes email der Nutzlast zu finden. Wenn es immer noch keinen Benutzer findet, wird ein Fehler ausgelöst.
Überprüfen Sie all dies, bevor Sie es tatsächlich auf einer Live-Website implementieren, aber ich weiß, dass der Ansatz mit gefälschten E-Mails auf Produktionswebsites für Fälle verwendet wurde, in denen die echten E-Mail-Adressen der Benutzer nicht mit der Discourse-Website geteilt werden können.
@simon Vielen Dank für die Informationen! Es scheint, als würden wir hier Fortschritte machen.
Das ist in Ordnung, und ich habe bereits erwähnt, dass dies eine akzeptable Lösung für das Problem “alle E-Mails müssen eindeutig sein” ist. Ich bin vollkommen damit einverstanden, E-Mails in unserem Fall im Wesentlichen zu deaktivieren, und gefälschte E-Mails waren eine Lösung, zu der ich kam, bevor ich diesen Beitrag verfasst habe.
Ich war vielleicht ursprünglich nicht klar genug, aber der Punkt des Beitrags war zu prüfen, ob es möglich ist, die Anmeldeprompt so zu zwingen, dass sie nur Benutzernamen akzeptiert, da die Anmeldung derzeit entweder mit einem Benutzernamen oder einer E-Mail erfolgen kann. Wenn E-Mail-Logins weiterhin als verfügbar auf dem Anmeldeprompt auf Discourse angezeigt werden, könnten unsere Benutzer versuchen, ihre bestehende Konto-E-Mail-Adresse zu verwenden, und mit einer Fehlermeldung konfrontiert werden. Entweder müssten wir also einfach damit umgehen, dass Leute versuchen und scheitern, ihre aktuelle E-Mail-Adresse zu verwenden, oder wir müssten den Benutzer irgendwie auf seine neue, forumsspezifische E-Mail aufmerksam machen. Beides kann zu Verwirrung und Reibung bei den Benutzern führen, daher wäre es ideal, wenn wir den Anmeldeprompt einfach auf die Akzeptanz von Benutzernamen beschränken könnten.
Auch Mitarbeiter mit eindeutigen E-Mail-Adressen ist leider nicht garantiert, daher möchte ich mich nicht darauf verlassen. Deaktiviert diese Einstellung nur das Senden von E-Mails? Oder deaktiviert sie die Nutzung von E-Mails als Ganzes, wie ich es für den Anmeldeprompt suche?
Ich habe die Seite DiscourseConnect mehrmals durchgesehen und diese Option dort nicht gesehen. Gibt es vielleicht einen besseren Ort, um diese Art von Dokumentation einzusehen? Ich habe keine Links zu einer vollständigen Dokumentation in diesem Beitrag gesehen, daher ging ich davon aus, dass alle Informationen dort alles waren, was es gab.
Ich gebe zu, dass ich DiscourseConnect noch nicht selbst eingerichtet habe, um die Einstellungen zu durchforsten. Ich hoffte, dass die Dokumentation ausreichen würde, um zu verstehen, was möglich ist und was nicht, damit wir keine vollständige Testinstanz des Forums einrichten müssten, es sei denn, wir wüssten, dass wir uns dafür entscheiden würden. Aber es scheint, dass immer noch einige Informationen nicht ohne Weiteres verfügbar sind, es sei denn, ich habe etwas Offensichtliches übersehen?
Dies wurde ebenfalls früher in diesem Thread berücksichtigt, aber das Problem bleibt bestehen, dass wir entweder mit fehlgeschlagenen E-Mail-Logins umgehen oder den Benutzer über diese neue Forum-E-Mail-Adresse informieren müssten. Das Entfernen dieser Reibung war mein Hauptziel. Wenn dies hier nicht ohne Forking von Discourse selbst möglich ist und die einzige Lösung darin besteht, entweder mit fehlgeschlagenen E-Mail-Logins umzugehen oder den Leuten eine neue E-Mail zum Merken zu geben, dann sind wir mit einer anderen Forenlösung vielleicht besser dran.
Ich habe das anscheinend missverstanden, das ist nicht ganz klar, basierend auf dem Beitrag selbst. Mein Punkt für die Erwähnung war jedoch, die Abhängigkeit von eindeutigen E-Mail-Adressen zu verdeutlichen, was immer noch ein Problem wäre.
Das war definitiv nicht klar, basierend auf dem Beitrag allein, es sei denn, ich habe etwas übersehen. Vielen Dank für diese Klarstellung! Das klingt eher nach dem, was ich mir erhofft hatte.
Soweit ich weiß, ist es nicht möglich, die Discourse-Anmeldeaufforderung zu zwingen, nur das Feld für den Benutzernamen anzuzeigen. Sie müssten sich auch damit auseinandersetzen, wie Sie die Benutzer überhaupt registrieren können. Deshalb schlage ich DiscourseConnect vor.
Wenn DiscourseConnect aktiviert ist, wird es zum einzigen Authentifizierungssystem für Ihre Discourse-Site. Wenn Benutzer auf die Anmeldeschaltfläche auf Discourse klicken, werden sie automatisch zur URL weitergeleitet, die Sie in der Website-Einstellung discourse_connect_url hinzugefügt haben. Ihr Authentifizierungssystem übernimmt dann. Das bedeutet, dass Benutzer, die sich derzeit mit Benutzernamen und Passwörtern anmelden können, sich weiterhin auf diese Weise anmelden.
Um dies einzurichten, müssen Sie in der Lage sein, Code auf dem Backend der Website hinzuzufügen, in die sich Benutzer derzeit anmelden. Die Einrichtung ist nicht allzu schwierig. Hier finden Sie gute Beispielcode: wp-discourse/lib/sso-provider/discourse-sso.php at main · discourse/wp-discourse · GitHub. Sie können auch in diesem Forum Hilfe dazu erhalten.
Wenn das Hinzufügen von Code zu Ihrer aktuellen Website nicht möglich ist, könnten Sie auch eine kleine Website erstellen, auf der sich Benutzer mit Benutzernamen und Passwörtern anmelden können, und dann den DiscourseConnect-Code zu dieser Website hinzufügen. Das wäre weniger Arbeit, als Discourse zu forken.
Vielen Dank! Es scheint, dass ich ein grundlegendes Missverständnis von DiscourseConnect hatte. Ich ging davon aus, dass die Anmeldeseite auf Discourse verbleibt und diese einfach den externen Server kontaktiert. Ich war mir nicht bewusst, dass der Benutzer auf eine andere Anmeldeseite unserer Wahl weitergeleitet wird.
Mein Missverständnis von DiscourseConnect scheint der Kern dieses Problems und all der Verwirrung gewesen zu sein.
Wenn Sie sich nicht darum kümmern, dass Discourse E-Mails für Benachrichtigungen sendet, könnten Sie Ihrem SSO die E-Mail-Adresse game-username@bogus.invalid geben.
Es wäre dann möglicherweise möglich, dass Benutzer eine zweite echte E-Mail-Adresse hinzufügen und dann die ungültige durch die sekundäre ersetzen.
Meine Entschuldigung, ich habe Ihre Antwort gestern Abend nicht gesehen
Das hatte ich nicht. Wie ich bereits sagte, wollten wir keine Testbereitstellung durchführen, bis wir wussten, dass Discourse nutzbar ist. Also hatte ich noch nichts ausprobiert, bisher haben wir uns nur Ihre Funktionen angesehen und hier gefragt, wenn etwas unklar war. Das ist wirklich fantastisch zu hören, ich wusste nicht, dass wir Dinge in diesem Maße steuern können
Ehrlich gesagt, es scheint ziemlich schwierig zu sein, echte Dokumentationen zu allem außerhalb der API zu finden. Zumindest aus der Perspektive eines erstmaligen Benutzers.
Auf der Homepage von Discourse gibt es nichts Offensichtliches, das zu einer Dokumentation verlinken würde, und alle Links auf der DiscourseConnect-Seite verlinken entweder zu nicht verwandten Seiten oder zurück zum Beitrag selbst. Der Versuch, nach „Discourse-Dokumentation“ in Suchmaschinen zu suchen, führt nur zu Seiten wie Documentation - Discourse Meta, was nur die Forenkategorie dafür ist, keine echte Dokumentationsseite, und https://docs.discourse.org/, aber dies ist die API-Dokumentation und enthält keine Informationen zu Funktionen wie DiscourseConnect, scheint es.
Der Versuch, diese Informationen organisch zu finden, hat sich als schwierig erwiesen.
Gibt es eine offensichtliche Stelle, die ich einfach übersehen habe, an der all dies behandelt wird? Es scheint, dass die Forenkategorie die nächstgelegene ist, da es viele Anleitungen/How-tos von Mitarbeitern und dergleichen zu verschiedenen Themen gibt. Aber die Wiederverwendung des Forums zur Dokumentation selbst klang für mich nicht richtig? Gibt es keine spezielle Dokumentationsquelle für Discourse-Funktionen/-Tools, wie es sie für die Discourse-API gibt?
Korrekt, das würde funktionieren. Wie bereits mehrmals erwähnt, war die Verwendung einer ungültigen E-Mail-Adresse vom OAuth-Anbieter etwas, das wir bereits vor diesem Beitrag festgestellt hatten.
Aber das allein löst nicht das Problem, dass „wenn ein Benutzer im Anmeldeformular sieht, dass E-Mails akzeptiert werden, er versuchen würde, sie zu verwenden und aufgrund einer ungültigen E-Mail fehlschlägt“.
Ich habe jedoch gerade missverstanden, wie DiscourseConnect funktioniert. Ich war der Meinung, dass das Anmeldeformular immer noch auf Discourse liegt und dass Discourse einfach den OAuth-Anbieter kontaktiert. @simon hat das jetzt für mich korrigiert. Ich wusste nicht, dass der Benutzer physisch von der Website zu unserem eigenen Anmeldeformular weitergeleitet wird. Das allein löst praktisch alle meine Probleme. Danke trotzdem!
Auch wenn Sie nur die Reifen “treten” wollen und nicht beabsichtigen, unser Hosting weiter zu nutzen, können Sie gerne eine Testseite starten! Es macht uns nichts aus!
Vielen Dank für dieses Feedback – wir bemühen uns bewusst, dies zu verbessern.
Hätten Sie etwas dagegen, wenn wir Sie zur weiteren Besprechung kontaktieren?
Niemand, mit dem ich zusammengearbeitet habe, war unzufrieden mit dem Hosting von discourse.org. Wenn Sie aus irgendeinem Grund selbst hosten müssen, können Sie sich unter https://dashboard.literatecomputing.com/ anmelden, der Gruppe „kostenlose Testversion“ beitreten und das Dashboard kostenlos nutzen (wenn Sie nicht herausfinden können, wie Sie der Gruppe „kostenlose Testversion“ beitreten, benötigen Sie wahrscheinlich mehr Unterstützung, als ich geben möchte). Wenn Sie bereit sind, Digital Ocean und Mailgun zu verwenden, müssen Sie nur API-Schlüssel und einen Hostnamen eingeben.
Ich habe diese Option peinlicherweise gar nicht in Betracht gezogen! Das ist ein guter Punkt und wir werden das wahrscheinlich zu Testzwecken durchführen.
Ich hatte mir heute früher Ihre Hosting-Optionen angesehen, da dies einfacher wäre als Self-Hosting, aber es liegt leider weit außerhalb unseres Budgets. Wir haben über 200.000 Nutzer, daher ist der “Basic”-Plan keine Option. Wir haben mehr als 5 Mitarbeiter, daher ist der “Standard”-Plan keine Option. Und als FOSS-Projekt leben wir von Spenden und verdienen kaum genug, um die Lichter am Laufen zu halten und einen einzigen Vollzeitentwickler zu bezahlen, daher ist der “Business”-Plan sehr weit entfernt.
Die Nutzung des Trials zu Testzwecken ist jedoch eine fantastische Idee, danke! Wir hosten die meisten unserer Dienste ohnehin selbst, sogar unsere Mastodon-Instanz, daher ist das Self-Hosting von Discourse keine große Hürde.
Natürlich! Ich helfe immer gerne, wenn ich kann, auch wenn es nur ist, um etwas Feedback zu geben. Ich hoffe, es kam nicht zu negativ rüber, denn das war nicht die Absicht, um das klarzustellen.
Wenn Sie interessiert sind, bieten wir kostenloses Hosting für einige FOSS-Projekte an… Ihre Mitarbeiterzahlen sind höher als unsere Limits, aber die Leute, die die Entscheidung treffen, könnten das durchgehen lassen.
(Beachten Sie, dass unsere Definition von „Mitarbeitern“ hier „Administratoren“ + „Standortweite Moderatoren“ ist, nicht „Mitarbeiter des jeweiligen Unternehmens“ – ich wäre neugierig, was die Definition von Mitarbeitern in Ihrem Kopf war, bevor dies geschah)
Danke! Das hatte ich auf Ihrer Preisseite übersehen. Ich bin gerade noch einmal zurückgegangen, um nachzusehen, und es ist ganz unten auf der Seite vergraben Ich werde mir das ansehen und mit meinen Leuten sprechen!
Unsere Definition von „Mitarbeitern“ in diesem Fall umfasst 2 breite Rollen:
Personen in unserem Kernentwicklungsteam (als Open-Source-Projekt kann dies schwanken, da Personen kommen und gehen können, aber wir hatten über die Jahre hinweg zu jeder Zeit etwa 5-10 aktive Entwickler)
Unser Moderationsteam (Nicht-Entwickler und Community-Mitglieder, die unsere Dienste moderieren, wie Online-Spiele und unsere Miiverse-Implementierung sowie unseren Discord-Server). Dies variiert ebenfalls.
Wir könnten dies auf nur 5 unserer Entwickler beschränken, was innerhalb dieser Grenzen liegen würde, aber wir müssten entscheiden, wer volle Rechte im Forum hat und wer nicht. Es würde auch die Anzahl der Personen einschränken, die das Forum moderieren können (wir haben ein Moderationsteam außerhalb des Entwicklungsteams eingeführt, um diese Last von uns zu nehmen).
Ich werde dies auf jeden Fall mit meinen Leuten besprechen und sehen, wie es weitergeht!
Ich werde mir das ansehen und mit meinen Leuten sprechen!