Django by default uses the
username field for authentication purposes of a user, but it's becoming a common trend to use
username field can be somewhat dropped. Also, the
username can be used, so it does not break any internal identification structure as well.
In the later sections, when I mentiond the (default)
User model please think of the default Django
User model (
So to make sure we're on the same page, our eventual goal is to get rid of the
username field and use
User model for authentication purposes.
Now, let's check out the usual ways to modify/extend the django
Create a Profile model: For example a
UserProfilemodel that has a one-to-one relationship with the
Usermodel. But this is to entend the functionalities of the
Usermodel e.g. to add a new field, not to modify it. So this option is of no use to us in this case.
AbstractUseris an abstract model that can be subclassed directly to create a concrete
Usermodel. In fact, the default
Usermodel subclasses this. But again if we create a model subclassing this, the model would allow us to extend the functionalities of the abstract class, not to allow for dropping the
usernamefield. There is a possibility of overriding the
usernameclass variable (the field declaration) with e.g.
Nonebut that could break some other functionalities as this would make
usernamea valid attribute of the model -- this could also lead to some hidden bugs down the line, so we want to omit it altogether. As a result, this option can't be taken into consideration as well.
django.contrib.auth.base_user.AbstractBaseUser): This is what we need (sorry, spoiler alert!). This is the superclass of
AbstractUserabstract model as well and defines only 2 fields and associated logics. The fields it define are:
last_login. So only a bare minimum and a perfect abstract superclass to extend and add only the fields we want.
So we'll be focusing on subclassing the
AbstractBaseUser model and modify it to meet our need.
The decision to take now is that which fields to include in our concrete user model as the
AbstractBaseUser defines only 2 fields mentioned fields. From here, we can go for a total
control over field definitions.
Before moving forward, if we were to extend the
User model, the easier option is to create
another profile model and put all the new fields and methods there. But this also has the penalty
of creating an extra database table which can be avoided by using the
AbstractUser model; as
Abstractuser is an abstract model, it does not result in a database table itself. So we would
get only one table created -- for the concrete subclass of it (which will contain all the
Now, as our plan is to drop the
username field and use
this point we can get some inspiration from the
AbstractUser model as it basically is what
User model comprised of (as it does not override much). Here's the source of
class User(AbstractUser): """ Users within the Django authentication system are represented by this model. Username, password and email are required. Other fields are optional. """ class Meta(AbstractUser.Meta): swappable = 'AUTH_USER_MODEL'
AbstractUser defines are:
date_joined. It inherits from
AbstractBaseUser so got
last_login from there. It also has
django.contrib.auth.models.PermissionsMixin) as it's super class so it
user_permissions fields from there. As you can imagine, the
superclasses have all the relevant methods and attributes defined as well, and
also implements some if it's own. The source codes of each are also linked so that you can check
to have a better idea of whats's going on underneath.
So based on the above idea, a simple
User model that does not have the
username field and
from django.db import models from django.contrib.auth.base_user import AbstractBaseUser from django.contrib.auth.models import PermissionsMixin from django.utils.translation import ugettext_lazy as _ class User(AbstractBaseUser, PermissionsMixin): email = models.EmailField(unique=True, max_length=255, blank=False) # All these field declarations are copied as-is from `AbstractUser` first_name = models.CharField(_('first name'), max_length=30, blank=True) last_name = models.CharField(_('last name'), max_length=150, blank=True) email = models.EmailField(_('email address'), blank=True) is_staff = models.BooleanField( _('staff status'), default=False, help_text=_('Designates whether the user can log into this admin site.'), ) is_active = models.BooleanField( _('active'), default=True, help_text=_( 'Designates whether this user should be treated as active. ' 'Unselect this instead of deleting accounts.' ), ) date_joined = models.DateTimeField(_('date joined'), default=timezone.now) # Add additional fields here if needed objects = UserManager() USERNAME_FIELD = 'email'
As seen, the major changes from default
User model are:
uniqueand it must be provided
- A custom manager is needed that overrides the
create_superusermethods used by Django internally in many places to create regular and super users, respectively.
Let's create our new
UserManager now, this is also inspired from the idea implemented by the
manager used in
from django.contrib.auth.base_user import BaseUserManager class UserManager(BaseUserManager): use_in_migrations = True def _create_user(self, email, password, **extra_fields): '''Create and save a user with the given email, and password.''' if not email: raise ValueError('The given email must be set') email = self.normalize_email(email) user = self.model(email=email, **extra_fields) user.set_password(password) user.save(using=self._db) return user def create_user(self, email, password=None, **extra_fields): extra_fields.setdefault('is_staff', False) extra_fields.setdefault('is_superuser', False) return self._create_user(email, password, **extra_fields) def create_superuser(self, email, password, **extra_fields): extra_fields.setdefault('is_staff', True) extra_fields.setdefault('is_superuser', True) if extra_fields.get('is_staff') is not True: raise ValueError('Superuser must have is_staff=True.') if extra_fields.get('is_superuser') is not True: raise ValueError('Superuser must have is_superuser=True.') return self._create_user(email, password, **extra_fields)
We need to move this definition before our
User model or
import if it's defined in
some other module.
The major change from the default
UserManager is the absense of
username in the
create_superuser methods. In our example, these methods delegate the actual user creation
_create_user method which is set up accordingly to create users based on email-password.
Note that, the names
UserManager are only a convention, you can give any name
you want but it's highly recommended that you keep the same naming conventions so that
it all makes sense to the next reader.
That's it! Now we only need to set our custom
User model as the default user model in the settings file (
AUTH_USER_MODEL = 'path.to.new.User'
And we're done! We can now use our custom user model like the way we want. We can customize it further to meet our need but here I've shown the basics of such an implementation.