Changes between Version 5 and Version 6 of ContribEmailAuth

Timestamp:

Sep 19, 2013, 12:15:00 PM (11 years ago)

Author:

anonymous

Comment:

--

ContribEmailAuth

@@ -37 +37 @@
 == Option 2: The authtools approach ==
 
-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.
+Make auth code more generic, eliminating the need for a separate app.  Optionally, provide an EmailUser for email as username.
+
+* Refactor the views and forms provided by django.contrib.auth to be generic.
+* Use swappable to provide a model in django.contrib.auth which uses email as username. (optional)
+
+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.
+
+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.
+
+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.
+
+=== Relevant Tickets ===
+
+ * Ticket for refactoring django.contrib.auth.views to use class-based views - [ticket:17209]
+ * Ticket for refactoring django.contrib.auth.forms.UserCreationForm to work with custom user models. - [ticket:19353]
+
+Much of the code for the refactoring work has already been written, but for some reason the tickets stagnated and never fully made it into master.
 
 === Advantages ===
 
- * Allows for other, potentially more sweeping alterations if desired (e.g. authtools combines first_name and last_name).
+ * using EmailUser only requires pointing AUTH_USER_MODEL at 'auth.EmailUser'
+ * built in auth code for forms and views becomes more generic and extensible.
+ * auth code lives in a single code base, rather than two contrib apps.
+ * no extra contrib application or confusion surrounding whether you should use views/forms form auth or auth_email.
 
 === Disadvantages ===
 
-  * More code duplication
-  * Doesn't really follow principle of least surprise. Ideally, the email-based User should behave exactly like the stock User, with this one exception.
+ * 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).
 
 == Final decision ==