Wie Jeff Atwood sagte, ist E-Mail das Herzstück von Discourse, und wir sollten es nicht ignorieren oder umgehen.
Die Realität kann jedoch ungestümer sein als unsere Vorstellung: Einige Plattformen stellen keine E-Mail-Adresse bereit, und wir möchten diese dennoch in unser Discourse integrieren. Die Lösung discourse-oauth2-basic ist
discourse-oauth2-basic ist ein allgemeines OAuth2-Plugin und enthält daher keine Funktionen für eine spezielle Plattform. Wenn wir jedoch einen plattformspezifischen Authentifizierer entwickeln, der keine E-Mail-Adresse bereitstellt, möchten wir möglicherweise das Benachrichtigungssystem der Plattform anstelle der standardmäßigen E-Mail-Benachrichtigung integrieren.
Mein vorgeschlagener Ansatz besteht darin, eine fiktive E-Mail-Adresse für eine eindeutige Identität zu erstellen, z. B. plattformspräfix + plattform-id@ihrediscourse.com, einen E-Mail-Validierer, um zu entscheiden, welches Benachrichtigungssystem verwendet werden soll, oder Hooks und Filter, um einen Absender beim Senden einer Benachrichtigung zu definieren – entweder die standardmäßige E-Mail-Benachrichtigung oder eine vom Authentifizierer implementierte. Ich denke, dies ist eine nicht-invasive Implementierung für die bestehende Architektur.
Das ist absolut machbar. Beispielsweise können Sie sich mit Steam anmelden (was keine E-Mail-Adresse bereitstellt), in einer geforkten Version des Plugins gefälschte E-Mail-Adressen festlegen und native Push-Benachrichtigungen (verfügbar unter Windows, macOS, Linux und Android) für alle Benachrichtigungsbedürfnisse nutzen.
Es wird immer etwas Anpassungsarbeit erfordern, um mit der spezifischen Plattform zu integrieren, und bei Discourse gibt es einige Kunden, die ein solches Setup mit großem Erfolg einsetzen. Sie gehören zu den größten Instanzen überhaupt!
Ja, aber Discourse scheint Export-Benachrichtigungen direkt über Email::Sender per Hardcoding zu versenden, anstatt einen Benachrichtigungs-Event-Hook wie DiscourseEvent aufzurufen.