8 ms·
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
by zeemonkee2 14y ago
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.
- legutierr 14y agoYou 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.
- zeemonkee2 14y agoWhat 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.
- legutierr 14y agoYou 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.