Closed Rubikium closed 2 years ago
I don't think this is the direction I was looking for. This is definitely an overkill.
You are following the Substituting a custom User model
section. It says that Some kinds of projects may have authentication requirements for which Django’s built-in [User](https://docs.djangoproject.com/en/4.1/ref/contrib/auth/#django.contrib.auth.models.User) model is not always appropriate.
which is not what we try to demo, and I don't foresee we have to demo custom authentication in the near future. Email / username + password login should be good enough for majority of projects. Even SSO login should be achievable with custom AUTHENTICATION_BACKENDS
(https://www.willianantunes.com/blog/2022/05/django-admin-authentication-using-sso-through-auth0/).
Please take a look at the Extending the existing User model
section instead. I suppose a one-to-one model is good enough.
Django recommended setting up a custom user model for new projects, even if the default User model is sufficient for the use cases. Also, if we only allow email and not username login, the email field should be a required field, which isn't the case for the default user model.
An alternate way for this would be to save the emails in the username
field inside the database and use a slightly modified default auth backend. This way is similar to how the mentioned SSO login method works (they use a hashed email as the username). Maybe we could consider this directions?
Btw, you can use interactive rebase to squash commits, so that the first two commits can be removed.
IMPORTANT: If there are existing applied migrations, the new migrations should be migrated using the
--fake-initial
option