Określanie backendu autentykacji¶

Pod maską, Django zarządza listą „backendów uwierzytelniania”, którą sprawdza dla uwierzytelnienia. Kiedy ktoś wywołuje django.contrib.auth.authenticate() – jak jest opisane w Jak zalogować użytkownika – Django próbuje uwierzytelnić przez wszystkie swoje backendy uwierzytelniania. Jeśli pierwsza metoda uwierzytelnienia zawiedzie, Django próbuję drugiej, i tak dalej, ąz wypróbuje wszystkie backendy.

Lista backendów uwierzytelniania do użycia jest wyspecyfikowana w ustawieniu AUTHENTICATION_BACKENDS. Powinna być to lista nazw ścieżek Pythona, które wskazują na klasy Pythona, które wiedzą jak uwierzytelniać. Te klasy mogą być gdziekolwiek na twojej ścieżce Pythona.

Domyślnie AUTHENTICATION_BACKENDS jest ustawione na:

['django.contrib.auth.backends.ModelBackend']

To podstawowy backend uwierzytelniający, który sprawdza bazę danych użytkowników Django i sprawdza wbudowane uprawnienia. Nie zawiera ochrony przeciwko atakom brute force przez żaden mechanizm ograniczania częstotliwości. Możesz albo zaimplementować swój własny mechanizm ograniczania częstotliwości we własnym backendzie auth lub użyć mechanizmów dostarczanych przez większość serwerów web.

Kolejność w AUTHENTICATION_BACKENDS ma znaczenie, więc jeśli ta sama nazwa użytkownika i hasło są poprawne w wielu backendach, Django przestanie przetwarzać przy pierwszej udanej weryfikacji.

Jeśli backend zgłasza wyjątek PermissionDenied, uwierzytelnienie nie powiedzie się w sposób natychmiastowy. Django nie będzie sprawdzało następnych backendów.

Pisanie back-endu autentykacji¶

Back-end autentykacji jest klasą, która implementuje dwie wymagane metody: get_user(user_id) i authenticate(request, **credentials) oraz zestaw związanych z prawami dostępu, opcjonalnych metod uwierzytelniających.

Metoda get_user przyjmuje user_id – które może być nazwą użytkownika, ID bazy danych lub czymkolwiek, ale musi być kluczem głównym twojego obiektu użytkownika – i zwraca obiekt użytkownika.

Metoda authenticate przyjmuje argument request i dane uwierzytelniające jako argumenty nazwane. W większości przypadków, będzie wyglądała dokładnie tak:

class MyBackend:
    def authenticate(self, request, username=None, password=None):
        # Check the username/password and return a user.
        ...

Ale może też autentykować token, w ten sposób:

class MyBackend:
    def authenticate(self, request, token=None):
        # Check the token and return a user.
        ...

Oboma sposobami, authenticate() powinno sprawdzić dane autentykujące, które dostaje i zwrócić obiekt użytkownika, który zgadza się z tymi danymi, jeżeli są one poprawne. Jeśli nie są poprawne, authenticate() powinno zwrócić None.

request to obiekt klasy HttpRequest i może mieć wartość None, jeżeli nie został podany do authenticate() (które przekazuje go do back-endu).

Panel administracyjny Django jest ściśle związany z obiektem User Django. Najlepszym sposobem na to jest tworzenie obiektu User Django dla każdego użytkownika, który istnieje dla twojego backendu (np. w twoim katalogu LDAP, twojej zewnętrznej bazie SQL itp.) Możesz albo napisać skrypt, który zrobi to za jednym razem lub twoja metoda authenticate może zrobić to podczas pierwszego logowania się użytkownika.

Przykładowy backend, który autentykuje w oparciu o zmienne nazwę użytkownika i hasło określone w twoim pliku settings.py i tworzy obiekt User Django, w momencie, kiedy użytkownika autentykuje się po raz pierwszy:

from django.conf import settings
from django.contrib.auth.hashers import check_password
from django.contrib.auth.models import User

class SettingsBackend:
    """
    Authenticate against the settings ADMIN_LOGIN and ADMIN_PASSWORD.

    Use the login name and a hash of the password. For example:

    ADMIN_LOGIN = 'admin'
    ADMIN_PASSWORD = 'pbkdf2_sha256$30000$Vo0VlMnkR4Bk$qEvtdyZRWTcOsCnI/oQ7fVOu1XAURIZYoOZ3iq8Dr4M='
    """

    def authenticate(self, request, username=None, password=None):
        login_valid = (settings.ADMIN_LOGIN == username)
        pwd_valid = check_password(password, settings.ADMIN_PASSWORD)
        if login_valid and pwd_valid:
            try:
                user = User.objects.get(username=username)
            except User.DoesNotExist:
                # Create a new user. There's no need to set a password
                # because only the password from settings.py is checked.
                user = User(username=username)
                user.is_staff = True
                user.is_superuser = True
                user.save()
            return user
        return None

    def get_user(self, user_id):
        try:
            return User.objects.get(pk=user_id)
        except User.DoesNotExist:
            return None

Obsługa uwierzytelnienia we własnych backendach¶

Własne backendy uwierzytelniania mogą zawierać swoje własne reguły dostępu.

Model użytkownika przekaże sprawdzenie uprawnień (get_group_permissions(), get_all_permissions(), has_perm() i has_module_perms()) każdemu backendowi autentykacyjnemu, który implementuje te funkcje.

Prawa dostępu dane użytkownikowi będą nadzbiorem wszystkich praw zwróconych przez wszystkie backendy. To znaczy, że Django daje użytkownikowi prawo dostępu, które daje którykolwiek z backendów.

Gdy backend zgłosi wyjątek PermissionDenied w has_perm() lub has_module_perms(), autoryzacja od razu zostanie zakończona niepowodzeniem i Django nie będzie sprawdzało kolejnych backendów.

Powyższy prosty backend mógłby mieć zaimplementowane prawa dostępu dla magicznego panelu administracyjnego całkiem prosto:

class SettingsBackend:
    ...
    def has_perm(self, user_obj, perm, obj=None):
        return user_obj.username == settings.ADMIN_LOGIN

Daje to pełne uprawnienia użytkownikowi, który otrzyma dostęp w powyższym przykładzie. Zwróć uwagę, że oprócz tych samych argumentów przekazywanych funkcjom związanym z django.contrib.auth.models.User, wszystkie funkcje backendu autentykacji przyjmują jako parametr obiekt użytkownika, którym może być użytkownik anonimowy.

Pełną implementację autoryzacji można znaleźć w klasie ModelBackend w django/contrib/auth/backends.py. Jest to domyślny backend, który przeważnie odpytuje tabelę auth_permission. Jeśli chciałbyś uzyskać własne zachowanie w tylko części API backendu, możesz skorzystać z dziedziczenia w Pythonie i stworzyć podklasę ModelBackend zamiast implementować pełne API we własnym backendzie.

Using a custom user model when starting a project¶

If you’re starting a new project, it’s highly recommended to set up a custom user model, even if the default User model is sufficient for you. This model behaves identically to the default user model, but you’ll be able to customize it in the future if the need arises:

from django.contrib.auth.models import AbstractUser

class User(AbstractUser):
    pass

Don’t forget to point AUTH_USER_MODEL to it. Do this before creating any migrations or running manage.py migrate for the first time.

Also, register the model in the app’s admin.py:

from django.contrib import admin
from django.contrib.auth.admin import UserAdmin
from .models import User

admin.site.register(User, UserAdmin)

Changing to a custom user model mid-project¶

Changing AUTH_USER_MODEL after you’ve created database tables is significantly more difficult since it affects foreign keys and many-to-many relationships, for example.

This change can’t be done automatically and requires manually fixing your schema, moving your data from the old user table, and possibly manually reapplying some migrations. See #25313 for an outline of the steps.

Due to limitations of Django’s dynamic dependency feature for swappable models, the model referenced by AUTH_USER_MODEL must be created in the first migration of its app (usually called 0001_initial); otherwise, you’ll have dependency issues.

In addition, you may run into a CircularDependencyError when running your migrations as Django won’t be able to automatically break the dependency loop due to the dynamic dependency. If you see this error, you should break the loop by moving the models depended on by your user model into a second migration. (You can try making two normal models that have a ForeignKey to each other and seeing how makemigrations resolves that circular dependency if you want to see how it’s usually done.)

Reusable apps and AUTH_USER_MODEL¶

Reusable apps shouldn’t implement a custom user model. A project may use many apps, and two reusable apps that implemented a custom user model couldn’t be used together. If you need to store per user information in your app, use a ForeignKey or OneToOneField to settings.AUTH_USER_MODEL as described below.

Referencing the User model¶

If you reference User directly (for example, by referring to it in a foreign key), your code will not work in projects where the AUTH_USER_MODEL setting has been changed to a different user model.

get_user_model()[źródło]¶

Instead of referring to User directly, you should reference the user model using django.contrib.auth.get_user_model(). This method will return the currently active user model – the custom user model if one is specified, or User otherwise.

When you define a foreign key or many-to-many relations to the user model, you should specify the custom model using the AUTH_USER_MODEL setting. For example:

from django.conf import settings
from django.db import models

class Article(models.Model):
    author = models.ForeignKey(
        settings.AUTH_USER_MODEL,
        on_delete=models.CASCADE,
    )

When connecting to signals sent by the user model, you should specify the custom model using the AUTH_USER_MODEL setting. For example:

from django.conf import settings
from django.db.models.signals import post_save

def post_save_receiver(sender, instance, created, **kwargs):
    pass

post_save.connect(post_save_receiver, sender=settings.AUTH_USER_MODEL)

Generally speaking, it’s easiest to refer to the user model with the AUTH_USER_MODEL setting in code that’s executed at import time, however, it’s also possible to call get_user_model() while Django is importing models, so you could use models.ForeignKey(get_user_model(), ...).

If your app is tested with multiple user models, using @override_settings(AUTH_USER_MODEL=...) for example, and you cache the result of get_user_model() in a module-level variable, you may need to listen to the setting_changed signal to clear the cache. For example:

from django.apps import apps
from django.contrib.auth import get_user_model
from django.core.signals import setting_changed
from django.dispatch import receiver

@receiver(setting_changed)
def user_model_swapped(**kwargs):
    if kwargs['setting'] == 'AUTH_USER_MODEL':
        apps.clear_cache()
        from myapp import some_module
        some_module.UserModel = get_user_model()

Changed in Django 1.11:

The ability to call get_user_model() at import time was added.

Specifying a custom user model¶

Django expects your custom user model to meet some minimum requirements.

If you use the default authentication backend, then your model must have a single unique field that can be used for identification purposes. This can be a username, an email address, or any other unique attribute. A non-unique username field is allowed if you use a custom authentication backend that can support it.

The easiest way to construct a compliant custom user model is to inherit from AbstractBaseUser. AbstractBaseUser provides the core implementation of a user model, including hashed passwords and tokenized password resets. You must then provide some key implementation details:

class models.CustomUser¶

USERNAME_FIELD¶

A string describing the name of the field on the user model that is used as the unique identifier. This will usually be a username of some kind, but it can also be an email address, or any other unique identifier. The field must be unique (i.e., have unique=True set in its definition), unless you use a custom authentication backend that can support non-unique usernames.

In the following example, the field identifier is used as the identifying field:

class MyUser(AbstractBaseUser):
    identifier = models.CharField(max_length=40, unique=True)
    ...
    USERNAME_FIELD = 'identifier'

USERNAME_FIELD now supports ForeignKeys. Since there is no way to pass model instances during the createsuperuser prompt, expect the user to enter the value of to_field value (the primary_key by default) of an existing instance.

EMAIL_FIELD¶

New in Django 1.11.

A string describing the name of the email field on the User model. This value is returned by get_email_field_name().

REQUIRED_FIELDS¶

A list of the field names that will be prompted for when creating a user via the createsuperuser management command. The user will be prompted to supply a value for each of these fields. It must include any field for which blank is False or undefined and may include additional fields you want prompted for when a user is created interactively. REQUIRED_FIELDS has no effect in other parts of Django, like creating a user in the admin.

For example, here is the partial definition for a user model that defines two required fields - a date of birth and height:

class MyUser(AbstractBaseUser):
    ...
    date_of_birth = models.DateField()
    height = models.FloatField()
    ...
    REQUIRED_FIELDS = ['date_of_birth', 'height']

Informacja

REQUIRED_FIELDS must contain all required fields on your user model, but should not contain the USERNAME_FIELD or password as these fields will always be prompted for.

REQUIRED_FIELDS now supports ForeignKeys. Since there is no way to pass model instances during the createsuperuser prompt, expect the user to enter the value of to_field value (the primary_key by default) of an existing instance.

is_active¶

A boolean attribute that indicates whether the user is considered „active”. This attribute is provided as an attribute on AbstractBaseUser defaulting to True. How you choose to implement it will depend on the details of your chosen auth backends. See the documentation of the is_active attribute on the built-in user model for details.

get_full_name()¶

Optional. A longer formal identifier for the user such as their full name. If implemented, this appears alongside the username in an object’s history in django.contrib.admin.

get_short_name()¶

Optional. A short, informal identifier for the user such as their first name. If implemented, this replaces the username in the greeting to the user in the header of django.contrib.admin.

Changed in Django 2.0:

In older versions, subclasses are required to implement get_short_name() and get_full_name() as AbstractBaseUser has implementations that raise NotImplementedError.

Importing AbstractBaseUser

AbstractBaseUser and BaseUserManager are importable from django.contrib.auth.base_user so that they can be imported without including django.contrib.auth in INSTALLED_APPS.

The following attributes and methods are available on any subclass of AbstractBaseUser:

class models.AbstractBaseUser¶

get_username()¶

Returns the value of the field nominated by USERNAME_FIELD.

clean()¶

Normalizes the username by calling normalize_username(). If you override this method, be sure to call super() to retain the normalization.

classmethod get_email_field_name()¶

New in Django 1.11.

Returns the name of the email field specified by the EMAIL_FIELD attribute. Defaults to 'email' if EMAIL_FIELD isn’t specified.

classmethod normalize_username(username)¶

Applies NFKC Unicode normalization to usernames so that visually identical characters with different Unicode code points are considered identical.

is_authenticated¶

Read-only attribute which is always True (as opposed to AnonymousUser.is_authenticated which is always False). This is a way to tell if the user has been authenticated. This does not imply any permissions and doesn’t check if the user is active or has a valid session. Even though normally you will check this attribute on request.user to find out whether it has been populated by the AuthenticationMiddleware (representing the currently logged-in user), you should know this attribute is True for any User instance.

is_anonymous¶

Read-only attribute which is always False. This is a way of differentiating User and AnonymousUser objects. Generally, you should prefer using is_authenticated to this attribute.

set_password(raw_password)¶

Sets the user’s password to the given raw string, taking care of the password hashing. Doesn’t save the AbstractBaseUser object.

When the raw_password is None, the password will be set to an unusable password, as if set_unusable_password() were used.

check_password(raw_password)¶

Returns True if the given raw string is the correct password for the user. (This takes care of the password hashing in making the comparison.)

set_unusable_password()¶

Marks the user as having no password set. This isn’t the same as having a blank string for a password. check_password() for this user will never return True. Doesn’t save the AbstractBaseUser object.

You may need this if authentication for your application takes place against an existing external source such as an LDAP directory.

has_usable_password()¶

Returns False if set_unusable_password() has been called for this user.

get_session_auth_hash()¶

Returns an HMAC of the password field. Used for Session invalidation on password change.

AbstractUser subclasses AbstractBaseUser:

class models.AbstractUser¶

clean()¶

New in Django 1.11.

Normalizes the email by calling BaseUserManager.normalize_email(). If you override this method, be sure to call super() to retain the normalization.

You should also define a custom manager for your user model. If your user model defines username, email, is_staff, is_active, is_superuser, last_login, and date_joined fields the same as Django’s default user, you can just install Django’s UserManager; however, if your user model defines different fields, you’ll need to define a custom manager that extends BaseUserManager providing two additional methods:

class models.CustomUserManager¶

create_user(*username_field*, password=None, **other_fields)¶

The prototype of create_user() should accept the username field, plus all required fields as arguments. For example, if your user model uses email as the username field, and has date_of_birth as a required field, then create_user should be defined as:

def create_user(self, email, date_of_birth, password=None):
    # create user here
    ...

create_superuser(*username_field*, password, **other_fields)¶

The prototype of create_superuser() should accept the username field, plus all required fields as arguments. For example, if your user model uses email as the username field, and has date_of_birth as a required field, then create_superuser should be defined as:

def create_superuser(self, email, date_of_birth, password):
    # create superuser here
    ...

Unlike create_user(), create_superuser() must require the caller to provide a password.

BaseUserManager provides the following utility methods:

class models.BaseUserManager¶

classmethod normalize_email(email)¶

Normalizes email addresses by lowercasing the domain portion of the email address.

get_by_natural_key(username)¶

Retrieves a user instance using the contents of the field nominated by USERNAME_FIELD.

make_random_password(length=10, allowed_chars='abcdefghjkmnpqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ23456789')¶

Returns a random password with the given length and given string of allowed characters. Note that the default value of allowed_chars doesn’t contain letters that can cause user confusion, including:

• i, l, I, and 1 (lowercase letter i, lowercase letter L, uppercase letter i, and the number one)
• o, O, and 0 (lowercase letter o, uppercase letter o, and zero)

Extending Django’s default User¶

If you’re entirely happy with Django’s User model and you just want to add some additional profile information, you could simply subclass django.contrib.auth.models.AbstractUser and add your custom profile fields, although we’d recommend a separate model as described in the „Model design considerations” note of Specifying a custom user model. AbstractUser provides the full implementation of the default User as an abstract model.

Custom users and the built-in auth forms¶

Django’s built-in forms and views make certain assumptions about the user model that they are working with.

The following forms are compatible with any subclass of AbstractBaseUser:

• AuthenticationForm: Uses the username field specified by USERNAME_FIELD.
• SetPasswordForm
• PasswordChangeForm
• AdminPasswordChangeForm

The following forms make assumptions about the user model and can be used as-is if those assumptions are met:

• PasswordResetForm: Assumes that the user model has a field that stores the user’s email address with the name returned by get_email_field_name() (email by default) that can be used to identify the user and a boolean field named is_active to prevent password resets for inactive users.

Finally, the following forms are tied to User and need to be rewritten or extended to work with a custom user model:

• UserCreationForm
• UserChangeForm

If your custom user model is a simple subclass of AbstractUser, then you can extend these forms in this manner:

from django.contrib.auth.forms import UserCreationForm
from myapp.models import CustomUser

class CustomUserCreationForm(UserCreationForm):

    class Meta(UserCreationForm.Meta):
        model = CustomUser
        fields = UserCreationForm.Meta.fields + ('custom_field',)

Custom users and django.contrib.admin¶

If you want your custom user model to also work with the admin, your user model must define some additional attributes and methods. These methods allow the admin to control access of the user to admin content:

class models.CustomUser

is_staff¶

Returns True if the user is allowed to have access to the admin site.

is_active¶

Returns True if the user account is currently active.

has_perm(perm, obj=None):

Returns True if the user has the named permission. If obj is provided, the permission needs to be checked against a specific object instance.

has_module_perms(app_label):

Returns True if the user has permission to access models in the given app.

You will also need to register your custom user model with the admin. If your custom user model extends django.contrib.auth.models.AbstractUser, you can use Django’s existing django.contrib.auth.admin.UserAdmin class. However, if your user model extends AbstractBaseUser, you’ll need to define a custom ModelAdmin class. It may be possible to subclass the default django.contrib.auth.admin.UserAdmin; however, you’ll need to override any of the definitions that refer to fields on django.contrib.auth.models.AbstractUser that aren’t on your custom user class.

Custom users and permissions¶

To make it easy to include Django’s permission framework into your own user class, Django provides PermissionsMixin. This is an abstract model you can include in the class hierarchy for your user model, giving you all the methods and database fields necessary to support Django’s permission model.

PermissionsMixin provides the following methods and attributes:

class models.PermissionsMixin¶

is_superuser¶

Boolean. Designates that this user has all permissions without explicitly assigning them.

get_group_permissions(obj=None)¶

Returns a set of permission strings that the user has, through their groups.

If obj is passed in, only returns the group permissions for this specific object.

get_all_permissions(obj=None)¶

Returns a set of permission strings that the user has, both through group and user permissions.

If obj is passed in, only returns the permissions for this specific object.

has_perm(perm, obj=None)¶

Returns True if the user has the specified permission, where perm is in the format "<app label>.<permission codename>" (see permissions). If the user is inactive, this method will always return False.

If obj is passed in, this method won’t check for a permission for the model, but for this specific object.

has_perms(perm_list, obj=None)¶

Returns True if the user has each of the specified permissions, where each perm is in the format "<app label>.<permission codename>". If the user is inactive, this method will always return False.

If obj is passed in, this method won’t check for permissions for the model, but for the specific object.

has_module_perms(package_name)¶

Returns True if the user has any permissions in the given package (the Django app label). If the user is inactive, this method will always return False.

Custom users and proxy models¶

One limitation of custom user models is that installing a custom user model will break any proxy model extending User. Proxy models must be based on a concrete base class; by defining a custom user model, you remove the ability of Django to reliably identify the base class.

If your project uses proxy models, you must either modify the proxy to extend the user model that’s in use in your project, or merge your proxy’s behavior into your User subclass.

A full example¶

Here is an example of an admin-compliant custom user app. This user model uses an email address as the username, and has a required date of birth; it provides no permission checking, beyond a simple admin flag on the user account. This model would be compatible with all the built-in auth forms and views, except for the user creation forms. This example illustrates how most of the components work together, but is not intended to be copied directly into projects for production use.

This code would all live in a models.py file for a custom authentication app:

from django.db import models
from django.contrib.auth.models import (
    BaseUserManager, AbstractBaseUser
)


class MyUserManager(BaseUserManager):
    def create_user(self, email, date_of_birth, password=None):
        """
        Creates and saves a User with the given email, date of
        birth and password.
        """
        if not email:
            raise ValueError('Users must have an email address')

        user = self.model(
            email=self.normalize_email(email),
            date_of_birth=date_of_birth,
        )

        user.set_password(password)
        user.save(using=self._db)
        return user

    def create_superuser(self, email, date_of_birth, password):
        """
        Creates and saves a superuser with the given email, date of
        birth and password.
        """
        user = self.create_user(
            email,
            password=password,
            date_of_birth=date_of_birth,
        )
        user.is_admin = True
        user.save(using=self._db)
        return user


class MyUser(AbstractBaseUser):
    email = models.EmailField(
        verbose_name='email address',
        max_length=255,
        unique=True,
    )
    date_of_birth = models.DateField()
    is_active = models.BooleanField(default=True)
    is_admin = models.BooleanField(default=False)

    objects = MyUserManager()

    USERNAME_FIELD = 'email'
    REQUIRED_FIELDS = ['date_of_birth']

    def __str__(self):
        return self.email

    def has_perm(self, perm, obj=None):
        "Does the user have a specific permission?"
        # Simplest possible answer: Yes, always
        return True

    def has_module_perms(self, app_label):
        "Does the user have permissions to view the app `app_label`?"
        # Simplest possible answer: Yes, always
        return True

    @property
    def is_staff(self):
        "Is the user a member of staff?"
        # Simplest possible answer: All admins are staff
        return self.is_admin

Then, to register this custom user model with Django’s admin, the following code would be required in the app’s admin.py file:

from django import forms
from django.contrib import admin
from django.contrib.auth.models import Group
from django.contrib.auth.admin import UserAdmin as BaseUserAdmin
from django.contrib.auth.forms import ReadOnlyPasswordHashField

from customauth.models import MyUser


class UserCreationForm(forms.ModelForm):
    """A form for creating new users. Includes all the required
    fields, plus a repeated password."""
    password1 = forms.CharField(label='Password', widget=forms.PasswordInput)
    password2 = forms.CharField(label='Password confirmation', widget=forms.PasswordInput)

    class Meta:
        model = MyUser
        fields = ('email', 'date_of_birth')

    def clean_password2(self):
        # Check that the two password entries match
        password1 = self.cleaned_data.get("password1")
        password2 = self.cleaned_data.get("password2")
        if password1 and password2 and password1 != password2:
            raise forms.ValidationError("Passwords don't match")
        return password2

    def save(self, commit=True):
        # Save the provided password in hashed format
        user = super().save(commit=False)
        user.set_password(self.cleaned_data["password1"])
        if commit:
            user.save()
        return user


class UserChangeForm(forms.ModelForm):
    """A form for updating users. Includes all the fields on
    the user, but replaces the password field with admin's
    password hash display field.
    """
    password = ReadOnlyPasswordHashField()

    class Meta:
        model = MyUser
        fields = ('email', 'password', 'date_of_birth', 'is_active', 'is_admin')

    def clean_password(self):
        # Regardless of what the user provides, return the initial value.
        # This is done here, rather than on the field, because the
        # field does not have access to the initial value
        return self.initial["password"]


class UserAdmin(BaseUserAdmin):
    # The forms to add and change user instances
    form = UserChangeForm
    add_form = UserCreationForm

    # The fields to be used in displaying the User model.
    # These override the definitions on the base UserAdmin
    # that reference specific fields on auth.User.
    list_display = ('email', 'date_of_birth', 'is_admin')
    list_filter = ('is_admin',)
    fieldsets = (
        (None, {'fields': ('email', 'password')}),
        ('Personal info', {'fields': ('date_of_birth',)}),
        ('Permissions', {'fields': ('is_admin',)}),
    )
    # add_fieldsets is not a standard ModelAdmin attribute. UserAdmin
    # overrides get_fieldsets to use this attribute when creating a user.
    add_fieldsets = (
        (None, {
            'classes': ('wide',),
            'fields': ('email', 'date_of_birth', 'password1', 'password2')}
        ),
    )
    search_fields = ('email',)
    ordering = ('email',)
    filter_horizontal = ()

# Now register the new UserAdmin...
admin.site.register(MyUser, UserAdmin)
# ... and, since we're not using Django's built-in permissions,
# unregister the Group model from admin.
admin.site.unregister(Group)

Finally, specify the custom model as the default user model for your project using the AUTH_USER_MODEL setting in your settings.py:

AUTH_USER_MODEL = 'customauth.MyUser'