Warum hier eine komplexe Abhängigkeit wählen, wenn ein trivialer E-Mail-Adressen-Sperrmodus so viel einfacher zu implementieren und nachzuvollziehen ist? Außerdem öffnen wir uns damit neuen Angriffsmöglichkeiten? Nein danke!
Angesichts der Seltenheit dieser Beschwerde und der außergewöhnlichen Umstände darum herum, halte ich den einfachen, besonders strengen Weg für vorzuziehen.
Der einfache Weg, alles zu verbieten, was nicht /a-zA-Z0-9/ entspricht, funktioniert zwar, hat aber erhebliche Usability-Probleme: Eine große Anzahl von Menschen wird nicht wissen, wie sie sich anmelden sollen, und wir müssten neue Fehlermeldungen erstellen. Viele Nutzer von Gmail wissen nicht, dass janedoe@gmail.com als ihre E-Mail-Adresse funktioniert, wenn sie immer dachten, es sei jane.doe@gmail.com. Ein Verbot würde OAuth beeinträchtigen und dazu führen, dass die Anmeldung mit Gmail fehlschlägt, damit es korrekt funktioniert.
E-Mail-Adresse:
sam.s@gmail.com
FEHLER:.ist in E-Mail-Adressen nicht erlaubt (neue Meldung)
Normalisierung ist weniger nutzerfeindlich und erfordert keine neuen UX-Änderungen.
Wir könnten mit einem einfacheren, optionalen Normalisierer beginnen (Tag entfernen, Punkt für Gmail entfernen).
Das gesagt: Um 100 % klar zu sein, schlage ich hier keine Abhängigkeit vor. email_address ist fehlerhaft und für unseren Zweck nicht geeignet.
Eine übereilte Halbmaßnahme würde lediglich eine Site-Einstellung namens „E-Mail auf meiner Site brechen
Richtig, aber seine Seite ist unter Beschuss. Tausende dieser duplizierten Konten melden sich täglich an. Daher ist es vernünftig, einen einfachen Sperrmodus für E-Mail-Adressen anzubieten, um Seiten zu unterstützen, die im Krieg mit dem Mossad liegen und dabei schlecht abschneiden.
Krieg erfordert Opfer. Es wird zivile Opfer geben. Seine Seite ist bereits völlig kaputt.
Idealerweise bräuchtest du eine Tabelle der E-Mail-Anbieter und wie man sie je nach Anbieter „bereinigt
Ich verstehe den Zusammenhang nicht.
Wenn wir bob.test+100@gmail.com intern als bobtest@gmail.com behandeln und so speichern (wenn der Schalter aktiviert ist), welches Opfer wird hier genau gebracht?
Der Fehler betrifft spezifisch gmail. Daher erscheint es mir als überzogene Reaktion, Punkte überall zu verbieten, nur weil Google beschlossen hat, eine Spezifikation zu erfinden und zu normalisieren. Die Logik zur Bereinigung ist eigentlich recht unkompliziert, und dies wäre standardmäßig deaktiviert.
@Mevo, nur um hier zu 100 % Klarheit zu schaffen: Der Vorschlag von Jeff besteht darin, einen „Katastrophenmodus
Ich würde empfehlen, den Vergleich mit der vereinfachten Form vorzunehmen, dabei aber darauf achten, die E-Mails weiterhin an die ursprünglich angegebene Adresse zu speichern und weiterzuleiten.
Sie haben keine Einwilligung des Nutzers, um andere Varianten zu kontaktieren, und die Verwendung einer anderen Adresse als der vom Nutzer angegebenen könnte dazu führen, dass die Nachricht nicht zugestellt wird.
Als Beispiel: Ich habe eine Gmail-Adresse, die in den ersten Monaten des Dienstes erstellt wurde. E-Mails an den Basis-Alias werden effektiv verworfen. Nur E-Mails, die bestimmte Plus-Adressen erreichen, werden jemals angezeigt.
Seien Sie auch bei Annahmen vorsichtig – viele Gmail-Nutzer wissen nicht, dass Punkte optional sind. Die überwältigende Mehrheit hat noch nie von Plus-Adressierung gehört. Eine Triagierung, um Missbrauch der letzteren zu verhindern, birgt das Risiko, die ersteren zu gefährden.
@sam Ich habe verstanden, was Jeff meint, und bin wie du gegen seinen Vorschlag (kein Offense, Meinungsverschiedenheiten passieren).
Das ist wahrscheinlich etwas pedantisch, aber wenn man nur die „bereinigte
Das ist ein sehr guter Punkt, es macht die Umsetzung etwas kniffliger.
Ich vermute, dass die Prüfung nur bei der Erstellung eines neuen Kontos durchgeführt wird:
Existiert bereits eine E-Mail-Adresse im System mit dieser kanonischen Form? Wenn ja, tut uns leid, kein neues Konto für Sie.
Es gibt ein Nebenthema bei Google OAuth (würde es auch nach der kanonischen E-Mail-Adresse prüfen) sowie den Übergang von nicht-kanonischen zu kanonischen Adressen.
OAuth funktioniert meines Wissens nach nicht mit Plus-Adressierung, fällt das also nicht aus dem Geltungsbereich?
Damit meine ich, dass ich kein neues Konto mit Google erstellen kann, einen anderen Alias angeben und das Ganze wiederholen kann.
Derselbe Problembereich.
Ich melde mich mit sam+hi@gmail.com an … und klicke dann auf die Schaltfläche „Mit Google anmelden“. Was passiert?
Aktuell: Neues Konto erstellt
Vorgeschlagen:
Option A: Fehlerbildschirm, Sie können dieses Konto nicht erstellen
Option B: Der Benutzer meldet sich mit sam+hi@gmail.com an
Ursprünglich vorgeschlagener Sperrmodus: sam.test@gmail.com kann sich nicht mit der Schaltfläche „Mit Google anmelden“ anmelden.
Wenn du eine robuste Übersetzung finden kannst, um Plus-Adressen und falsche Punkte zu entfernen, könntest du einfach einen Hash der bereinigten E-Mail-Adresse speichern und diesen beim Erstellen des Kontos damit vergleichen.
Das ist Option B, also Es gibt ein Nebenthema bei Google OAuth 
Das Migrationsproblem ist zwar heikel, ließe sich aber wahrscheinlich überspringen.
Angesichts des Ausmaßes des Problems in der Praxis gehe ich jedoch nicht davon aus, dass wir in den nächsten Monaten Änderungen daran vornehmen werden.
Wie oben erwähnt, wäre es keine Lösung, intern ausschließlich die ‘kanonische’ Version zu verwenden und zusätzlich das vom Benutzer Eingetragene zu speichern (nur zum Versenden von E-Mails)?
Das können wir problemlos lösen. Ich schätze, dass das Testen und Debuggen eines solchen neuen Switches 2–6 Arbeitstage in Anspruch nimmt, da es viele kleine Dinge zu beachten gibt.
Das Problem ist jedoch, dass @codinghorror die Bereitstellung dieser Zeit für diese Funktion nicht rechtfertigen kann.
Wir könnten break a big pile of email logins in einem Arbeitstag umsetzen, aber ich möchte eine solche Einstellung in Discourse nicht haben.
Daher befindest du dich hier in einer Zwickmühle, @Mevo … mehr Leute müssen dieses Problem erleben und melden, damit wir die Zeitinvestition dafür rechtfertigen können.
@sam Ich verstehe das.
(Übrigens, das sehe ich zum ersten Mal. Dein Beitrag wurde automatisch bearbeitet: „[system] — Zitat des gesamten vorherigen Beitrags automatisch entfernt“. Wow! Das ist eine wirklich tolle Funktion!)
Sie müssen sehr sorgfältig darauf achten, die kanonische Version niemals zu speichern. Der Nutzer hat nicht zugestimmt, sie bereitzustellen, und falls Ihre Nutzertabellen kompromittiert werden, können sie nicht sofort feststellen, welcher Dienst ihre Daten gefährdet hat.
Facebook ist wiederholt in große Schwierigkeiten geraten, weil es personenbezogene Daten (PII) von Nutzern gespeichert hat, die weder bereitgestellt noch zugestimmt haben, dass sie ihrem Konto zugeordnet werden.
Ich persönlich sehe überhaupt kein Problem mit dieser Einstellung. Ich bin nur widerwillig, es zu tun, weil „dieser eine Typ hatte einmal ein Problem".
Ja, das ist eine schreckliche Sache, die wir Discourse hinzufügen sollten. Ich wäre heftig dagegen, sie hinzuzufügen. Außerdem ist Adressierung eine Funktion, war immer eine Funktion, und sie ist benutzerfreundlich.
Wenn Sie von Mossad angegriffen werden … aktivieren Sie den Mossad-Angriffsmodus. Ich schätze, wir brauchen nur, dass Mossad mehr Leute angreift? 
Ich bin strikt gegen die Aufnahme dieser Einstellung in Discourse. Ich habe nichts dagegen, wenn jemand ein Plugin dafür entwickelt – das sind nur ein paar Zeilen Code in einem Plugin. Wenn Sie unbedingt darauf bestehen, mache ich heute eine Pause und baue das Plugin. Lassen Sie es mich einfach wissen.
Es ist ziemlich sinnlos, es zu entwickeln, da die einzige Person, die das Problem hat, bereits sagt, dass sie es nicht nutzen wird.
Eine Einstellung namens „Mein Discourse kaputt machen“ ist grundsätzlich schlecht und gehört meiner Meinung nach nicht in das Produkt.
Ich denke, wenn mehr Leute das Problem hätten, wäre ein E-Mail-Sperren-Modus eher vertretbar. Aber im Moment ist es nur dieser eine Typ auf dieser einen Seite.
Also warten wir es ab…
Ein Typ, auf einer Seite, der das Feature nicht nutzen würde
…ist genauer.