[Cosmo-dev] account activation link persistence

[Jared Rhine]

Travis Vachon wrote:
> The way we want this to work (I believe) is that when a user signs up
> for an account, they should be sent an e-mail with a link something like
> "http://osaf.us/cosmo/account/activate?id=ag3de98435jsdf45". When a user
> goes to that page, we should look up the id hash and activate the
> account associated with it.

That sounds accurate.  If the Foxmarks people are still listening here, I'd
be curious to see if this matches how you implemented activation?

One should assume that activations will "leak", and so some accounts will
not be activated.  To me, this suggests that you must keep track of at least
a timestamp of the hash.  So the server property doesn't look attractive
there, at least without having multiple properties.

How will leaked activations be cleaned up?  It could be done with a cronjob
and straight SQL, but perhaps you want something built-in and scheduled via
Cosmo?

It should be an admin option whether to require email activation or not.

Sounds like once a user creates an account, no one else can create an
account with that name (ie, signup reserves an account until activated, as
opposed to first-to-confirm wins).  That seems fine to me, although if an
activation email is lost or never activated, someone couldn't "try again".

Perhaps as a result, an "activation record" holds all the information needed
to create an account, and the account is only created when the activation is
received?

I like the idea of an "activation" status for users, as it supports
infrastructure for the "disable access for this user" enhancement that has
been filed.  On the other hand, if you defer the actual account creation
until activation has occurred, then you don't have to implement any "deny
access if not activated yet" logic.

> In either case, I'd also like to keep track of a seed number for the
> activation id that is incremented each time a user signs up to avoid
> activation id collisions. Is there any reason not to use a
> ServerProperty for this?

Could you explain more?  Is this a literal seed to a random id generation
algorithm?  Seems like a purely-random id of the proposed size would be
sufficient to avoid collisions.  Sounds like I'm not understanding your
logic here.

Thanks!

-- Jared