How should email address opt-in implemented?

views:

answers:

+2 Q:

How should email address opt-in implemented?

Scenario:

User gives you an email address. Before they can sign up for services, they need to validate the email address - you email out a URL, they click on it, then they can subscribe to the services.

Questions:

What does the URL look like? I'm thinking a random guid would be OK.

Do you use that same random key for unsubscribe requests?

Are there any good open source implementations of double-opt in I should be looking at?

+1 A:

This is pretty simple to implement with a random string and a GET request. I probably wouldn't use the same for unsubscribe, because you know most people are going to lose the original email. Do it the same way -- they say they want to unsubscribe, and it does so, but also sends an email saying you've been unsubscribed in case it was an accident.

Edit: You wouldn't even need to ensure a unique string, since you'd pass in the email address too.

Jon 2010-02-01 19:28:09

I'd prefer to not include the email address in the URL - in effect, the random string would be a proxy for the email address.The unsub link would be included in each email sent.

chris 2010-02-01 19:32:40

In that case, you'd just need to make sure your string was unique. It also creates another problem -- how long do you ensure uniqueness? Let's say I subscribe and click the link. The next day, someone else gets the same random string (unlikely but possible) but doesn't click the link. I forget, and I click it again. Poof, they're subscribed.

Jon 2010-02-01 19:44:33

Or worse, if you're using the same idea for unsub. There's still a link out there (maybe deep in my mailbox) that might now unsubscribe someone else. Or, in a hypothetical worst case scenario, you just have a script hitting your unsubscribe confirmation page with every combination. (Okay, fine, statistically, they wouldn't get very far. My point is that two tokens that only make sense together is usually a better idea than one token.)

Jon 2010-02-01 19:47:11

A simple unique constraint on the db field prevents that from happening. You'd only update the unique ID if the email address changed.

chris 2010-02-01 19:57:58

So the GUID is just basically a hashed form of the email?

Jon 2010-02-01 20:03:50

Jon, the whole point of a GUID is that it is guaranteed to be unique - that is it's entire purpose! See http://stackoverflow.com/questions/39771/is-a-guid-unique-100-of-the-time

Dan Diplo 2010-02-01 22:28:39

Sorry, I wasn't specific with my terms - I started using GUID because it appeared elsewhere here. What I meant was just a unique string. My point was that if you're going to send out that unique string and it takes an action automatically, especially in the case where someone can just click on it to perform that action, you want to be relatively certain it won't be reused inappropriately. If you're maintaining the ID over the lifetime of a user with the database constraining its lifetime uniqueness, you should be fine. I was clarifying because chris said it would change when the email changed.

Jon 2010-02-02 17:11:32

The guid/hash value is a proxy for the email address, and is stored in the database.

chris 2010-02-03 17:37:08

Fair enough -- the only point I was making is that the longer you maintain a static hash per user, the more likely it is that someone can randomly execute things on their behalf. But for this purpose, it's probably overthinking it.

Jon 2010-02-03 18:18:03

I've used a random GUID before such purposes to verify email accounts, and it works well. Unless you are dealing with ultra-secure, ultra-sensitive data then it should suffice. I see no reason not to use the same GUID for unsubscribe requests - that way you just need to store one GUID per account that can be a lookup to your subscribers database (or however you store them). You could add the unsubscribe link to the bottom of all emails, making it a simple one-click option.

Dan Diplo 2010-02-01 19:33:36

ansaurus

tags:

views:

answers:

How should email address opt-in implemented?

related questions