Pourquoi ajouter une dépendance complexe ici alors qu’un verrouillage trivial par adresse e-mail est bien plus simple à mettre en œuvre et à comprendre ? De plus, cela nous expose désormais à de nouvelles failles d’exploitation ? Non merci !
Compte tenu de la rareté de cette plainte et des circonstances exceptionnelles qui l’entourent, je pense que la voie simple et ultra-strict est préférable.
La solution simple consistant à interdire tout ce qui n’est pas /a-zA-Z0-9/ fonctionne, mais elle pose d’importants problèmes d’utilisabilité : un grand nombre de personnes ne sauront pas comment s’inscrire, et nous aurions besoin de nouveaux messages d’erreur. Beaucoup de personnes utilisant Gmail ignorent que janedoe@gmail.com fonctionne comme adresse e-mail alors qu’elles pensaient toujours que c’était jane.doe@gmail.com. L’interdiction affecterait OAuth et empêcherait la connexion via Gmail de fonctionner correctement.
Adresse e-mail :
sam.s@gmail.com
ERREUR : le caractère.n’est pas autorisé dans les adresses e-mail (nouveau message)
La normalisation est moins hostile pour l’utilisateur et ne nécessite aucune nouvelle interface utilisateur.
Nous pourrions commencer par un normalisateur optionnel plus simple (supprimer le tag, supprimer le point pour Gmail).
Cela dit, pour être parfaitement clair, je ne recommande pas une dépendance ici : email_address est défectueux et ne convient pas à ce que nous cherchons à faire.
Une mesure à moitié précipitée ici ne fera que créer un paramètre de site « casser les e-mails sur mon site », que je ne suis pas particulièrement enthousiaste à l’idée d’ajouter.
C’est vrai, mais son site est sous le feu. Des milliers de ces comptes dupliqués s’inscrivent chaque jour. Il est donc logique qu’il existe un mode de verrouillage simple pour les adresses e-mail, à proposer aux sites qui sont en guerre contre le Mossad et qui perdent lamentablement.
La guerre exige des sacrifices. Il y aura des victimes civiles. Son site est déjà cassé comme un malade.
Idéalement, il faudrait un tableau répertoriant les fournisseurs de messagerie et la façon de « nettoyer » les adresses selon chaque fournisseur (exactement ce que vous avez cité). Comme Bart l’a bien expliqué, il ne s’agit pas d’empêcher l’utilisation d’adresses e-mail contenant certains caractères, mais de pouvoir détecter quelles adresses sont en réalité identiques.
Bien sûr, les spammeurs qui le souhaitent vraiment y parviendront toujours. C’est comme avec les alarmes/serrures et les voleurs : l’idée est de rendre les choses plus difficiles.
Créer des dizaines de comptes Gmail constitue du spam envers Gmail ; c’est un problème qu’ils doivent régler (même si cela peut ensuite être utilisé pour vous envoyer du spam).
Je ne suis pas sûr de bien comprendre.
Si nous traitons bob.test+100@gmail.com comme bobtest@gmail.com en interne et que nous le stockons ainsi (lorsque l’option est activée), quel est exactement le sacrifice en question ?
Le bug concerne spécifiquement Gmail ; il me semble donc excessif d’interdire tous les points partout simplement parce que Google a décidé d’inventer une spécification et de normaliser. La logique de nettoyage est en réalité assez simple et cette option serait désactivée par défaut.
@Mevo, juste pour être absolument clair : la proposition de Jeff ici est d’ajouter un « mode catastrophe ». Dans ce mode, bob.test@gmail.com est considéré comme une adresse e-mail invalide qui ne peut pas être utilisée.
Je suggérerais de comparer à la forme simplifiée, mais vous devez veiller à toujours stocker et acheminer les e-mails vers l’adresse initialement spécifiée.
Vous n’avez pas le consentement de l’utilisateur pour envoyer des messages à toute autre variante, et l’utilisation d’une adresse différente de celle qu’il a spécifiée pourrait entraîner le fait qu’il ne reçoive pas le message.
Par exemple, j’ai une adresse Gmail créée lors des premiers mois du service. Les e-mails envoyés à l’alias de base sont effectivement rejetés. Seuls les e-mails qui atteignent des adresses avec un signe plus spécifique sont jamais vus.
Méfiez-vous également des suppositions : de nombreux utilisateurs de Gmail ignorent que les points sont optionnels. La grande majorité n’a jamais entendu parler de l’adressage avec un signe plus non plus. Un triage pour prévenir les abus de ce dernier risque de causer des dommages au premier.
@sam J’ai bien compris ce que Jeff veut dire, et comme toi, je suis contre ce qu’il propose (aucune offense pour lui, les désaccords arrivent).
C’est probablement être pointilleux, mais stocker uniquement l’adresse e-mail « nettoyée » supprimera ce que certains utilisateurs légitimes font intentionnellement. Par exemple : un utilisateur qui s’inscrit (tout à fait légitimement et une seule fois) avec bob+meta@example.com ou bob+forums@example.com perdra ce qu’il cherchait à accomplir. Le problème est qu’il ne recevra des e-mails qu’à l’adresse bob@example.com, ce qui n’est pas ce qu’il souhaitait (il peut par exemple utiliser le « tag » pour placer les e-mails reçus dans un dossier spécifique).
Je comprends tout à fait que prendre cela en compte rendrait le système un peu plus complexe. Il faudrait stocker à la fois la version entrée par l’utilisateur (pour envoyer des e-mails) ET la version nettoyée. Vous pouvez utiliser la version nettoyée comme vous utilisez les adresses e-mail actuellement (pour tout ce qui est interne à l’utilisateur et pour vérifier si cet utilisateur est déjà inscrit). De plus, pour éviter ce petit problème, il faudrait stocker ce que l’utilisateur a saisi, en plus de cela (uniquement pour l’envoi d’e-mails). Ce serait l’équivalent de l’adresse « répondre à » dans les e-mails.
J’espère que c’est compréhensible.
EDIT : Écrit en même temps que @Stephen (globalement la même idée)
C’est un point très pertinent, cela rend la mise en œuvre légèrement plus complexe.
Je suppose que vous ne feriez cette vérification que lors de la « création d’un nouveau compte » :
Existe-t-il déjà dans le système une adresse e-mail correspondant à cette forme canonique ? Si oui, désolé, aucun nouveau compte pour vous.
Il y a aussi un problème secondaire lié à l’authentification Google OAuth (vérifierait-elle également l’e-mail canonique), ainsi que la transition d’une adresse non canonique vers une adresse canonique.
À ma connaissance, OAuth ne fonctionne pas avec l’adressage par « plus », donc cela ne relève-t-il pas du hors champ ?
Par là, j’entends que je ne peux pas créer un nouveau compte avec Google, spécifier un autre alias, puis recommencer.
Même espace de problème.
Je m’inscris avec sam+hi@gmail.com… puis je clique sur le bouton « Se connecter avec Google », que se passe-t-il ?
Actuellement : un nouveau compte est créé
Proposé :
Option A : écran d’erreur, vous ne pouvez pas créer ce compte
Option B : l’utilisateur se connecte avec sam+hi@gmail.com
Mode verrouillé proposé à l’origine : sam.test@gmail.com ne peut pas se connecter avec le bouton « Se connecter avec Google ».
En supposant que vous puissiez concevoir une traduction robuste pour supprimer les adresses avec des plus et les points superflus, vous pourriez simplement conserver un hachage de l’adresse e-mail dédupliquée et le comparer lors de la création du compte.
C’est l’option B, d’où « Il y a un problème secondaire avec Google OAuth » 
De plus, la migration est complexe, mais on pourrait probablement l’omettre.
Cela dit, compte tenu de l’ampleur du problème rencontré dans la pratique, je ne m’attends pas vraiment à ce que nous travaillions sur des modifications dans les prochains mois.
Comme mentionné précédemment, utiliser uniquement la version « canonique » en interne et stocker en plus ce que l’utilisateur a saisi (uniquement pour envoyer des e-mails) ne serait-ce pas une solution ?
Nous pouvons tout à fait résoudre cela. J’estime qu’il faudra entre 2 et 6 jours de travail pour tester et déboguer un tel nouveau commutateur, car il y a beaucoup de petits détails à prendre en compte.
Le problème ici, c’est que @codinghorror ne peut pas justifier l’allocation de ce temps pour cette fonctionnalité.
Nous pouvons implémenter casser un gros tas de connexions par e-mail en une journée de travail, mais je ne veux pas d’un tel paramètre dans Discourse.
Donc, vous êtes un peu coincé là, @Mevo… Il faut que plus de personnes rencontrent et signalent ce problème afin que nous puissions justifier de consacrer du temps à cela.
@sam Je comprends tout à fait.
(Au fait, c’est la première fois que je vois ça. Ton message a été automatiquement modifié : " [system] — Suppression automatique de la citation du message précédent". Waouh ! C’est une fonctionnalité vraiment sympa !)
Vous devez faire très attention à ne jamais stocker la version canonique. L’utilisateur n’a pas donné son consentement pour la fournir, et si vos tables d’utilisateurs sont compromises, il ne pourra pas facilement identifier quel service a compromis ses données.
Facebook a à plusieurs reprises été mis en difficulté pour avoir stocké des informations personnelles identifiables (PII) relatives à des utilisateurs qu’ils n’ont ni fournies, ni consenti à associer à leur compte.
Je ne vois personnellement aucun problème avec ce paramètre ; je suis simplement réticent à le faire à cause de « ce type qui a eu un problème une fois ».
Oui, c’est une terrible chose à suggérer d’ajouter à Discourse. Je m’y opposerais violemment. De plus, l’adressage est une fonctionnalité, l’a toujours été, et c’est convivial pour l’utilisateur.
Si vous êtes attaqué par le Mossad… activez le mode attaque Mossad. Il faut juste que le Mossad attaque plus de gens, je suppose ? 
Je suis farouchement opposé à l’ajout de ce paramètre dans Discourse. Je n’ai aucun problème avec le fait que quelqu’un crée un plugin pour cela ; il ne s’agit que de quelques lignes de code dans un plugin. Si vous devez absolument l’avoir, je prendrai une pause et je construirai le plugin aujourd’hui, faites-le-moi savoir.
C’est un peu inutile de le construire, car la seule personne qui a le problème a déjà indiqué qu’elle ne l’utiliserait pas.
Un paramètre du type « casser mon Discourse » est fondamentalement mauvais et ne devrait pas faire partie du produit, à mon avis.
Je pense que si plus de personnes rencontraient ce problème, un mode de verrouillage par e-mail serait plus défendable. Mais pour l’instant, c’est juste ce gars-là sur ce site-là.
Alors on attend et on voit…
Un gars, sur un site, qui n’utiliserait pas la fonctionnalité
C’est plus exact…