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 > <[email protected]<javascript:> > > 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 >> <[email protected] <javascript:>> 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 >> > [email protected]<javascript:> >> . >> > To unsubscribe from this group, send email to >> > [email protected] <javascript:>. >> > 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 >> [email protected]<javascript:> >> . >> To unsubscribe from this group, send email to >> [email protected] <javascript:>. >> 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 view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/r_8IWkCIlcgJ. 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.
