Re: Custom user models don't like non integer primary keys.

[Tim Graham]

Ticket #14881  addresses the 
issue that django.contrib.auth assumes User.pk is an integer and thus 
password reset doesn't work. I've updated the original patch and added 
documentation and a backwards compatibility proposal. Reviews and feedback 
appreciated!

On Friday, November 9, 2012 5:42:06 PM UTC-5, Eric Hutchinson wrote:
>
> Sorry for disappearing there.
>
> I didn't think a full trace was necessary, russ nailed that particular 
> instance. As a user of django, I don't think for 1.5 that you need to 
> change the behavior of views. It just blind sided me that the custom auth 
> model needed an integer ID and it should be added to the docs before 
> release. 
>
> It'd be super nice if it worked with other field types, but I don't see it 
> being a big deal if it's documented as being that way.
>
> On Tuesday, November 6, 2012 6:07:14 PM UTC-5, Russell Keith-Magee wrote:
>>
>> Hi Eric,
>>
>> Although the full stack trace would confirm it, I think I can guess what 
>> the problem is here -- it's the mechanism for generating reset tokens. 
>>
>> If you dig into the token generation (and reversal) mechanisms, they use 
>> int_to_base36 and base36_to_int to convert the user's primary key into 
>> something that can be used as a reversible, text-based identifier of the 
>> user object that isn't the literal identifier itself. This identifier is 
>> then used as part of the password reset token (along with a timestamp 
>> component and a component based on the last login timestamp)
>>
>> A base36 encoding of an integer produces a nice reversible alphanumeric 
>> representation of the integer primary key that can be used in this reset 
>> token. 
>>
>> So, yes -- non-integer primary keys will have a problem with any of the 
>> password reset or account activation logic. These should (he says, 
>> hopefully) be the only views that are affected.
>>
>> One of the big features for Django 1.5 is the introduction of swappable 
>> user models. However, even with that change, we've maintained the 
>> requirement that the User model has an integer primary key
>>
>> That said, I'm not personally opposed to dropping this requirement -- we 
>> just need to find a way to abstract the PK-dependent tokenization part in a 
>> useful way. As an initial thought, this is something that we could abstract 
>> out to the token generator API; the token generator is already customisable 
>> in the password reset views. However, I'm certainly open to other 
>> approaches.
>>
>> Yours,
>> Russ Magee %-)
>>
>> On Wed, Nov 7, 2012 at 3:19 AM, Jacob Kaplan-Moss wrote:
>>
>>> Hey Eric --
>>>
>>> Can you post the full traceback instead of just the snippet? Without
>>> that it's not clear whether this is a bug or just a consequence of
>>> defining your own custom user model. As the documentation notes:
>>>
>>> """
>>>
>>> As you may expect, built-in Django's forms and views make certain
>>> assumptions about the user model that they are working with.
>>>
>>> If your user model doesn't follow the same assumptions, it may be
>>> necessary to define a replacement form, and pass that form in as part
>>> of the configuration of the auth views.
>>> """
>>>
>>> So it might be the case that you just need to be customizing more
>>> stuff to deal with your special model. Or not, but we probably need
>>> more info to decide either way.
>>>
>>> Jacob
>>> Jacob
>>>
>>>
>>> On Tue, Nov 6, 2012 at 12:43 PM, Eric Hutchinson
>>>  wrote:
>>> > I've been playing with custom user models. Something i've found is that
>>> > trying to use the django-extensions uuidfield as a primary key doesn't 
>>> seem
>>> > very usable at the moment.
>>> >
>>> > Many of the built in auth views, specifically password reset, assume an
>>> > integer field here.
>>> >
>>> > /lib/python2.7/site-packages/django/utils/http.py", line 187, in
>>> > int_to_base36
>>> > raise TypeError("Non-integer base36 conversion input.")
>>> > TypeError: Non-integer base36 conversion input.
>>> >
>>> >
>>> > Also, in the admin when creating a new user with the example admin 
>>> setup
>>> > from the docs, even though it would seem to have no reason to i get it
>>> > trying to redirect to /app/model/(integer)/ when the id is clearly a 
>>> uuid.
>>> >
>>> > I know this isn't that helpful, but I don't know if this is just 
>>> something
>>> > you might want to warn about in the docs, or if this is something you 
>>> want
>>> > to fix in the built-in auth views, or what.
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google 
>>> Groups
>>> > "Django developers" group.
>>> > To view this discussion on the web visit
>>> > https://groups.google.com/d/msg/django-developers/-/VHk_gOF8DmEJ.
>>> > To post to this group, send email to django-d...@googlegroups.com.
>>> > To unsubscribe from this group, send email to
>>> > django-develop...@googlegroups.com.
>>> > For more options, 

Re: Custom user models don't like non integer primary keys.

[Eric Hutchinson]

Sorry for disappearing there.

I didn't think a full trace was necessary, russ nailed that particular 
instance. As a user of django, I don't think for 1.5 that you need to 
change the behavior of views. It just blind sided me that the custom auth 
model needed an integer ID and it should be added to the docs before 
release. 

It'd be super nice if it worked with other field types, but I don't see it 
being a big deal if it's documented as being that way.

On Tuesday, November 6, 2012 6:07:14 PM UTC-5, Russell Keith-Magee wrote:
>
> Hi Eric,
>
> Although the full stack trace would confirm it, I think I can guess what 
> the problem is here -- it's the mechanism for generating reset tokens. 
>
> If you dig into the token generation (and reversal) mechanisms, they use 
> int_to_base36 and base36_to_int to convert the user's primary key into 
> something that can be used as a reversible, text-based identifier of the 
> user object that isn't the literal identifier itself. This identifier is 
> then used as part of the password reset token (along with a timestamp 
> component and a component based on the last login timestamp)
>
> A base36 encoding of an integer produces a nice reversible alphanumeric 
> representation of the integer primary key that can be used in this reset 
> token. 
>
> So, yes -- non-integer primary keys will have a problem with any of the 
> password reset or account activation logic. These should (he says, 
> hopefully) be the only views that are affected.
>
> One of the big features for Django 1.5 is the introduction of swappable 
> user models. However, even with that change, we've maintained the 
> requirement that the User model has an integer primary key
>
> That said, I'm not personally opposed to dropping this requirement -- we 
> just need to find a way to abstract the PK-dependent tokenization part in a 
> useful way. As an initial thought, this is something that we could abstract 
> out to the token generator API; the token generator is already customisable 
> in the password reset views. However, I'm certainly open to other 
> approaches.
>
> Yours,
> Russ Magee %-)
>
> On Wed, Nov 7, 2012 at 3:19 AM, Jacob Kaplan-Moss 
>  > wrote:
>
>> Hey Eric --
>>
>> Can you post the full traceback instead of just the snippet? Without
>> that it's not clear whether this is a bug or just a consequence of
>> defining your own custom user model. As the documentation notes:
>>
>> """
>>
>> As you may expect, built-in Django's forms and views make certain
>> assumptions about the user model that they are working with.
>>
>> If your user model doesn't follow the same assumptions, it may be
>> necessary to define a replacement form, and pass that form in as part
>> of the configuration of the auth views.
>> """
>>
>> So it might be the case that you just need to be customizing more
>> stuff to deal with your special model. Or not, but we probably need
>> more info to decide either way.
>>
>> Jacob
>> Jacob
>>
>>
>> On Tue, Nov 6, 2012 at 12:43 PM, Eric Hutchinson
>>  wrote:
>> > I've been playing with custom user models. Something i've found is that
>> > trying to use the django-extensions uuidfield as a primary key doesn't 
>> seem
>> > very usable at the moment.
>> >
>> > Many of the built in auth views, specifically password reset, assume an
>> > integer field here.
>> >
>> > /lib/python2.7/site-packages/django/utils/http.py", line 187, in
>> > int_to_base36
>> > raise TypeError("Non-integer base36 conversion input.")
>> > TypeError: Non-integer base36 conversion input.
>> >
>> >
>> > Also, in the admin when creating a new user with the example admin setup
>> > from the docs, even though it would seem to have no reason to i get it
>> > trying to redirect to /app/model/(integer)/ when the id is clearly a 
>> uuid.
>> >
>> > I know this isn't that helpful, but I don't know if this is just 
>> something
>> > you might want to warn about in the docs, or if this is something you 
>> want
>> > to fix in the built-in auth views, or what.
>> >
>> > --
>> > You received this message because you are subscribed to the Google 
>> Groups
>> > "Django developers" group.
>> > To view this discussion on the web visit
>> > https://groups.google.com/d/msg/django-developers/-/VHk_gOF8DmEJ.
>> > To post to this group, send email to 
>> > django-d...@googlegroups.com
>> .
>> > To unsubscribe from this group, send email to
>> > django-develop...@googlegroups.com .
>> > For more options, visit this group at
>> > http://groups.google.com/group/django-developers?hl=en.
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To post to this group, send email to 
>> django-d...@googlegroups.com
>> .
>> To unsubscribe from this group, send email to 
>> django-develop...@googlegroups.com .
>> For more options, visit this group at 
>> http://groups.google.com/group/django-developers?hl=en.
>>
>>
>

-- 
You 

Re: Custom user models don't like non integer primary keys.

[Bruno Renié]

On Wed, Nov 7, 2012 at 12:06 AM, Russell Keith-Magee
 wrote:
> Hi Eric,
>
> Although the full stack trace would confirm it, I think I can guess what the
> problem is here -- it's the mechanism for generating reset tokens.
>
> If you dig into the token generation (and reversal) mechanisms, they use
> int_to_base36 and base36_to_int to convert the user's primary key into
> something that can be used as a reversible, text-based identifier of the
> user object that isn't the literal identifier itself. This identifier is
> then used as part of the password reset token (along with a timestamp
> component and a component based on the last login timestamp)
>
> A base36 encoding of an integer produces a nice reversible alphanumeric
> representation of the integer primary key that can be used in this reset
> token.
>
> So, yes -- non-integer primary keys will have a problem with any of the
> password reset or account activation logic. These should (he says,
> hopefully) be the only views that are affected.
>
> One of the big features for Django 1.5 is the introduction of swappable user
> models. However, even with that change, we've maintained the requirement
> that the User model has an integer primary key
>
> That said, I'm not personally opposed to dropping this requirement -- we
> just need to find a way to abstract the PK-dependent tokenization part in a
> useful way. As an initial thought, this is something that we could abstract
> out to the token generator API; the token generator is already customisable
> in the password reset views. However, I'm certainly open to other
> approaches.

The token generator API looks very similar to the cryptographic
signing API. The password reset views can be updated to use signing
instead. In fact I rewrote the password reset views using class-based
views and signing [0] and they ended up working very well even when
using an external authentication system instead of contrib.auth. I
also got rid of the base36 conversion in the process but this could be
added back with customization hooks.

It seems the auth views could benefit from such a conversion.

[0] http://pypi.python.org/pypi/django-password-reset

Bruno

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Custom user models don't like non integer primary keys.

[Russell Keith-Magee]

Hi Eric,

Although the full stack trace would confirm it, I think I can guess what
the problem is here -- it's the mechanism for generating reset tokens.

If you dig into the token generation (and reversal) mechanisms, they use
int_to_base36 and base36_to_int to convert the user's primary key into
something that can be used as a reversible, text-based identifier of the
user object that isn't the literal identifier itself. This identifier is
then used as part of the password reset token (along with a timestamp
component and a component based on the last login timestamp)

A base36 encoding of an integer produces a nice reversible alphanumeric
representation of the integer primary key that can be used in this reset
token.

So, yes -- non-integer primary keys will have a problem with any of the
password reset or account activation logic. These should (he says,
hopefully) be the only views that are affected.

One of the big features for Django 1.5 is the introduction of swappable
user models. However, even with that change, we've maintained the
requirement that the User model has an integer primary key

That said, I'm not personally opposed to dropping this requirement -- we
just need to find a way to abstract the PK-dependent tokenization part in a
useful way. As an initial thought, this is something that we could abstract
out to the token generator API; the token generator is already customisable
in the password reset views. However, I'm certainly open to other
approaches.

Yours,
Russ Magee %-)

On Wed, Nov 7, 2012 at 3:19 AM, Jacob Kaplan-Moss wrote:

> Hey Eric --
>
> Can you post the full traceback instead of just the snippet? Without
> that it's not clear whether this is a bug or just a consequence of
> defining your own custom user model. As the documentation notes:
>
> """
>
> As you may expect, built-in Django's forms and views make certain
> assumptions about the user model that they are working with.
>
> If your user model doesn't follow the same assumptions, it may be
> necessary to define a replacement form, and pass that form in as part
> of the configuration of the auth views.
> """
>
> So it might be the case that you just need to be customizing more
> stuff to deal with your special model. Or not, but we probably need
> more info to decide either way.
>
> Jacob
> Jacob
>
>
> On Tue, Nov 6, 2012 at 12:43 PM, Eric Hutchinson
>  wrote:
> > I've been playing with custom user models. Something i've found is that
> > trying to use the django-extensions uuidfield as a primary key doesn't
> seem
> > very usable at the moment.
> >
> > Many of the built in auth views, specifically password reset, assume an
> > integer field here.
> >
> > /lib/python2.7/site-packages/django/utils/http.py", line 187, in
> > int_to_base36
> > raise TypeError("Non-integer base36 conversion input.")
> > TypeError: Non-integer base36 conversion input.
> >
> >
> > Also, in the admin when creating a new user with the example admin setup
> > from the docs, even though it would seem to have no reason to i get it
> > trying to redirect to /app/model/(integer)/ when the id is clearly a
> uuid.
> >
> > I know this isn't that helpful, but I don't know if this is just
> something
> > you might want to warn about in the docs, or if this is something you
> want
> > to fix in the built-in auth views, or what.
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django developers" group.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msg/django-developers/-/VHk_gOF8DmEJ.
> > To post to this group, send email to django-developers@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/django-developers?hl=en.
>
> --
> 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
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Custom user models don't like non integer primary keys.

[Jacob Kaplan-Moss]

Hey Eric --

Can you post the full traceback instead of just the snippet? Without
that it's not clear whether this is a bug or just a consequence of
defining your own custom user model. As the documentation notes:

"""

As you may expect, built-in Django's forms and views make certain
assumptions about the user model that they are working with.

If your user model doesn't follow the same assumptions, it may be
necessary to define a replacement form, and pass that form in as part
of the configuration of the auth views.
"""

So it might be the case that you just need to be customizing more
stuff to deal with your special model. Or not, but we probably need
more info to decide either way.

Jacob
Jacob


On Tue, Nov 6, 2012 at 12:43 PM, Eric Hutchinson
 wrote:
> I've been playing with custom user models. Something i've found is that
> trying to use the django-extensions uuidfield as a primary key doesn't seem
> very usable at the moment.
>
> Many of the built in auth views, specifically password reset, assume an
> integer field here.
>
> /lib/python2.7/site-packages/django/utils/http.py", line 187, in
> int_to_base36
> raise TypeError("Non-integer base36 conversion input.")
> TypeError: Non-integer base36 conversion input.
>
>
> Also, in the admin when creating a new user with the example admin setup
> from the docs, even though it would seem to have no reason to i get it
> trying to redirect to /app/model/(integer)/ when the id is clearly a uuid.
>
> I know this isn't that helpful, but I don't know if this is just something
> you might want to warn about in the docs, or if this is something you want
> to fix in the built-in auth views, or what.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/VHk_gOF8DmEJ.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Custom user models don't like non integer primary keys.

[Eric Hutchinson]

I've been playing with custom user models. Something i've found is that 
trying to use the django-extensions uuidfield as a primary key doesn't seem 
very usable at the moment.

Many of the built in auth views, specifically password reset, assume an 
integer field here. 

/lib/python2.7/site-packages/django/utils/http.py", line 187, in 
int_to_base36
raise TypeError("Non-integer base36 conversion input.")
TypeError: Non-integer base36 conversion input.


Also, in the admin when creating a new user with the example admin setup 
from the docs, even though it would seem to have no reason to i get it 
trying to redirect to /app/model/(integer)/ when the id is clearly a uuid.

I know this isn't that helpful, but I don't know if this is just something 
you might want to warn about in the docs, or if this is something you want 
to fix in the built-in auth views, or what.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/VHk_gOF8DmEJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.