[Cosmo-dev] account activation link persistence

[Brian Moseley]

On 11/16/06, Jared Rhine <jared at wordzoo.com> wrote:

> One should assume that activations will "leak", and so some accounts will
> not be activated.

i assume that by "leak" you mean accounts that are signed up but never
activated?

> 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?

yea. my initial thought is a UnactivatedUserReaper class that simply
wraps a java.util.Timer that runs a daemon thread on a period
configured by the admin in cosmo.properties. the reaper would be
integrated into the app server lifecycle with a
ServletContextConfigurer.

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

agree.

> 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".

until the reaper nukes the unused activation from the database, which
seems totally reasonable to me.

> 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?

nah, cos then we'd have to keep the schema of that table and the user
table in sync.

> 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.

i think those are two different states. account activation happens one
time during the lifecycle of an account, and locking an account could
happen many times based on policies that may evolve over time.

> 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.

the framework we use for access control (acegi security) already has
gears for this, so we don't have to worry about effort or complexity
here.