Perché adottare una dipendenza complessa quando una modalità di blocco dell’indirizzo email banale è molto più semplice da implementare e da analizzare? Inoltre, ora ci espone a nuovi exploit? No, grazie!
Data la rarità di questo reclamo e le circostanze eccezionali che lo circondano, ritengo che sia preferibile scegliere la strada semplice ma estremamente rigorosa.
La soluzione semplice di bloccare tutto ciò che non corrisponde a /a-zA-Z0-9/ funziona, ma presenta gravi problemi di usabilità: un gran numero di persone non saprà come registrarsi e dovremmo creare nuovi messaggi di errore. Molte persone che usano Gmail non sanno che janedoe@gmail.com funziona come loro indirizzo email, dato che hanno sempre pensato che fosse jane.doe@gmail.com. Il blocco avrebbe un impatto su OAuth e causerebbe il fallimento dell’accesso tramite Gmail per far funzionare correttamente il sistema.
Indirizzo email:
sam.s@gmail.com
ERRORE:.non è consentito negli indirizzi email (nuovo messaggio)
La normalizzazione è meno ostile all’utente e non richiede nuove interfacce utente (UX).
Potremmo iniziare con un normalizzatore più semplice e opzionale (rimuovere il tag, rimuovere il punto per Gmail).
Detto questo, per essere assolutamente chiari, non sto suggerendo di introdurre una dipendenza qui: email_address è difettoso e non adatto a quanto vogliamo ottenere.
Una soluzione frettolusa e parziale creerebbe semplicemente un’impostazione del sito “rompi-email sul mio sito”, alla quale non sono particolarmente interessato ad aggiungere.
Giusto, ma il suo sito è sotto assedio. Ogni giorno si registrano migliaia di questi account duplicati. Quindi ha senso che esista una modalità di blocco semplice per gli indirizzi email, da offrire ai siti che sono in guerra con il Mossad e stanno perdendo clamorosamente.
La guerra richiede sacrifici. Ci saranno vittime civili. Il suo sito è già completamente rotto.
Idealmente, servirebbe una tabella con i provider di posta elettronica e le relative procedure per “pulire” gli indirizzi (proprio come hai citato). Come Bart ha spiegato bene, non si tratta di impedire l’uso di indirizzi email contenenti determinati caratteri, ma di essere in grado di rilevare quali indirizzi sono effettivamente identici.
Certamente, gli spammer che lo desiderano davvero riusciranno sempre a farlo. È come con allarmi e serrature rispetto ai ladri: l’idea è rendere le cose più difficili.
Creare molti indirizzi Gmail è spam per Gmail; è un loro problema da risolvere (anche se ciò potrebbe essere usato successivamente per inviarti spam).
Non capisco.
Se trattiamo bob.test+100@gmail.com come bobtest@gmail.com internamente e lo memorizziamo in questo modo (quando l’interruttore è attivo), quale sacrificio viene esattamente fatto?
Il bug è specifico per gmail, quindi a me sembra una reazione eccessiva vietare tutti i punti ovunque solo perché Google ha deciso di inventare una specifica e normalizzare. La logica per la pulizia è in realtà molto semplice e questa opzione sarebbe disattivata per impostazione predefinita.
@Mevo, solo per essere chiari al 100% qui, la proposta di Jeff è che aggiungiamo una “modalità disastro”; in modalità disastro bob.test@gmail.com è un indirizzo email non valido che non può essere utilizzato.
Suggerirei di confrontarlo con la forma semplificata, ma devi fare attenzione a memorizzare e inoltrare comunque le email all’indirizzo specificato originalmente.
Non hai il consenso dell’utente per inviare messaggi a qualsiasi altra variante, e l’uso di qualsiasi cosa diversa dall’indirizzo da loro specificato potrebbe comportare che non ricevano il messaggio.
Ad esempio, ho un indirizzo Gmail creato nei primi mesi del servizio. Le email inviate all’alias di base vengono effettivamente scartate. Solo le email che raggiungono indirizzi plus specifici verranno mai visualizzate.
Fai attenzione anche alle ipotesi: molti utenti Gmail non sanno che i punti sono opzionali. La stragrande maggioranza non ha mai sentito parlare dell’indirizzamento plus. Una triage per prevenire l’abuso di quest’ultimo rischia di causare danni a quelli del primo gruppo.
@sam Ho capito perfettamente cosa intende Jeff e, come te, sono contrario a quanto propone (senza offesa per lui, le divergenze ci stanno).
Forse sto entrando nei dettagli, ma conservare solo l’indirizzo email “ripulito” eliminerebbe ciò che alcuni utenti legittimi fanno intenzionalmente. Ad esempio: un utente che si registra (in modo totalmente legittimo e una sola volta) con bob+meta@example.com o bob+forums@example.com perderebbe ciò che cercava di ottenere. Il problema è che riceverà email solo a bob@example.com, e non è quello che voleva (può, ad esempio, utilizzare il “tag” per spostare le email ricevute in una cartella specifica).
Capisco perfettamente che tenere conto di questo renderebbe il sistema un po’ più complesso. Dovresti conservare ENTRAMBE le versioni: quella inserita dall’utente (per inviare email) e quella ripulita. Potresti usare la versione ripulita come usi gli indirizzi email attualmente (per tutto ciò che riguarda internamente l’utente e per verificare se l’utente è già registrato). Inoltre, per evitare questo piccolo problema, dovresti conservare anche ciò che l’utente ha inserito (esclusivamente per l’invio delle email). Sarebbe l’equivalente dell’indirizzo “rispondi a” nelle email.
Spero sia chiaro.
EDIT: Scritto nello stesso momento di @Stephen (in linea di massima la stessa idea)
È un punto molto valido, rende effettivamente la realizzazione leggermente più complessa.
Immagino che il controllo venga eseguito solo durante la “creazione di un nuovo account”:
Esiste già nel sistema un indirizzo email con questa forma canonica? In tal caso, ci dispiace, non è possibile creare un nuovo account.
C’è poi un problema collaterale legato all’autenticazione OAuth di Google (verificherebbe anche l’email canonica?) e alla transizione da un indirizzo non canonico a uno canonico.
Per quanto ne so, OAuth non funziona con l’indirizzamento plus, quindi non è forse fuori dall’ambito di applicazione?
Con questo intendo che non posso creare un nuovo account utilizzando Google, specificare un alias diverso, e ripetere l’operazione.
Stesso ambito di problema.
Mi iscrivo con sam+hi@gmail.com … poi clicco sul pulsante “Accedi con Google”, cosa succede?
Attualmente: viene creato un nuovo account
Proposta:
Opzione A: schermata di errore, non è possibile creare questo account
Opzione B: l’utente accede con sam+hi@gmail.com
Modalità di blocco proposta originale: sam.test@gmail.com non può accedere tramite il pulsante “Accedi con Google”.
Supponendo di poter elaborare una traduzione robusta per rimuovere gli indirizzi con il segno più e i punti errati, potresti semplicemente mantenere un hash dell’email de-duplicata e confrontarlo con la creazione di quell’account?
Quella è l’opzione B, quindi c’è un problema collaterale legato all’autenticazione OAuth di Google 
Inoltre, la migrazione è complessa, ma probabilmente potrebbe essere saltata.
Detto questo, data la portata del problema in circolazione, non prevedo che lavoreremo su modifiche in questo ambito nei prossimi mesi.
Come detto sopra, utilizzare internamente solo la versione “canonica” e memorizzare inoltre ciò che l’utente ha inserito (solo per inviare e-mail) non sarebbe una soluzione?
Possiamo risolvere questo problema senza problemi: stimo che serviranno 2-6 giorni di lavoro per testare e correggere un nuovo switch del genere, dato che ci sono molte piccole cose da tenere in considerazione.
Il problema qui è che @codinghorror non può giustificare l’allocazione di questa quantità di tempo per questa funzionalità.
Possiamo implementare rompi un mucchio di accessi via email in un giorno di lavoro, ma non voglio avere una tale impostazione in Discourse.
Quindi ti trovi in una situazione un po’ delicata, @Mevo… servono più persone che sperimentino e segnalino questo problema, così da poter giustificare l’investimento di tempo su di esso.
@sam Capisco perfettamente.
(a proposito, è la prima volta che vedo questa cosa. Il tuo post è stato modificato automaticamente: " [system] — Rimozione automatica della citazione dell’intero post precedente". Wow! È una funzionalità davvero utile!)
Devi fare molta attenzione a non memorizzare mai la versione canonica. L’utente non ha acconsentito a fornirla e, se le tabelle degli utenti vengono compromesse, non è possibile identificare facilmente quale servizio ha violato i loro dati.
Facebook è stato ripetutamente coinvolto in gravi problemi per la memorizzazione di informazioni personali identificative (PII) relative agli utenti, che questi non hanno fornito né acconsentito a associare al proprio account.
Personalmente non vedo alcun problema con questa impostazione; sono semplicemente riluttante a farlo perché “quello tizio ha avuto un problema una volta”.
Già, è una cosa terribile suggerire di aggiungerla a Discourse. Mi opporrei con violenza all’aggiunta. Inoltre, l’indirizzamento è una funzionalità, è sempre stata una funzionalità ed è user-friendly.
Se state subendo attacchi da parte del Mossad… attivate la Modalità Attacco Mossad. Immagino che dobbiamo solo far sì che il Mossad attacchi più persone? 
Sono fermamente contrario all’aggiunta di questa impostazione a Discourse. Non ho alcun problema se qualcuno crea un plugin per essa: bastano poche righe di codice in un plugin. Se proprio devi averla, farò una pausa e costruirò il plugin oggi stesso, fammi solo sapere.
È un po’ inutile costruirlo, dato che l’unica persona che ha il problema ha già dichiarato che non lo userà.
Un’impostazione del tipo “rompi il mio Discourse” è fondamentalmente sbagliata e, a mio avviso, non appartiene al prodotto.
Credo che se più persone avessero questo problema, una modalità di blocco per email sarebbe più giustificabile. Ma al momento è solo quel tizio su quel sito.
Quindi aspettiamo e vediamo…
Un solo tizio, su un solo sito, che non utilizzerebbe la funzionalità
…è più accurato…