Legend:

This option is similar to https://django-authtools.readthedocs.org/en/latest/. The idea would be to create a separate app that houses admin, views, etc., that are analogous to the ones that support User in django.contrib.auth.

39

Make auth code more generic, eliminating the need for a separate app. Optionally, provide an EmailUser for email as username.

40

41

* Refactor the views and forms provided by django.contrib.auth to be generic.

42

* Use swappable to provide a model in django.contrib.auth which uses email as username. (optional)

43

44

django-authtools could roughly be viewed as a patch. authtools was written to provide flexibility that the built in auth code didn't provide. Once the built-in auth code has this flexibility, authtools can go away. Refactoring forms and views in auth to be generic towards username in the same manner as authtools will allow auth to work with a broader range of custom user models. In this case, specifically, with a user model which uses email as username.

45

46

In regards to including a user model in django which uses email as username. Swappable already works with two concrete models with the same swappable value. Adding an EmailUser to django.contrib.auth.models that is also swappable on AUTH_USER_MODEL works as desired. The only model that is installed is the one referenced by settings.AUTH_USER_MODEL. All other models swappable on AUTH_USER_MODEL are ignored and not installed. authtools is actually already doing this. If you look at authtools.models.User [https://github.com/fusionbox/django-authtools/blob/master/authtools/models.py#L86], this model is swappable on AUTH_USER_MODEL but will not be installed unless settings.AUTH_USER_MODEL points to it.

47

48

Putting EmailUser in auth.models should be considered independent of the views/forms refactor. This refactor will make it much easier for 3rd party apps to provide their own custom user models, and remove the necessary code duplication found in authtools.

* using EmailUser only requires pointing AUTH_USER_MODEL at 'auth.EmailUser'

60

* built in auth code for forms and views becomes more generic and extensible.

61

* auth code lives in a single code base, rather than two contrib apps.

62

* no extra contrib application or confusion surrounding whether you should use views/forms form auth or auth_email.

44

63

45

64

=== Disadvantages ===

46

65

47

* More code duplication

48

* Doesn't really follow principle of least surprise. Ideally, the email-based User should behave exactly like the stock User, with this one exception.

66

* Now we have EmailUser included in auth. What about FacebookUser, or PhoneNumberUser. (note that this is in reference to adding EmailUser, not to refactoring auth.forms and auth.views to be more generic).