Come dice il titolo, se l'utente desidera modificare il suo indirizzo e-mail nell'applicazione, in termini di programmazione, quale approccio (processo) utilizzare? Dove memorizzi il nuovo indirizzo email finché l'utente non lo confermerà?
Se non si desidera apportare modifiche all'archiviazione dei dati dell'utente (ad esempio, aggiungere un altro campo alla tabella del database), è possibile includere il nuovo indirizzo email nel collegamento di risposta di conferma come parametro. Per motivi di sicurezza, potresti anche inviare un avviso all'indirizzo corrente, "Ehi, stai cambiando il tuo indirizzo email in" qualunque cosa ", quindi è stata inviata una conferma lì ...".
La tua applicazione dovrà considerare una conferma della modifica dell'indirizzo email un po 'diversa dalla nuova procedura di conferma dell'account aggiornando l'indirizzo email. Forse il vecchio è registrato?
Se l'utente sceglie di non confermare la tua app non deve fare nulla.
Non so quanto sia critico un indirizzo email per l'applicazione (dipende molto dalle comunicazioni o è solo per scopi di marketing), ma potresti voler considerare di mantenerne più di uno. Ci può sempre essere un indirizzo predefinito / principale. I vecchi indirizzi sono semplicemente disabilitati in caso di confusione.
Penso che l'approccio migliore sarebbe creare una nuova tabella chiamata email_resets , in cui avrai alcuni campi:
id | new_email | old_email | hash | date_added
Quindi invia all'utente un link email di ripristino sul vecchio indirizzo email. Informa l'utente che la sua email sarà cambiata in [email protected] , quindi quando farà clic sul link, controllerà l'hash, l'email e l'ora in cui è stata effettuata la richiesta, quindi potrai aggiornare il tuo tabella utente principale ed eliminare la voce di posta elettronica di ripristino. (puoi sostituire old_email con user_id e forse rimuovere completamente il campo id )
I vantaggi sarebbero i seguenti:
PS: è necessario anche un hash generato in modo casuale (questo è il motivo alla base del campo hash ), oltre al tempo di scadenza per assicurarsi che queste richieste non possano essere falsificate.
l'ID e-mail è l'ID di accesso? è usato come riferimento altrove? la riga utente ha una chiave primaria diversa?
Se progettato bene, la tabella ha una chiave primaria Db / separata (e l'id email non è una chiave esterna altrove). Quindi è possibile mantenere nuovi indirizzi e-mail in una tabella diversa finché non vengono verificati insieme alla chiave a cui appartiene. anche come convalida assicurati che lo stesso ID email non venga utilizzato da altri utenti né sia sottoposto a convalida da parte di altri utenti.
una volta convalidato, aggiorna alla tabella principale, rimuovi dalla tabella temporanea e se puoi mantenere la vecchia email in una tabella di controllo
Leggi altre domande sui tag validation email user-experience information