Deprecate the current User model for authentication and authorization

[nanuxbe]

Code of Conduct

• I agree to follow Django's Code of Conduct

Feature Description

• Introduce a simpler User that does not have groups or permissions (as in permission model)
• keep the abstract User model without username or email
• start new projects with either a subclass of that base model that has basic role (user and admin could be it)
• keep the Permission classes
• enable the current user model as an option
• provide an entrypoint (and simple implementation) for 2FA

Problem

For a lot of cases, the current user model is not adequate, being either too complex (project requires only "user" and "admin" roles) or too simple (no notion of record-level ownership or hierarchy). It is also missing a unified 2FA mechanism

Request or proposal

proposal

Additional Details

No response

Implementation Suggestions

No response

[github-actions]

Thank you nanuxbe for sharing your idea! We have a lot of them so please be patient. You can see the current queue here. If you'd like to learn about other ways to get this idea more attention, please see this page.

Community instructions

For commenters, please use the emoji reactions on the issue to express support, and/or concern easily. Please use the comments to ask questions or contribute knowledge about the idea. It is unhelpful to post comments of "I'd love this" or "What's the state of this?"

Reaction Guide

• 👍 This is something I would use
• 👎 This is something that would cause problems for me or Django
• 😕 I’m indifferent to this
• 🎉 This is an easy win

[apollo13]

Imo this is many features/ideas in one issue. For instance 2fa would be any ideal candidate independent of whether the user model gets reworked.

While I agree that the user model could do with a rework I don't really agree with "it is to complex". I know that this doesn't cover all examples, but if you solely need user/admin set is_superuser for admins and ignore the groups/permissions. This still allows you to level-up your game once you figure out that user/admin wasn't actually enough. I rather have a user model where non-required functionality is not used (to some extend at least) than having to switch a user model mid-project because it is to simple.

What I'd love to see on a user model if we change it:

• a display_name field/property/whatever so we know how to address the user (and get rid of the "broken" first/last names).
• a unique_identifier that can be used for login purposes amongst other things (essentially replacement for username & email)

[sergei-maertens]

IMO making the user model part of the start project template is the interesting part here - changing the user model after it has been set up is quite painful. Are there any statistics or anecdotal evidence about beginners missing the recommendation in the docs to use a custom user model?

[yardensachs]

I would also suggest that password is optional, and allow for an entrypoint (and simple implementation) for email-only logins (magic link one-time code)

[nanorepublica]

Are there any statistics or anecdotal evidence about beginners missing the recommendation in the docs to use a custom user model?

This happens all the time when beginners come to the Discord asking for help.

Generally I agree with apollo13 though in that there is a lot wrapped into this thread and we could do with splitting it out or becoming a bit more focused on what the goal is for this feature.

[apollo13]

IMO making the user model part of the start project template is the interesting part here - changing the user model after it has been set up is quite painful.

Which is also one of the reasons why a new user model should imo strive to cover as many usecases as possible while still staying simple so not many people need to switch the user model. Personally I am not really a fan of swappable models.

[tim-schilling]

I'm generally fine with this, but the 2FA mention feels shoehorned in. I'd like to see that split off because it feels like we should consider 2fa even without a new user model.

[carltongibson]

I love the one vote for "Easy win" on this 🫠

Bundle tickets seems the norm form auth suggestions. #12 includes a 2FA suggestion too. (FWIW there's a long accepted ticket for 2fa — the issue is how — I commented some thoughts on #12 — but Details!)

So there's DEP to improve the start project template (and allow multiple templates, etc) — if we can advance that then it opens the doorway to a new template with a different user model already in place.

In the meantime, folks could very easily create such a template anyway, and demonstrate ideas for a better user model.

I'm also noodling on my Bolt-on migrations to the existing user model approach, which is a bit Doc Brown but fine, it turns out. (Next bit there is Remove Profile Fields, when I get time to bundle that up.)

a new user model should imo strive to cover as many usecases as possible while still staying simple

My own take is that the user model should be ideally no more than an identity object, a target for FKs. Auth credentials sets are ideally on a separate model. Profile data is ideally on a separate model (or models if different areas of your app have different user-data needs). And so on.

...demonstrate ideas...

As ever, that's where I'd put my focus.

[LilyFirefly]

We're moving this forward. Next steps will be to write up a more detailed proposal in a DEP. We think #12, #17 and #22 are sufficiently related to look at together.