Opened 16 years ago
Last modified 13 years ago
#10265 closed
_make_token_with_timestamp inconsistent based on User.last_login — at Version 1
Reported by: | felix | Owned by: | nobody |
---|---|---|---|
Component: | Contrib apps | Version: | 1.0 |
Severity: | Keywords: | auth token login | |
Cc: | crucialfelix@… | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
default token generator makes inconsistent tokens depending on if the user has been loaded from the db or has just been created during this response
the difference is that a User just created has a last_login with microseconds set, but when reloaded from the db it does not and the token generator uses unicode(user.last_login) in the hash
>>> from django.contrib.auth.models import User >>> u1 = User.objects.create_user("username","user@email.com","password") >>> u1.last_login datetime.datetime(2009, 2, 14, 16, 5, 3, 638275) >>> unicode(u1.last_login) u'2009-02-14 16:05:03.638275' >>> u2 = User.objects.all()[0] >>> u2 <User: crucial> >>> u2.last_login datetime.datetime(2009, 2, 14, 15, 47, 20) >>> unicode(u2.last_login) u'2009-02-14 15:47:20'
(as an aside, I don't think that a user should be created with a last login of now.
a new user has never logged in.)
# user just made, generate token:
making token 3 2009-02-14 16:24:33.632380 2966
2ae-c3c68b86d5148e768353
# user comes to site, token fails equality test in check_token
making token 3 2009-02-14 16:24:33 2966
2ae-e8d746b5603f6fae0fd5
the fix is to explicitly format user.last_login without microsecond
this fix should not break any currently generated tokens out there in email land
Change History (2)
by , 16 years ago
Attachment: | token.patch added |
---|
comment:1 by , 16 years ago
Description: | modified (diff) |
---|
Please use the preview button :)