#10265: _make_token_with_timestamp inconsistent based on User.last_login
-----------------------------------+----------------------------------------
          Reporter:  felix         |         Owner:  nobody          
            Status:  new           |     Milestone:                  
         Component:  Contrib apps  |       Version:  1.0             
        Resolution:                |      Keywords:  auth token login
             Stage:  Unreviewed    |     Has_patch:  1               
        Needs_docs:  0             |   Needs_tests:  0               
Needs_better_patch:  0             |  
-----------------------------------+----------------------------------------
Changes (by Alex):

  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0

Old description:

> 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","[email protected]","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

New description:

 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","[email protected]","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

Comment:

 Please use the preview button :)

-- 
Ticket URL: <http://code.djangoproject.com/ticket/10265#comment:1>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django updates" 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-updates?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to