Agree on Django auth; it's horribly designed - need an extra field - use a separate UserProfile - really? Need to login with unique email address - which EVERY SINGLE client asks for - you're going to go down a rabbit hole. A group/permissions system almost nobody uses outside the admin.
Django auth was designed around the typical use case ca. 2005. The world's moved on a bit since then.
What I end up doing nowadays is roll my own (and re-use bits of contrib.auth where appropriate, such as password hashing) using a custom auth backend and keep a separate site for the Django admin which uses contrib.auth models. As long as I don't have to use 3rd party apps that rely on auth.User I'm fine.
You can also subclass auth.User, which allows you to maintain compatibility with 3rd party apps.
This is how I've gotten around the user name length limitation. I have a longer field in the subclass, and implement a backend to check that. But because it's a subclass, foreign-key relations still work.
What if you want to get rid of the username field altogether?
For example, my typical use case: unique email address for logins, no usernames:
I suppose you could subclass User with a longer username, and sync the username with the email address using a signal, for example.
Still, it's a chunk of workaround I end up doing one way or another with each new project. Hopefully soon (based on discussions on django-developers group) we'll see some kind of pluggable User model.
Django auth was designed around the typical use case ca. 2005. The world's moved on a bit since then.
What I end up doing nowadays is roll my own (and re-use bits of contrib.auth where appropriate, such as password hashing) using a custom auth backend and keep a separate site for the Django admin which uses contrib.auth models. As long as I don't have to use 3rd party apps that rely on auth.User I'm fine.