As the title says, if the user wants change their email address in the application, in terms of programming, what approach (process) to use? Where do you store the new email address until the user will confirms it?
-
3Would depend on the needs of the given application. Do I still need the old email? If not just overwrite and mark as not validated. If I want to keep the old one I need a second table (or field may be enough) obviously. What exactly is your problem?– thorsten müllerCommented Apr 19, 2013 at 10:48
-
2What have you tried? What's not working for you? Do you have to confirm the new email with the user? Some background information regarding your current change process would be helpful in answering your question.– user53019Commented Apr 19, 2013 at 11:09
-
2@thorstenmüller;@GlenH7: I want hold the old email until the user confirms its new email. i don't want overwrite the old email with new email before verification. my main issue is where can store new email temporally?– msoaCommented Apr 19, 2013 at 11:13
Add a comment
|
3 Answers
If you don't want to make a change to your user data storage (e.g. add another field to your database table.), you can include the new email address in the confirmation reply link as a parameter. For security purposes, you could also send a notice to the current address, "Hey, you're changing your email address to "whatever" so a confirmation was sent there...".
Your application will have to treat an email address change confirmatation a little different than your new account confirmation process by updating the email address. Maybe the old one is logged?
If the user chooses not to confirm your app doesn't have to do anything.
I don't know how critical an email address is to the application (relies heavily on notices or is just for your marketing purposes), but you may want to consider maintaining more than one. There can always be a default/main address. Old addresses are just disabled in case of a mix up.
-
@JeffO: How to include the new mail address in the confirmation replay string? there is no security risk?– msoaCommented Apr 19, 2013 at 13:46
-
You're sending an email to an address with the email address in the body of the message and you think there is a security risk?– JeffOCommented Apr 19, 2013 at 21:01
-
but anyone can edit that email and verify another email address. not sure of what use but it seems like inviting trouble one in a million. no need when we have so many free databases and cheap systems nowadays– tgkprogCommented Apr 19, 2013 at 22:03
-
@tgkprog: Well, that could be avoided by also including a cryptographic checksum, or by encrypting the address parameter.– BrianCommented Aug 17, 2013 at 19:39
I think the best approach would be to create a new table called email_resets, where you will have a few fields:
id | new_email | old_email | hash | date_added
Then send the user a reset email link on the old email address. Inform the user that his email will be changed to [email protected], and then when he clicks the link, check the hash, email and the time when the request was made, then you can update your main user table, and delete the reset email entry. (you can replace old_email with user_id, and maybe remove the id field completely)
The advantages would be the following:
- no alterations to the main table (neither database structure, nor the values stored)
- you have full control over the time limit (ie reset email link will only be available for X hours), and you can make a cron job to clean up the table.
- little extra memory needed - if the email reset requests are cleaned up every few hours/days
PS: A randomly generated hash is also needed (this is the reason behind the hash field), besides the expire time to make sure these requests cannot be forged.
is the email id the login id? is it used as a reference anywhere else? does the user row have a different primary key?
If designed well then the table has a Db / separate primary key (and the email id it self is not a foreign key elsewhere). Then you could keep new email addresses in a different table till its verified along with the key to who it belongs. also as validation make sure same email id is not used by other user nor is it under validation by someone other user.
once validated, update to the main table, remove from the temp table and if you can keep the old email in an audit table
-
@tgkprog: Isn't login id, isn't reference, other primary key exist. What type of storage engine(Mysql) is suitable for keeping new email and related information? (for a week)– msoaCommented Apr 19, 2013 at 11:49
-
i do not know about engine, but a basic table with the new email, user id, the random verify string and date of sign up, date of expiry? what do you mean by storage engine? type of chars?– tgkprogCommented Apr 19, 2013 at 12:01
-
**@tgkprog: **The fields your refer is suitable, thanks. storage engines like myIsam,innodb,Memory and . . . however not important for now.– msoaCommented Apr 19, 2013 at 13:15
-
i would not go with memory. hard disk is cheap no? what is the adv of in mem? myIsam and inno read about it long back but forget. i think the default should be fine– tgkprogCommented Apr 19, 2013 at 22:04