# Integration in ein benutzerdefiniertes Authentifizierungssystem, bei dem E-Mails nicht eindeutig sind **URL:** \ **Category:** SSO\ **Tags:** email\ **Created:** [2. Mai 2024 um 15:50 UTC](https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489 "2024-05-02T15:50:43Z")\ **Posts on this page:** 1\ **Showing post:** 6
**Author:** ![jonbarrow](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/jonbarrow/32/383296_2.png) [@jonbarrow](https://meta.discourse.org/u/jonbarrow)\ **Post date:** [2. Mai 2024 um 23:52 UTC](https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489/6 "2024-05-02T23:52:09Z")
> [@pfaffman](#): > > Es sei denn, sie haben sich mit dem Benutzernamen angemeldet. 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. > [@pfaffman](#): > > Sie müssten es bewusst machen. Ich denke, das wäre der erste Schritt. 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. > [@pfaffman](#): > > Eine weitere hässliche Option wäre, nur dem „ersten“ (wie auch immer das definiert wird) Benutzer die Anmeldung bei Discourse überhaupt zu ermöglichen. 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. > [@pfaffman](#): > > Eine weitere hässliche Lösung wäre, Benutzer in Ihrem System zu zwingen, eindeutige Adressen für jedes Konto zu erhalten. 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](https://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. --- _[View the full topic](https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489)._