Hello everyone,

I've started work on a long-overdue re-haul of the confirmation link system in Dada Mail

Currently, you'll notice that confirmation links have embedded in them the Mailing List the sub/unsub confirmation is for, the email address the confirmation is for, and then the mysterious, "pin" number, which is used to verify that the confirmation is real

There's a few shortcomings to this system The big one is that pin number: it's neither random, nor unique - nor does it ever expire You can basically dredge up an confirmation email from a year ago and try out the confirmation link - it may in fact work

The pin number itself is created using a not-so-intelligent, "algorithm" that uses two different and hopefully hard-to-guess strings, PLUS the email and list short name in calculating that number If someone can figure out the two hard-to-guess strings, the email and list are located in the confirmation link itself, and the pin number "algorithm" could be reverse-engineered Unless early-20-something me was WAY more clever than early-30-something me thinks he was

I doubt anyone's "cracked" the pin in Dada Mail - so don't read this the wrong way, but it's certainly a weakness in the app, so I'm intending the fix it I do think it's contributing to the problem that many are reporting, of specific addresses that seem to be unsubscribing and subscribing to a mailing list I still don't know what's executing these requests, but it doesn't help that these confirmation URLs are never-expiring

So, I've started work on this new system:

https://github
com/justingit/dada-mail/tree/features-confirmation_tokens

which replaces a "difficult"-to-calculate pin number that's embedded in the confirmation URL, with a really, really really long number (basically) that corresponds to a row in a database that holds the email address, mailing list and action that the confirmation link is going to be used for That means, no information about the actual confirmation is embedded in the mailing list, and there's no real way to, "crack" the new pin number (or "token", as I've been calling it), as there's nothing to crack - there's no real significance to the number - it's basically just a random number picked out of a hat

Since all the important stuff about the confirmation is in the table row itself, once we're done confirming whatever it is we need, we can remove the table row, as it's useless, and bang! - the confirmation link is now null-and-void: so clicking on it twice won't do anything A timestamp is also applied to the table structure, so we can say: after one day - remove the row We can even use that token to log things with - so not only can we log the date/time and ip address of a confirmation click, we can even log what confirmation URL gets clicked I'm trying to figure out if that's useful though…

In the future, this will also solve the problem of how to confirm other neat things, besides subscription/unsubscription confirmations, since I don't have to figure out a new scheme on how to whip up a entirely new confirmation link - all the important information is in the table row, and there's room to grow The confirmation link will just continue to have that token

So, here's what a confirmation link may look like:

http://example
com/cgi-bin/test_dada/mail
cgi/t/Kii3jdYoPKtXS9A3xyeYTE8FKP2ICmbxDHEmHyey/ 

And here's what the corresponding table row looks like:

mysql> select * from dada_confirmation_tokens; +----+---------------------+------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------+ | id | timestamp | token | data | +----+---------------------+------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------+ | 1 | 2013-02-11 14:57:02 | Kii3jdYoPKtXS9A3xyeYTE8FKP2ICmbxDHEmHyey | $D = {'email' => 'user@exampe','data' => {'flavor' => 'sub_confirm'},'list' => 'example'};;$D | +----+---------------------+------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------+

So, essentially it's just a real simple, but effective session system

So, my initial commits to this idea basically work: there's rough edges and I need to remove the old tests and write new ones AND THEN make a non-SQL version of all this, but that's the rest of today's work, I guess I'll try to push this out in some sort of beta form, soon, for those who would like to try,