Just to be clear, I think steps 1 and 2 there are exhausted by something along the lines of the draft PR I’ve put up here:
I hope that’s not too radical for anyone
To quote the Action Points at the very end of the essay you linked:
At the least I’d like us to remove the highly recommended line about custom user models. Even if you think I’m mad, you must see that having that there is harmful for beginners.
At the same time we should tone down the warning about migrating to a custom user model mid-project. I’ve argued there’s no reason to do it, but even so, it’s not that hard. We can say it’s involved, without giving people heart attacks.
I’d hope we could get that far at least.
My plan is to recruit @wsvincent to lead author the Profile How To at DjangoCon this year
(Gotta do a little bike-shedding here)
I’d love to see you drop the word “somewhat” in the second change.
I agree that in many cases, changing the user model isn’t horrible - but there are also a number of cases where it becomes a nightmare. (Usually when things weren’t done “right” at the start, but then we don’t always do things perfect at the beginning.)
I’d love to see some type of wording (without it becoming too long) that expresses the idea that it might be a simple operation, or it could end up being extremely complex.
These all seem like reasonable steps to be made. 3 and 4 can be done separately and don’t need to be part of a larger User re-imagining either.
Regarding 4, I’m not sure of the process of how to add those more advanced guides to the docs. I’d like to see it done. I suspect the first step is write a blog post that shows it, get feedback, then attempt a upstream merge of it?
I was finally able to complete the reading of Carlton’s post, and I can’t agree more with what he suggests/proposes.
With my non-Fellow hat on, let me share that I have always been critical of the “custom user model option” and, in all honesty, never fully grasped it (or used it). I always preferred to use 1-1 profiles to do what I needed, and I see the User model as a mere placeholder for the “entity that represents an authenticated being”. This means I heavily rely on User for everything authentication-related, but any metadata or logic beyond that is in a new model with a 1-1 to User.
What I don’t see mentioned in the article (and I think I understand why – the article is about the User model and improvements for it, not a whole redesign) is how to support, nicely, decoupled authentication (“Is this user who they say they are?”) and authorization (“Can this user perform action X?”) flows. This is something I would eventually love to see improved in Django.
In summary, I’m +1 to the immediate changes, including:
Proposed docs changes (will do that PR review soonish)
Pushing for a Profile How-To
A medium-term initiative would be evaluating and including in core django-unique-user-email, which I haven’t inspected yet.
In the medium to long term, I’m +1 on working on a plan where custom User models get deprecated-ish or documented as a last resort.
Following the discussion, various posts online, and the numerous hearts and +1s, here and on the PR, I’ve opened two Django tickets to push forward the small docs changes, and the Profile How-To.
I think it’s worth pointing out the 2012 Wiki on this topic and the fact that Option #5, which @jacobian liked at the time, was in line with this: ContribAuthImprovements – Django
I agree with basically everything Carlton wrote and especially having a plug-and-play way of switching auth methods from username to email to [your-solution] would be amazing.
What I really want to see is good support for using different types of identifiers for logging in. I will go with the email example because it’s what I personally use almost always.
Without needing a second model or a custom user, how would I do the following:
Have the login identifier be an email field, with correct length and validation?
Ideally enforce in this in the database via constraints, e.g. that the email is case-insensitively unique?
Related to the above, ensure I can query on it quickly?
I’m also interested in how we’d add extra (but very auth related) bells and whistles, for example:, storing that the email has been verified, but separate from is_active.
And finally if this would include a plan to remove (optionally? over an extended deprecation?) the non-auth related fields, especially first/last name.
Most of these things are addressed in your post. But I would be against, for example, having both a username and email but only using one of them. I would like to see some easy to use options where you can choose which you want to live in the database (which should include either or both). Which leaves me wondering how to do this. With extra models and User is close to empty? Could work.
But I do agree with all of the immediate action points, which is what this post is about anyway
Sorry, a bit rambly, could have been more concise.
Yes, they are , but let me just say what I think, to be clear.
Ultimately I would strip User down to (more or less) just an ID field to be the target of foreign keys from other models. Authentication credentials (be it log in by username, email, or anything else) should live in separate models, so you can add whichever you need, with Django providing the base interface, and then the core implementations that are most common.
We’re a long way from there, so it’s a question of slowly slowly. Current status is proof-of-concepts showing that we can evolve auth.User. It’s been a long-time held that we just simply couldn’t, and I think that’s where we gave up too early. (An in the meantime strategy I’m quite keen on is just ignoring offending fields, and assuming we already got there, of course.)
, but let me just say what I think, to be clear.