> Django 1.5 introduces support for a configurable User model. The basic Django User model is still around, of course, but now there's first-class support for specifying your own model and having Django's auth system make use of it.
I guess having it be a special User model is just part of the deal with Django's good out-of-the-box admin. I don't even remember how the various Rails plugins (ActiveAdmin, for example) generates the scaffolding needed for an authenticated user.
It's very easy to extend the existing user model rather than creating one from scratch. I had to do some unconventional auth stuff recently and I only extended auth.User slightly (and also wrote a slightly modified authentication backend).
This feature was something we'd hoped would be awesome; it's not. Going over the documentation shows there's some jaw-dropping nastiness you have to go through to make it work.
It's good that they're providing it, but I think the complexity is going to turn people off (I know I won't be using it unless it's simplified at some point in the future). User profiles have always been used for adding data to User models indirectly, and I think this is probably going to remain the best way to handle it for most uses.
Can you expand on the "jaw-dropping nastiness you have to go through to make it work"? Seems pretty straightforward, though I have not tried to actually use it yet.
It appears the database migration is the biggest hurdle, but I don't think there's a way around that. User profiles require a join and that can be suboptimal, which is why this is a useful addition. If you weren't running into problems before it's probably better to not change (though that's usually the case for working code).
I suspect this may be the nastiness that's being referred to; this is the use case that I was hoping would be made dead simple.
With previous versions of Django I generated a random hash for use as a dummy/unguessable username, required an email address in the RegistrationForm, customized the AuthenticationForm, created a custom email authentication backend, and monkey patched User with various helper methods.
In 1.5 it looks like the AuthenticationForm will adapt to the field defined in USERNAME_FIELD[1], but a lot of work is still required. Support for easily using email address as the username (or support for easily specifying the username field in general without requiring all the other boilerplate) would probably go a long way.
> there's some jaw-dropping nastiness you have to go through to make it work.
What "jaw-dropping nastinesses" are those, and why didn't you check and report them during the beta/rc phase since you were "hoping it would be awesome"?
I've been using custom User models for over a month, and I can tell you that using a profile model is far nastier.
Besides avoiding a join in the DB (or worse, a separate select), being able to override user model methods has been an incredible benefit to my projects.
Yeah I've been using them for about a month too and all I can say is, this is how it should have always been.
The docs give you a pretty good starting point for a fully functional user model, and jarcoal (above) outlines a simple method for migrating from old to new.
The lack of a configurable User model is the reason I had to abandon django on a couple of projects. I like the framework, but formerly User was tied tightly up and down the framework (contrib.auth most notably).
Oh yes, it's easy. I was just forgetting exactly (I haven't used it in awhile) what it built out for you upon that command and what opinionated pattern it might constrain you to.
Not very opinionated at all, your application controller must expose a method to authenticate a user, and another to get the current user (defaults to :current_user which works out-of-the-box with Devise). Both method names can be configured in the initializer that is generated on install from this template: https://github.com/gregbell/active_admin/blob/master/lib/gen...
I haven't used ActiveAdmin in a few months, but when I last did I was really impressed.
I guess having it be a special User model is just part of the deal with Django's good out-of-the-box admin. I don't even remember how the various Rails plugins (ActiveAdmin, for example) generates the scaffolding needed for an authenticated user.