|Version 2 (modified by tanderegg, 2 years ago) (diff)|
Adding an Email-based authentication model
ContribAuthImprovements described and implemented a set of changes to allow for pluggable User models in contrib.auth. One of the primary motivators behind this change was to make it easy to implement email-based authentication. To make this even easier, #20824 describes an enhancement for Django to ship with a ready-to-use Email-based login model.
Some django-developer discussions that cover this topic:
A number of solutions have been proposed. Here is a summary of the most viable candidates:
Option 1: Simple auth.User analog
Feature branch: https://github.com/tanderegg/django/tree/ticket_20824_master
This option is a simple analog to the auth.User model. In auth_email.models, there is an AbstractUser class that inherits from AbstractBaseUser and PermissionsMixin, and contains the fields email, first_name, last_name, is_active, and is_staff, basically identical to auth.User with the exception of having no username. the auth_email.models.User class then extends the AbstractUser class to make it instantiable and swappable. A custom UserManager class adds in methods for creating users and superusers.
The auth_email.admin.UserAdmin class inherits from auth.admin.UserAdmin and overides the appropriate members and methods, including pointing the class to the custom UserCreationForm and UserChangeForm in auth_email.forms. These forms are again nearly identical to the ones in auth.forms.
The approach I took is very similar to the one used in https://github.com/Liberationtech/django-libtech-emailuser. The primary difference is that django-libtech-emailuser does not contain a new abstract class, and instead contains a single concrete class EmailUser.
- Simple implementation, a developer must only include auth_email in INSTALLED_APPS and set AUTH_USER_MODEL = 'auth_email.User'.
- Principle of least surprise: auth_email.User should behave exactly as auth.User would, with the exception of no username.
- A small amount of new code means fewer opportunities to introduce new bugs.
- Makes few assumptions about how an email user should behave, which leaves further implementation up to each use case
- django.contrib.auth could potentially be modified a bit to reduce code duplication, specifically with regards to admin.UserAdmin. If there is interest in this I will modify my branch.
To be determined.