Changes between Version 1 and Version 2 of ContribEmailAuth


Ignore:
Timestamp:
09/18/2013 08:13:34 AM (2 years ago)
Author:
tanderegg
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ContribEmailAuth

    v1 v2  
    1111A number of solutions have been proposed. Here is a summary of the most viable candidates:
    1212
    13 == Option 1: Something ==
     13== Option 1: Simple auth.User analog ==
    1414
    15 Build a thing.
     15Feature branch: https://github.com/tanderegg/django/tree/ticket_20824_master
     16
     17This 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.
     18
     19The 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.
     20
     21The 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.
    1622
    1723=== Advantages ===
    1824
    19  * Something
     25 * Simple implementation, a developer must only include auth_email in INSTALLED_APPS and set AUTH_USER_MODEL = 'auth_email.User'.
     26 * Principle of least surprise: auth_email.User should behave exactly as auth.User would, with the exception of no username.
     27 * A small amount of new code means fewer opportunities to introduce new bugs.
     28 * Makes few assumptions about how an email user should behave, which leaves further implementation up to each use case
    2029
    2130=== Problems ===
    2231
    23  * Something
     32 * 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.
    2433
    2534== Final decision ==
Back to Top