Django自带的验证机制足以应对一般情况，但是你可能不满足于默认的可立即使用的配置。在你的项目中自定义验证机制，需要了解在已有验证系统中哪些地方是可以扩展的，哪些地方是可以代替的。这个文档提供了如何自定义验证系统的一些细节。
\n<authentication-backends>当用户模型中存储的用户名和密码需要不同于Django默认服务的验证时，提供了一个可扩展系统。
\n你可以给你的模型 定制权限 并且可以被Django的授权系统通过检查。
\n你可以 :ref:` 扩展 <extending-user> ` 默认的 User 模型，或者完全自定义一个模型进行 :ref:` 替换 <auth-custom-user>`
有时候你需要连接到其他认证源——一个包含用户名及密码的源或者认证方法。
\n例如，你的公司可能已经存在一套存储所有员工用户名及密码的 LDAP 配置。如果用户在LDAP和基于Django的应用程序中都有独立账号，那对用户自己或者网络管理员都会造成麻烦。
\n所以，为了处理这样的情况，Django认证系统可以让你插入其他认证源。您可以重写Django的默认基于数据库的方案，或者可以与其他系统一起使用默认系统。
\n请参阅<authentication-backends-reference>身份验证后端引用，有关Django中包含的身份验证后端的信息。
\n在幕后，Django维护一个“身份验证后端”列表，用于检查身份验证。当有人调用:func:django.contrib.auth.authenticate() - 如下所示:ref:如何在`用户登录<how-to-log-a-user-in> - Django尝试所有身份验证后端进行身份验证。如果第一个验证方法失败，Django会尝试第二个验证方法，依此类推，直到所有后端都被尝试。
\n在设置：`AUTHENTICATION_BACKENDS`设置中指定要使用的身份验证后端列表。这应该是一个Python路径名列表，指向知道如何进行身份验证的Python类。这些类可以在你的Python路径上的任何地方。
\n默认， :setting:`AUTHENTICATION_BACKENDS`设定为:
\n['django.contrib.auth.backends.ModelBackend']\nDjango 的默认后台只检查其数据库和内置权限，并不提供任何登录限制机制来防止暴力登录攻击。如果需要抵制暴力登录攻击，需要自己在后台实现登录限制机制，或者使用 Web 服务器提供的保护机制。
\n:setting:`AUTHENTICATION_BACKENDS`是有序的，如果相同的用户名和密码对于多个后端都是合法的，那么 Django 会优先使用其中的第一个后端，而不会再处理后面的后端。
\n如果一个后端抛出 PermissionDenied 异常，则验证流程立马终止，Django 不会继续检查其后的后端。
一个验证后端其实就是一个 class，它实现了两个必要的方法：get_user(user_id) 和 authenticate(request, **credentials)，以及其它一系列可选的权限相关的方法:ref:`authorization methods<authorization_methods> `.
get_user 方法只接受一个参数``user_id``，user_id 有可能是 用户名、数据库 ID 或者其它任何值（该值必须是用户对象的主键），该方法返回一个用户对象。
authenticate``方法接受 ``request 参数和 credentials 关键字参数，大多数情况下，该方法类似于下面的代码:
class MyBackend:\n def authenticate(self, request, username=None, password=None):\n # Check the username/password and return a user.\n ...\n但它也可能验证一个Token，就像这样:
\nclass MyBackend:\n def authenticate(self, request, token=None):\n # Check the token and return a user.\n ...\n无论是哪一种方式，authenticate()``都应该检查所获得的凭证，并当凭证有效时返回一个用户对象。当凭证无效时，应该返回``None。
request 是 HttpRequest ，默认为 None 如果没有被提供给 authenticate() (它把request传给后端).
Django admin 和 Django User object. 紧密结合。最好的处理方式是为你后端的每一个用户都创建一个 Django User 。(例如, 你的 LDAP 目录、你的外部 SQL 数据库等等。) 你能写一个脚本来提前做这件事情，或者让你的 authenticate 方法在一个用户第一次登录时做这件事。
下面是一段验证后端的示例代码，它通过在 ``settings.py``文件中定义的用户名和密码变量进行身份验证，并且当用户第一次验证时，创建一个Django的``User``对象。
\nfrom django.conf import settings\nfrom django.contrib.auth.hashers import check_password\nfrom django.contrib.auth.models import User\n\nclass SettingsBackend:\n """\n Authenticate against the settings ADMIN_LOGIN and ADMIN_PASSWORD.\n\n Use the login name and a hash of the password. For example:\n\n ADMIN_LOGIN = 'admin'\n ADMIN_PASSWORD = 'pbkdf2_sha256$30000$Vo0VlMnkR4Bk$qEvtdyZRWTcOsCnI/oQ7fVOu1XAURIZYoOZ3iq8Dr4M='\n """\n\n def authenticate(self, request, username=None, password=None):\n login_valid = (settings.ADMIN_LOGIN == username)\n pwd_valid = check_password(password, settings.ADMIN_PASSWORD)\n if login_valid and pwd_valid:\n try:\n user = User.objects.get(username=username)\n except User.DoesNotExist:\n # Create a new user. There's no need to set a password\n # because only the password from settings.py is checked.\n user = User(username=username)\n user.is_staff = True\n user.is_superuser = True\n user.save()\n return user\n return None\n\n def get_user(self, user_id):\n try:\n return User.objects.get(pk=user_id)\n except User.DoesNotExist:\n return None\n为给定的模型对象创建自定权限，使用 permission ， 参考： model Meta attribute<meta-options>
\n这个 Task 模型创建了三个用户自定权限，即：用户能不能使用 Task 实例执行操作，取决于你的应用程序。
\nclass Task(models.Model):\n ...\n class Meta:\n permissions = (\n ("view_task", "Can see available tasks"),\n ("change_task_status", "Can change the status of tasks"),\n ("close_task", "Can remove a task by setting its status as closed"),\n )\n当你运行:djadmin:manage.py migrate <migrate> 时，它只创建那些额外的权限。（创建权限的函数连接到:data:~django.db.models.signals.post_migrate 信号）。 你的代码负责在用户试图访问由应用程序提供的功能（查看任务（task），改变任务状态，关闭任务）时检查这些权限的值。继续上面的例子， 下面的语句检查是否一个用户能查看任务:
\nuser.has_perm('app.view_task')\nUser）模型Link to this heading#There are two ways to extend the default\nUser model without substituting your own\nmodel. If the changes you need are purely behavioral, and don't require any\nchange to what is stored in the database, you can create a proxy model based on User. This\nallows for any of the features offered by proxy models including default\nordering, custom managers, or custom model methods.
If you wish to store information related to User, you can use a\nOneToOneField to a model containing the fields for\nadditional information. This one-to-one model is often called a profile model,\nas it might store non-auth related information about a site user. For example\nyou might create an Employee model:
from django.contrib.auth.models import User\n\nclass Employee(models.Model):\n user = models.OneToOneField(User, on_delete=models.CASCADE)\n department = models.CharField(max_length=100)\n假设一个既有用户又有雇员模型的现有雇员Fred Smith，您可以使用Django的标准相关模型约定访问相关信息：
\n>>> u = User.objects.get(username='fsmith')\n>>> freds_department = u.employee.department\nTo add a profile model's fields to the user page in the admin, define an\nInlineModelAdmin (for this example, we'll use a\nStackedInline) in your app's admin.py and\nadd it to a UserAdmin class which is registered with the\nUser class:
from django.contrib import admin\nfrom django.contrib.auth.admin import UserAdmin as BaseUserAdmin\nfrom django.contrib.auth.models import User\n\nfrom my_user_profile_app.models import Employee\n\n# Define an inline admin descriptor for Employee model\n# which acts a bit like a singleton\nclass EmployeeInline(admin.StackedInline):\n model = Employee\n can_delete = False\n verbose_name_plural = 'employee'\n\n# Define a new User admin\nclass UserAdmin(BaseUserAdmin):\n inlines = (EmployeeInline, )\n\n# Re-register UserAdmin\nadmin.site.unregister(User)\nadmin.site.register(User, UserAdmin)\nThese profile models are not special in any way - they are just Django models\nthat happen to have a one-to-one link with a user model. As such, they aren't\nauto created when a user is created, but\na django.db.models.signals.post_save could be used to create or update\nrelated models as appropriate.
Using related models results in additional queries or joins to retrieve the\nrelated data. Depending on your needs, a custom user model that includes the\nrelated fields may be your better option, however, existing relations to the\ndefault user model within your project's apps may justify the extra database\nload.
\nUser 模型。Link to this heading#Some kinds of projects may have authentication requirements for which Django's\nbuilt-in User model is not always\nappropriate. For instance, on some sites it makes more sense to use an email\naddress as your identification token instead of a username.
Django 允许你为引用了自定模型的：setting: AUTH_USER_MODEL 设置一个值来重写默认的用户表。
\nAUTH_USER_MODEL = 'myapp.MyUser'\nThis dotted pair describes the name of the Django app (which must be in your\nINSTALLED_APPS), and the name of the Django model that you wish to\nuse as your user model.
If you're starting a new project, it's highly recommended to set up a custom\nuser model, even if the default User model\nis sufficient for you. This model behaves identically to the default user\nmodel, but you'll be able to customize it in the future if the need arises:
from django.contrib.auth.models import AbstractUser\n\nclass User(AbstractUser):\n pass\nDon't forget to point AUTH_USER_MODEL to it. Do this before creating\nany migrations or running manage.py migrate for the first time.
同样的，在 app 中的 admin.py 中注册模型。
from django.contrib import admin\nfrom django.contrib.auth.admin import UserAdmin\nfrom .models import User\n\nadmin.site.register(User, UserAdmin)\nChanging AUTH_USER_MODEL after you've created database tables is\nsignificantly more difficult since it affects foreign keys and many-to-many\nrelationships, for example.
This change can't be done automatically and requires manually fixing your\nschema, moving your data from the old user table, and possibly manually\nreapplying some migrations. See #25313 for an outline of the steps.
\nDue to limitations of Django's dynamic dependency feature for swappable\nmodels, the model referenced by AUTH_USER_MODEL must be created in\nthe first migration of its app (usually called 0001_initial); otherwise,\nyou'll have dependency issues.
In addition, you may run into a CircularDependencyError when running your\nmigrations as Django won't be able to automatically break the dependency loop\ndue to the dynamic dependency. If you see this error, you should break the loop\nby moving the models depended on by your user model into a second migration.\n(You can try making two normal models that have a ForeignKey to each other\nand seeing how makemigrations resolves that circular dependency if you want\nto see how it's usually done.)
AUTH_USER_MODELLink to this heading#Reusable apps shouldn't implement a custom user model. A project may use many\napps, and two reusable apps that implemented a custom user model couldn't be\nused together. If you need to store per user information in your app, use\na ForeignKey or\nOneToOneField to settings.AUTH_USER_MODEL\nas described below.
User modelLink to this heading#If you reference User directly (for\nexample, by referring to it in a foreign key), your code will not work in\nprojects where the AUTH_USER_MODEL setting has been changed to a\ndifferent user model.
Instead of referring to User directly,\nyou should reference the user model using\ndjango.contrib.auth.get_user_model(). This method will return the\ncurrently active user model -- the custom user model if one is specified, or\nUser otherwise.
When you define a foreign key or many-to-many relations to the user model,\nyou should specify the custom model using the AUTH_USER_MODEL\nsetting. For example:
from django.conf import settings\nfrom django.db import models\n\nclass Article(models.Model):\n author = models.ForeignKey(\n settings.AUTH_USER_MODEL,\n on_delete=models.CASCADE,\n )\nWhen connecting to signals sent by the user model, you should specify\nthe custom model using the AUTH_USER_MODEL setting. For example:
from django.conf import settings\nfrom django.db.models.signals import post_save\n\ndef post_save_receiver(sender, instance, created, **kwargs):\n pass\n\npost_save.connect(post_save_receiver, sender=settings.AUTH_USER_MODEL)\nGenerally speaking, it's easiest to refer to the user model with the\nAUTH_USER_MODEL setting in code that's executed at import time,\nhowever, it's also possible to call get_user_model() while Django\nis importing models, so you could use\nmodels.ForeignKey(get_user_model(), ...).
If your app is tested with multiple user models, using\n@override_settings(AUTH_USER_MODEL=...) for example, and you cache the\nresult of get_user_model() in a module-level variable, you may need to\nlisten to the setting_changed signal to clear\nthe cache. For example:
from django.apps import apps\nfrom django.contrib.auth import get_user_model\nfrom django.core.signals import setting_changed\nfrom django.dispatch import receiver\n\n@receiver(setting_changed)\ndef user_model_swapped(**kwargs):\n if kwargs['setting'] == 'AUTH_USER_MODEL':\n apps.clear_cache()\n from myapp import some_module\n some_module.UserModel = get_user_model()\nDjango 希望你自定义的用户模型能够满足一些最低需求。
\n如果使用默认身份验证后端，那么您的模型必须具有用于标识目的的唯一字段。这可以是用户名、电子邮件地址或任何其他唯一属性。如果使用可以支持它的自定义身份验证后端，则允许使用非唯一用户名字段。
\n构造一个兼容的自定义用户模型的最简单方法是继承:class:~django.contrib.auth.models.AbstractBaseUser。:class:`~django.contrib.auth.models.AbstractBaseUser`提供用户模型的核心实现，包括散列密码和标记化的密码重置。然后必须提供一些关键实现细节：
\n作为唯一标识符的描述用户模型字段名的字符串，通常是一个用户名，但也可以是一个电子邮件地址，或任何其他唯一标识符。该字段*必须*是唯一的（即定义了 unique=True ），除非你使用自定义身份验证后端，可以支持非唯一的用户名。
接下来的样例中，identifier 字段将被用作识别字段。
class MyUser(AbstractBaseUser):\n identifier = models.CharField(max_length=40, unique=True)\n ...\n USERNAME_FIELD = 'identifier'\nUSERNAME_FIELD now supports\nForeignKeys. Since there is no way to pass\nmodel instances during the createsuperuser prompt, expect the\nuser to enter the value of to_field\nvalue (the primary_key by default) of an\nexisting instance.
A string describing the name of the email field on the User model.\nThis value is returned by\nget_email_field_name().
A list of the field names that will be prompted for when creating a\nuser via the createsuperuser management command. The user\nwill be prompted to supply a value for each of these fields. It must\ninclude any field for which blank is\nFalse or undefined and may include additional fields you want\nprompted for when a user is created interactively.\nREQUIRED_FIELDS has no effect in other parts of Django, like\ncreating a user in the admin.
比如说，这里是一个局部的用户模型，定义了两个必须的字段——生日和身高。
\nclass MyUser(AbstractBaseUser):\n ...\n date_of_birth = models.DateField()\n height = models.FloatField()\n ...\n REQUIRED_FIELDS = ['date_of_birth', 'height']\nREQUIRED_FIELDS now supports\nForeignKeys. Since there is no way to pass\nmodel instances during the createsuperuser prompt, expect the\nuser to enter the value of to_field\nvalue (the primary_key by default) of an\nexisting instance.
A boolean attribute that indicates whether the user is considered\n"active". This attribute is provided as an attribute on\nAbstractBaseUser defaulting to True. How you choose to\nimplement it will depend on the details of your chosen auth backends.\nSee the documentation of the is_active attribute on the built-in\nuser model for details.
Optional. A longer formal identifier for the user such as their full\nname. If implemented, this appears alongside the username in an\nobject's history in django.contrib.admin.
Optional. A short, informal identifier for the user such as their\nfirst name. If implemented, this replaces the username in the greeting\nto the user in the header of django.contrib.admin.
The following attributes and methods are available on any subclass of\nAbstractBaseUser:
Returns the value of the field nominated by USERNAME_FIELD.
Normalizes the username by calling normalize_username(). If you\noverride this method, be sure to call super() to retain the\nnormalization.
Returns the name of the email field specified by the\nEMAIL_FIELD attribute. Defaults to\n'email' if EMAIL_FIELD isn't specified.
Applies NFKC Unicode normalization to usernames so that visually\nidentical characters with different Unicode code points are considered\nidentical.
\nRead-only attribute which is always True (as opposed to\nAnonymousUser.is_authenticated which is always False).\nThis is a way to tell if the user has been authenticated. This does not\nimply any permissions and doesn't check if the user is active or has\na valid session. Even though normally you will check this attribute on\nrequest.user to find out whether it has been populated by the\nAuthenticationMiddleware\n(representing the currently logged-in user), you should know this\nattribute is True for any User instance.
Read-only attribute which is always False. This is a way of\ndifferentiating User and AnonymousUser\nobjects. Generally, you should prefer using\nis_authenticated to this attribute.
Sets the user's password to the given raw string, taking care of the\npassword hashing. Doesn't save the\nAbstractBaseUser object.
When the raw_password is None, the password will be set to an\nunusable password, as if\nset_unusable_password()\nwere used.
Returns True if the given raw string is the correct password for\nthe user. (This takes care of the password hashing in making the\ncomparison.)
Marks the user as having no password set. This isn't the same as\nhaving a blank string for a password.\ncheck_password() for this user\nwill never return True. Doesn't save the\nAbstractBaseUser object.
You may need this if authentication for your application takes place\nagainst an existing external source such as an LDAP directory.
\nReturns False if\nset_unusable_password() has\nbeen called for this user.
Returns an HMAC of the password field. Used for\nSession invalidation on password change.
\nAbstractUser subclasses AbstractBaseUser:
Normalizes the email by calling\nBaseUserManager.normalize_email(). If you override this method,\nbe sure to call super() to retain the normalization.
You should also define a custom manager for your user model. If your user model\ndefines username, email, is_staff, is_active, is_superuser,\nlast_login, and date_joined fields the same as Django's default user,\nyou can just install Django's UserManager;\nhowever, if your user model defines different fields, you'll need to define a\ncustom manager that extends BaseUserManager\nproviding two additional methods:
The prototype of create_user() should accept the username field,\nplus all required fields as arguments. For example, if your user model\nuses email as the username field, and has date_of_birth as a\nrequired field, then create_user should be defined as:
def create_user(self, email, date_of_birth, password=None):\n # create user here\n ...\nThe prototype of create_superuser() should accept the username\nfield, plus all required fields as arguments. For example, if your user\nmodel uses email as the username field, and has date_of_birth\nas a required field, then create_superuser should be defined as:
def create_superuser(self, email, date_of_birth, password):\n # create superuser here\n ...\nUnlike create_user(), create_superuser() must require the\ncaller to provide a password.
BaseUserManager provides the following\nutility methods:
Normalizes email addresses by lowercasing the domain portion of the\nemail address.
\nRetrieves a user instance using the contents of the field\nnominated by USERNAME_FIELD.
Returns a random password with the given length and given string of\nallowed characters. Note that the default value of allowed_chars\ndoesn't contain letters that can cause user confusion, including:
i, l, I, and 1 (lowercase letter i, lowercase\nletter L, uppercase letter i, and the number one)
o, O, and 0 (lowercase letter o, uppercase letter o,\nand zero)
UserLink to this heading#If you're entirely happy with Django's User\nmodel and you just want to add some additional profile information, you could\nsimply subclass django.contrib.auth.models.AbstractUser and add your\ncustom profile fields, although we'd recommend a separate model as described in\nthe "Model design considerations" note of 指定自定义用户模型.\nAbstractUser provides the full implementation of the default\nUser as an abstract model.
Django's built-in forms and views make certain assumptions about the user model that they\nare working with.
\nThe following forms are compatible with any subclass of\nAbstractBaseUser:
AuthenticationForm: Uses the username\nfield specified by USERNAME_FIELD.
The following forms make assumptions about the user model and can be used as-is\nif those assumptions are met:
\nPasswordResetForm: Assumes that the user\nmodel has a field that stores the user's email address with the name returned\nby get_email_field_name() (email by\ndefault) that can be used to identify the user and a boolean field named\nis_active to prevent password resets for inactive users.
Finally, the following forms are tied to\nUser and need to be rewritten or extended\nto work with a custom user model:
If your custom user model is a simple subclass of AbstractUser, then you\ncan extend these forms in this manner:
from django.contrib.auth.forms import UserCreationForm\nfrom myapp.models import CustomUser\n\nclass CustomUserCreationForm(UserCreationForm):\n\n class Meta(UserCreationForm.Meta):\n model = CustomUser\n fields = UserCreationForm.Meta.fields + ('custom_field',)\ndjango.contrib.adminLink to this heading#If you want your custom user model to also work with the admin, your user model\nmust define some additional attributes and methods. These methods allow the\nadmin to control access of the user to admin content:
\n如果允许用户有访问 admin 页面就返回 True。
返回``True``，如果该用户的账号当前是激活状态
\nReturns True if the user has the named permission. If obj is\nprovided, the permission needs to be checked against a specific object\ninstance.
Returns True if the user has permission to access models in\nthe given app.
You will also need to register your custom user model with the admin. If\nyour custom user model extends django.contrib.auth.models.AbstractUser,\nyou can use Django's existing django.contrib.auth.admin.UserAdmin\nclass. However, if your user model extends\nAbstractBaseUser, you'll need to define\na custom ModelAdmin class. It may be possible to subclass the default\ndjango.contrib.auth.admin.UserAdmin; however, you'll need to\noverride any of the definitions that refer to fields on\ndjango.contrib.auth.models.AbstractUser that aren't on your\ncustom user class.
To make it easy to include Django's permission framework into your own user\nclass, Django provides PermissionsMixin.\nThis is an abstract model you can include in the class hierarchy for your user\nmodel, giving you all the methods and database fields necessary to support\nDjango's permission model.
PermissionsMixin provides the following\nmethods and attributes:
Boolean. Designates that this user has all permissions without\nexplicitly assigning them.
\nReturns a set of permission strings that the user has, through their\ngroups.
\nIf obj is passed in, only returns the group permissions for\nthis specific object.
Returns a set of permission strings that the user has, both through\ngroup and user permissions.
\nIf obj is passed in, only returns the permissions for this\nspecific object.
Returns True if the user has the specified permission, where\nperm is in the format "<app label>.<permission codename>" (see\npermissions). If the user is inactive, this method will\nalways return False.
If obj is passed in, this method won't check for a permission for\nthe model, but for this specific object.
Returns True if the user has each of the specified permissions,\nwhere each perm is in the format\n"<app label>.<permission codename>". If the user is inactive,\nthis method will always return False.
If obj is passed in, this method won't check for permissions for\nthe model, but for the specific object.
Returns True if the user has any permissions in the given package\n(the Django app label). If the user is inactive, this method will\nalways return False.
One limitation of custom user models is that installing a custom user model\nwill break any proxy model extending User.\nProxy models must be based on a concrete base class; by defining a custom user\nmodel, 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\nthe user model that's in use in your project, or merge your proxy's behavior\ninto your User subclass.
Here is an example of an admin-compliant custom user app. This user model uses\nan email address as the username, and has a required date of birth; it\nprovides no permission checking, beyond a simple admin flag on the user\naccount. This model would be compatible with all the built-in auth forms and\nviews, except for the user creation forms. This example illustrates how most of\nthe components work together, but is not intended to be copied directly into\nprojects for production use.
This code would all live in a models.py file for a custom\nauthentication app:
from django.db import models\nfrom django.contrib.auth.models import (\n BaseUserManager, AbstractBaseUser\n)\n\n\nclass MyUserManager(BaseUserManager):\n def create_user(self, email, date_of_birth, password=None):\n """\n Creates and saves a User with the given email, date of\n birth and password.\n """\n if not email:\n raise ValueError('Users must have an email address')\n\n user = self.model(\n email=self.normalize_email(email),\n date_of_birth=date_of_birth,\n )\n\n user.set_password(password)\n user.save(using=self._db)\n return user\n\n def create_superuser(self, email, date_of_birth, password):\n """\n Creates and saves a superuser with the given email, date of\n birth and password.\n """\n user = self.create_user(\n email,\n password=password,\n date_of_birth=date_of_birth,\n )\n user.is_admin = True\n user.save(using=self._db)\n return user\n\n\nclass MyUser(AbstractBaseUser):\n email = models.EmailField(\n verbose_name='email address',\n max_length=255,\n unique=True,\n )\n date_of_birth = models.DateField()\n is_active = models.BooleanField(default=True)\n is_admin = models.BooleanField(default=False)\n\n objects = MyUserManager()\n\n USERNAME_FIELD = 'email'\n REQUIRED_FIELDS = ['date_of_birth']\n\n def __str__(self):\n return self.email\n\n def has_perm(self, perm, obj=None):\n "Does the user have a specific permission?"\n # Simplest possible answer: Yes, always\n return True\n\n def has_module_perms(self, app_label):\n "Does the user have permissions to view the app `app_label`?"\n # Simplest possible answer: Yes, always\n return True\n\n @property\n def is_staff(self):\n "Is the user a member of staff?"\n # Simplest possible answer: All admins are staff\n return self.is_admin\nThen, to register this custom user model with Django's admin, the following\ncode would be required in the app's admin.py file:
from django import forms\nfrom django.contrib import admin\nfrom django.contrib.auth.models import Group\nfrom django.contrib.auth.admin import UserAdmin as BaseUserAdmin\nfrom django.contrib.auth.forms import ReadOnlyPasswordHashField\n\nfrom customauth.models import MyUser\n\n\nclass UserCreationForm(forms.ModelForm):\n """A form for creating new users. Includes all the required\n fields, plus a repeated password."""\n password1 = forms.CharField(label='Password', widget=forms.PasswordInput)\n password2 = forms.CharField(label='Password confirmation', widget=forms.PasswordInput)\n\n class Meta:\n model = MyUser\n fields = ('email', 'date_of_birth')\n\n def clean_password2(self):\n # Check that the two password entries match\n password1 = self.cleaned_data.get("password1")\n password2 = self.cleaned_data.get("password2")\n if password1 and password2 and password1 != password2:\n raise forms.ValidationError("Passwords don't match")\n return password2\n\n def save(self, commit=True):\n # Save the provided password in hashed format\n user = super().save(commit=False)\n user.set_password(self.cleaned_data["password1"])\n if commit:\n user.save()\n return user\n\n\nclass UserChangeForm(forms.ModelForm):\n """A form for updating users. Includes all the fields on\n the user, but replaces the password field with admin's\n password hash display field.\n """\n password = ReadOnlyPasswordHashField()\n\n class Meta:\n model = MyUser\n fields = ('email', 'password', 'date_of_birth', 'is_active', 'is_admin')\n\n def clean_password(self):\n # Regardless of what the user provides, return the initial value.\n # This is done here, rather than on the field, because the\n # field does not have access to the initial value\n return self.initial["password"]\n\n\nclass UserAdmin(BaseUserAdmin):\n # The forms to add and change user instances\n form = UserChangeForm\n add_form = UserCreationForm\n\n # The fields to be used in displaying the User model.\n # These override the definitions on the base UserAdmin\n # that reference specific fields on auth.User.\n list_display = ('email', 'date_of_birth', 'is_admin')\n list_filter = ('is_admin',)\n fieldsets = (\n (None, {'fields': ('email', 'password')}),\n ('Personal info', {'fields': ('date_of_birth',)}),\n ('Permissions', {'fields': ('is_admin',)}),\n )\n # add_fieldsets is not a standard ModelAdmin attribute. UserAdmin\n # overrides get_fieldsets to use this attribute when creating a user.\n add_fieldsets = (\n (None, {\n 'classes': ('wide',),\n 'fields': ('email', 'date_of_birth', 'password1', 'password2')}\n ),\n )\n search_fields = ('email',)\n ordering = ('email',)\n filter_horizontal = ()\n\n# Now register the new UserAdmin...\nadmin.site.register(MyUser, UserAdmin)\n# ... and, since we're not using Django's built-in permissions,\n# unregister the Group model from admin.\nadmin.site.unregister(Group)\nFinally, specify the custom model as the default user model for your project\nusing the AUTH_USER_MODEL setting in your settings.py:
AUTH_USER_MODEL = 'customauth.MyUser'\n