On Tuesday 15 December 2009 23:10:23 Matt Schinckel wrote: > I came across one today: > contrib.auth.tokens.PasswordResetTokenGenerator > has a method _make_token_with_timestamp, which uses last_login to > create the > token. This means that if someone generates a password reset > request, the token > will be invalidated if that user then logs in. This could occur if > a person creates > password reset requests for a user that is not themself.
That behaviour would occur whether or not last_login allowed nulls, and it is deliberate - the token is intended to be "use once", so logging in or setting the password changes the value of the token. However, the bigger issue is that I think changing the definition of this field really requires a migration mechanism (which would update existing databases), which we don't have. We really don't want the situation of bugs which are impossible to reproduce because they depend on installation and upgrade order. Luke -- "I imagine bugs and girls have a dim suspicion that nature played a cruel trick on them, but they lack the intelligence to really comprehend the magnitude of it." (Calvin and Hobbes) Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. 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.
