Anyone have a Best Practice approach on confirming the registrants email address before allowing access?

Where activating the user account only after sending an "Almost done, last step" email to the email address included in the Register.aspx form with a link to postback to the site and auto unlock the account?

Much like signing up for this forum... Here's a sample link I received in my inbox to complete the registration for this forum:

http://p2p.wrox.com/register.asp?act...lg1738497dci6h

Clearly the actkey is the 'key'... But where to start

you can do this:

- Create a new role "TempUsers"
  with that you can see the users there are waiting from one email, or the users that inserted a wrong email
- When some user try to register, they will be added to the "TempUsers" role and their login will be disabled.
- Send an autoemail with the actication code: http://www.domain.com/activate.aspx?...gjkhdslfghsdfg
  So, waht code can you use? I use the memberID :) Why? Because it work! You could still disable the member in the future if you want because if he discover that the activate link that i receive in the past could enable the login he will be wrong because this link will only enable users that are in "TempUsers" role! Understand?
- Make a new page "activate.aspx"
 - In this page catch the querystring for "member" and "code"
 - Call your DB to retrieve dthe memberID for the member expressed in querystring
 - Compare the two of them.
 - If they match, see if the member is in the "tempUsers" Role.
 - If it is, enable the member, remove him from the tempusers role and show in one message with:
   "Thanks, Your account has been activated, please login!"

Good luck

There is actually a pretty good explanation of how to do this using GUIDs here:

http://forums.asp.net/p/1205725/2110325.aspx

Maxxim thanks for the solution, and Lee Dumond thanks for the asp.net link. This should give me a clearer direction on implementing this.

Hi kabel,

I've done something along the following:

* User is initially created as inactive. I threw in a captcha during the registration process as well, in an attempt to weed out bots.
* A GUID is created and stored in a temporary table along with the userID and the mail address.
* The user is sent a mail with said link.
* When the user hops to the activation page, the temporary table is checked to verify the existance of the code / mail address combination. If present, the line will be deleted, and the account activated.

I must admit my code doesn't quite stick to the whole TBH approach (in that I do not use objects, but directly fire some procedures), but that ought to be easy enough to change.

Drop me a PM if you'd like to see my implementation :-) (The PM so I'll receive a mail about it, and will remember it).

Cheers,

Peter

http://entropia-online.blogspot.com/

Excuse me for asking, but I'm not exactly sure why some of you are going to this trouble of creating a new GUID, temporary tables, etc.

The userID itself is already a GUID. You can get it from the following:

Guid userId = (Guid)user.ProviderUserKey;

Just make sure to set the IsApproved property to false upon initial creation of the user. then set it to true in your activation page.

Lee,

You're right. You don't need to create another GUID in a tempTable, or a TempUser Role, but like Maxxim said and ViagraFalls implemented. What if you disable the account in the future?

If only the UserId was used in the key, there is nothing to stop the user from using the same link to reestablish access. I reviewed the link from the asp.net forum, and it would seem, that would be the case in that example. If I'm seeing it right ???

Either way.. I wan't to thank everyone for the help. This is the first forum I've participated in and the help has been invaluable...! :)

Good point, I didn't think of that. Now that I look at the solution above that uses a TempUsers role, I see what you mean.

Mostly I implemented it this way to be able to remove users that never confirmed their mail address. Reasoning is that I know some of my potential userbase can be true dingleberries, and could possibly attempt to fill my database with bogus mail addresses. While the created database garbage would not be harmfull, it will most definitly have a bigger impact when attempting to use the database for data mining/marketing purposes.

Hence, I chose to implement the most strict method, where I'll automatically remove all accounts that haven't been confirmed within a week. Should I later on choose to port my code for other sides, the method will be in place, but can easily be disabled :)

Cheers.

http://entropia-online.blogspot.com/

Hi Peter,

I sent you a message through your site, not sure if you received it, but I'd really like to see your implementation on this.

It seems like you've created the exact same direction I want to take. I was also thinking of adding to the procedure the ability to remove the user after 10 days if he/she didn't activate the account. You've done that too.! :-)