On Jun 28, 1:39 am, "Scott Moonen" <[EMAIL PROTECTED]> wrote: > I don't think it's necessary to implement this in such a way that additional > server state is stored. Instead, you could let the confirmation token be a > hash of the internal user state -- including, most importantly, the user > password's salt and encrypted values. That way, the valid confirmation > token is 1) known only to the server (the User 'password' field is not > externalized), 2) able to be computed at any time without being stashed > anywhere, 3) constant until the user changes their password, and 4) > guaranteed to change whenever the password is actually changed.
That's absolutely ingenious - that approach gets my vote. I think I'll switch DjangoPeople over to that. Cheers, Simon --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
