Django 自带的身份验证已经足够满足大多数常见的情况，但你可能有一些需求没有被开箱即用的默认值所满足。在你的项目中定制身份验证需要了解所提供系统的哪些点是可扩展或可替换的。本文档详细介绍了如何定制认证系统。
\n当用户模型中存储的用户名和密码需要对一个不同于 Django 默认服务验证时，认证后端 提供了一个可扩展的系统。
\n你可以给你的模型 自定义权限 并且可以通过 Django 的授权系统检查。
\n你可以 扩展 默认的 User 模型，或者完全自定义一个模型进行 替换
有时候你需要连接到其他认证源——一个包含用户名及密码的源或者认证方法。
\n例如，你的公司可能已经有了一个 LDAP 配置，为每个员工存储了一个用户名和密码。如果用户在 LDAP 和基于 Django 的应用程序中分别有不同的账户，那么对于网络管理员和用户本身来说都是一件很麻烦的事情。
\n所以，为了处理这样的情况，Django 认证系统让你可以插入其他认证源。你可以覆盖 Django 默认的基于数据库的方案，也可以将默认系统与其他系统串联使用。
\n参见 认证后端参考，了解 Django 所包含的认证后端的信息。
\nBehind the scenes, Django maintains a list of "authentication backends" that it\nchecks for authentication. When somebody calls\ndjango.contrib.auth.authenticate() -- as described in How to log\na user in -- Django tries authenticating across\nall of its authentication backends. If the first authentication method fails,\nDjango tries the second one, and so on, until all backends have been attempted.
要使用的认证后端列表在 AUTHENTICATION_BACKENDS 配置中指定。这应该是一个指向知道如何验证的 Python 类的 Python 路径名列表。这些类可以是 Python 路径上的任何地方。
默认情况下，AUTHENTICATION_BACKENDS 配置为：
["django.contrib.auth.backends.ModelBackend"]\n这是基本的身份验证后端，它会检查 Django 用户数据库并查询内置权限。它不提供任何速率限制机制来防止暴力攻击。你可以在自定义身份验证后端中实现自己的速率限制机制，或者使用大多数 Web 服务器提供的机制。
\nAUTHENTICATION_BACKENDS 的顺序很重要，所以如果同一个用户名和密码在多个后端都有效，Django 会在第一个正向匹配时停止处理。
如果一个后端抛出 PermissionDenied 异常，则验证流程立马终止，Django 不会继续检查其后的后端。
认证后端是一个类，它实现了两个必要的方法：get_user(user_id) 和 authenticate(request, **credentials)，以及一组可选的与权限相关的 认证方法。
get_user 方法接收一个 user_id ——可以是用户名、数据库 ID 或其他什么，但必须是用户对象的主键——然后返回一个用户对象或 None。
authenticate 方法采用 request 参数和证书作为关键字参数。大多数情况下，它看起来像这样：
from django.contrib.auth.backends import BaseBackend\n\n\nclass MyBackend(BaseBackend):\n def authenticate(self, request, username=None, password=None):\n # Check the username/password and return a user.\n ...\n但它也可以认证一个令牌，比如：
\nfrom django.contrib.auth.backends import BaseBackend\n\n\nclass MyBackend(BaseBackend):\n def authenticate(self, request, token=None):\n # Check the token and return a user.\n ...\n无论哪种方式，authenticate() 应该检查它所得到的凭证，如果凭证有效，则返回一个与这些凭证相匹配的用户对象。如果无效，则应返回 None。
request 是一个 HttpRequest，如果没有提供给 authenticate() （将其传递给后端），则可能是 None。
Django 管理后台与 Django 的 用户对象 紧密耦合。例如，用户要访问管理后台，User.is_staff 和 User.is_active 必须为 ``True``（详情请参阅 AdminSite.has_permission()）。
处理这个问题的最佳方法是为后端存在的每个用户（例如，在你的 LDAP 目录、外部 SQL 数据库等中）创建一个 Django User 对象。你可以提前编写一个脚本来完成此操作，或者你的 authenticate 方法可以在用户首次登录时完成此操作。
这是一个示例后端，它根据在 settings.py 文件中定义的用户名和密码变量进行身份验证，并在用户首次认证时创建一个 Django User 对象。在这个示例中，创建的 Django User 对象是一个超级用户，他将拥有对管理后台的完全访问权限：
from django.conf import settings\nfrom django.contrib.auth.backends import BaseBackend\nfrom django.contrib.auth.hashers import check_password\nfrom django.contrib.auth.models import User\n\n\nclass SettingsBackend(BaseBackend):\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) # is_active defaults to True.\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要为给定的模型对象创建自定义权限，使用 permissions 模型 Meta 属性。
这个 Task 模型创建了两个自定义权限，即用户可以或不可以对 Task 实例进行的操作，具体到你的应用程序：
class Task(models.Model):\n ...\n\n class Meta:\n permissions = [\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这样做的唯一作用就是当你运行 manage.py migrate 时，创建这些额外的权限（创建权限的函数连接到 post_migrate 信号）。你的代码负责在用户试图访问应用程序提供的功能（改变任务状态或关闭任务）时检查这些权限的值。 继续上面的例子，下面检查用户是否可以关闭任务：
user.has_perm("app.close_task")\nUser 模型Link to this heading#有两种方法可以扩展默认的 User 模型，而不用替换自己的模型。如果你需要的是纯粹的行为改变，而不需要改变数据库中存储的内容，你可以基于 User 创建一个 代理模型。这允许代理模型提供的任何功能，包括默认排序、自定义管理器或自定义模型方法。
如果你希望存储与 User 相关的信息，你可以使用一个 OneToOneField 到一个包含字段的模型，以获得额外的信息。这种一对一的模型通常被称为 profile 模型，因为它可能会存储一个站点用户的非认证相关信息。例如，你可以创建一个 Employee 模型：
from django.contrib.auth.models import User\n\n\nclass Employee(models.Model):\n user = models.OneToOneField(User, on_delete=models.CASCADE)\n department = models.CharField(max_length=100)\n假设存在一个名为 Fred Smith 的员工，他既有一个 User 模型又有一个 Employee 模型，您可以使用 Django 的标准关联模型约定来访问相关信息：
\n>>> u = User.objects.get(username="fsmith")\n>>> freds_department = u.employee.department\n要将配置文件模型的字段添加到管理员的用户页面中，在你的应用程序的 admin.py 中定义一个 InlineModelAdmin （在这个例子中，我们将使用一个 StackedInline），并将其添加到一个 UserAdmin 类中，该类用 User` 类注册：
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\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\n# Define a new User admin\nclass UserAdmin(BaseUserAdmin):\n inlines = [EmployeeInline]\n\n\n# Re-register UserAdmin\nadmin.site.unregister(User)\nadmin.site.register(User, UserAdmin)\n这些 profile 模型并没有任何特殊之处——它们只是 Django 模型，恰好与用户模型有一对一的联系。因此，当用户被创建时，它们并不会自动创建，但可以用一个 django.db.models.signals.post_save 来适当地创建或更新相关模型。
使用相关模型会导致额外的查询或连接来检索相关数据。根据你的需求，包含相关字段的自定义用户模型可能是你更好的选择，然而，在你的项目应用程序中与默认用户模型的现有关系可能会证明额外的数据库负载是合理的。
\nUser 模型。Link to this heading#有些项目可能会有认证需求，而 Django 内置的 User 模型并不总是合适。例如，在一些网站上，使用电子邮件地址作为你的身份识别标记比使用用户名更有意义。
Django 允许你通过为 AUTH_USER_MODEL 配置提供一个引用自定义模型的值来覆盖默认的用户模型：
AUTH_USER_MODEL = "myapp.MyUser"\n这个点对描述了 Django 应用程序的 label （必须在您的 INSTALLED_APPS 中），以及您希望用作用户模型的 Django 模型的名称。
如果你正在启动一个新项目，可以通过继承 AbstractUser 来设置一个与默认用户模型行为相同的自定义用户模型：
from django.contrib.auth.models import AbstractUser\n\n\nclass User(AbstractUser):\n pass\n不要忘记将 AUTH_USER_MODEL 指向它。在创建任何迁移或者首次运行 manage.py migrate 之前执行这个操作。
同样的，在 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)\n在创建数据库表后更改 AUTH_USER_MODEL 是可行的，但可能会很复杂，因为它会影响外键和多对多关系等。
这个改动并不能自动完成，需要手动修复你的架构，将数据从旧的用户表移出，并有可能需要手动执行一些迁移操作。查看步骤概述，请查看 #25313。
\n由于 Django 对可交换模型的动态依赖特性的限制，AUTH_USER_MODEL 所引用的模型必须在其应用的第一次迁移中创建（通常称为 0001_initial）；否则，你会出现依赖问题。
此外，当你运行迁移时，你可能会遇到一个 CircularDependencyError，因为 Django 不会因为动态依赖而自动打破依赖循环。如果你看到这个错误，你应该通过将你的用户模型所依赖的模型移动到第二个迁移中来打破这个循环。（如果你想看看通常是怎么做的，你可以尝试做两个正常的模型，它们之间有一个 ForeignKey，看看 makemigrations 是如何解决这个循环依赖的。）
AUTH_USER_MODELLink to this heading#可重用应用不应该实现自定义用户模型。一个项目可能会使用很多应用，两个实现了自定义用户模型的可重用应用不能一起使用。如果你需要在你的应用中存储每个用户的信息，可以使用一个 ForeignKey 或 OneToOneField 到 settings.AUTH_USER_MODEL，如下所述。
User 模型Link to this heading#如果你直接引用 User （例如，通过在一个外键中引用它），你的代码将无法在 AUTH_USER_MODEL 配置已被更改为不同用户模型的项目中工作。
与其直接引用 User，不如使用 django.contrib.auth.get_user_model() 引用用户模型。这个方法将返回当前活动的用户模型——如果指定了自定义用户模型，则返回自定义用户模型，否则返回 User。
在定义用户模型的外键或多对多关系时，应使用 AUTH_USER_MODEL 配置指定自定义模型。例如：
from django.conf import settings\nfrom django.db import models\n\n\nclass Article(models.Model):\n author = models.ForeignKey(\n settings.AUTH_USER_MODEL,\n on_delete=models.CASCADE,\n )\n连接用户模型发送的信号时，应使用 AUTH_USER_MODEL 配置指定自定义模型。例如：
from django.conf import settings\nfrom django.db.models.signals import post_save\n\n\ndef post_save_receiver(sender, instance, created, **kwargs):\n pass\n\n\npost_save.connect(post_save_receiver, sender=settings.AUTH_USER_MODEL)\n一般来说，在导入时执行的代码中，用 AUTH_USER_MODEL 配置来引用用户模型是最简单的，不过，也可以在 Django 导入模型时调用 get_user_model()，所以可以使用 models.ForeignKey(get_user_model()，...)。
例如，如果你的应用是用多个用户模型进行测试的，使用 @override_settings(AUTH_USER_MODEL=...)，并且你把 get_user_model() 的结果缓存在模块级变量中，你可能需要监听 setting_changed 信号来清除缓存。例如：
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\n@receiver(setting_changed)\ndef user_model_swapped(*, setting, **kwargs):\n if setting == "AUTH_USER_MODEL":\n apps.clear_cache()\n from myapp import some_module\n\n some_module.UserModel = get_user_model()\n当你用自定义用户模型开始你的项目时，请停下来考虑一下这是否是你项目的正确选择。
\n将所有用户相关信息保存在一个模型中，就不需要额外的或更复杂的数据库查询来检索相关模型。另一方面，在一个与你的自定义用户模型有关系的模型中存储特定应用的用户信息可能更合适。这允许每个应用程序指定自己的用户数据需求，而不会有潜在的冲突或破坏其他应用程序的假设。这也意味着，你会让你的用户模型尽可能的简单，专注于认证，并遵循 Django 期望自定义用户模型满足的最低要求。
\n如果你使用默认的认证后端，那么你的模型必须有一个可用于识别目的的唯一字段。这可以是一个用户名，一个电子邮件地址，或任何其他独特的属性。如果你使用可以支持的自定义认证后端，则允许使用非唯一的用户名字段。
\n最简单的方法是继承 AbstractBaseUser。 AbstractBaseUser 提供了用户模型的核心实现，包括哈希密码和令牌化密码重置。然后你必须提供一些关键的实现细节。
一个字符串，描述了在用户模型上用作唯一标识符的字段的名称。通常，这将是某种用户名，但它也可以是电子邮件地址或任何其他唯一标识符。该字段 必须 是唯一的（例如，在其定义中设置了 unique=True），除非您使用可以支持非唯一用户名的自定义身份验证后端。
接下来的样例中，identifier 字段将被用作识别字段：
class MyUser(AbstractBaseUser):\n identifier = models.CharField(max_length=40, unique=True)\n ...\n USERNAME_FIELD = "identifier"\n用来描述用户模型中的邮件字段，该值通过 get_email_field_name() 返回。
在通过 createsuperuser 管理命令创建用户时，将提示用户输入的字段名称列表。用户将被提示为每个字段提供一个值。它必须包括 blank 为 False 或未定义的任何字段，并可能包括你希望在交互式创建用户时提示的其他字段。REQUIRED_FIELDS 在 Django 的其他部分没有效果，比如在管理中创建用户。
例如，这里是一个用户模型的部分定义，它定义了两个必填字段——出生日期和身高：
\nclass MyUser(AbstractBaseUser):\n ...\n date_of_birth = models.DateField()\n height = models.FloatField()\n ...\n REQUIRED_FIELDS = ["date_of_birth", "height"]\nA 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.
可选项。用户的较长身份标识符，比如用户的全名。如果已经设置，则会与用户名一起出现在 django.contrib.admin 中。
可选项。用户较短的身份标识符，比如用户的名。如果已经设置，它会在 django.contrib.admin 页面头部的欢迎词中替换用户名。
AbstractBaseUser 的任何子类都可以使用下面的属性和方法：
返回 USERNAME_FIELD 指定的字段的值。
通过调用 normalize_username() 来规范化用户名。 如果重写此方法，必须调用 super() 来保持规范化。
返回由 EMAIL_FIELD 属性指定的电子邮件字段的名称。 如果未指定 EMAIL_FIELD ，则默认为 'email' 。
应用 NFKC Unicode 规范化用户名，使得不同 Unicode 码位视觉相同字符视为相同。
\n只读属性，始终返回 True （匿名用户 AnonymousUser.is_authenticated 始终返回 False ）。这是一种判断用户是否已通过身份验证的方法。这并不意味着任何权限，也不会检查用户是否处于活动状态或是否具有有效会话。即使通常您会根据 request.user 检查这个属性，以确定它是否被 AuthenticationMiddleware 填充（表示当前登录的用户），但是你应该知道该属性对于任何 User 实例都返回 True。
只读属性总是 False。这个属性用于区分 User 和 AnonymousUser 对象。通常情况下， is_authenticated 应该置于只读。
设置用户密码，谨慎保存密码哈希。不可保存 AbstractBaseUser 的对象。
When the raw_password is None, the password will be set to an\nunusable password, as if\nset_unusable_password()\nwere used.
异步版本：acheck_password()
如果给定的原始字符串是用户的正确密码，返回 True。（在进行比较时，这将处理密码散列。）
Marks the user as having no password set. This isn't the same as\nhaving a blank string for a password.\ncheck_password() for\nthis user will never return True. Doesn't save the\nAbstractBaseUser object.
如果你的应用程序的身份验证是针对现有的外部源（如 LDAP 目录）进行的，你可能需要这个功能。
\nReturns False if\nset_unusable_password()\nhas been called for this user.
返回密码字段的 HMAC。用于 session-invalidation-onpassword-change。
\n使用 SECRET_KEY_FALLBACKS 生成密码字段的 HMAC。被 get_user() 使用。
AbstractUser 是 AbstractBaseUser 的子类。
通过调用 BaseUserManager.normalize_email() 来规范化邮件。如果你覆盖了这个方法，一定要调用 super() 来保留规范化。
你也该为你的用户模型定义一个自定义管理器。如果你的用户模型定义了和默认用户相同的 username, email, is_staff, is_active, is_superuser, last_login, 和 ``date_joined`等字段，你可以安装 UserManager ；但是，如果你的用户模型还定义了其他字段，那么就需要定义一个自定义管理器，它扩展了 BaseUserManager ，提供了两个额外的方法：
create_user() 的原型应该接受username字段，加上其他所有必须的字段作为参数。举例，如果你的用户模型使用 email 作为用户名字段，date_of_birth 字段作为必填字段，那么 create_user 应该如下定义：
def create_user(self, email, date_of_birth, password=None):\n # create user here\n ...\ncreate_superuser() 的原型应该接受username字段，加上其他所有必须的字段作为参数。举例，如果你的用户模型使用 email 作为用户名字段，date_of_birth 字段作为必填字段，那么 create_superuser 应该如下定义：
def create_superuser(self, email, date_of_birth, password=None):\n # create superuser here\n ...\n对于 USERNAME_FIELD 或 REQUIRED_FIELDS 中的 ForeignKey ，这些方法接收现有实例的:attr:~.ForeignKey.to_field （默认为 primary_key ）的值。
BaseUserManager 提供以下实用方法：
通过降低电子邮件地址的域部分来规范化电子邮件地址。
\nAsynchronous version: aget_by_natural_key()
使用 USERNAME_FIELD 指定的字段的内容检索用户实例。
如果您对 Django 的 User 模型完全满意，但想要添加一些额外的个人资料信息，您可以子类化 django.contrib.auth.models.AbstractUser 并添加您自定义的个人资料字段，尽管我们建议按照 指定自定义用户模型 中描述的方式使用一个单独的模型。AbstractUser 提供了默认 User 的完整实现作为一个 抽象模型。
Django的内置 :ref:`forms ` 和 :ref:`views ` 对他们正在使用的用户模型做了一些假设。
\n以下表单与 AbstractBaseUser 的任何子类兼容：
AuthenticationForm: 使用 USERNAME_FIELD 指定的username字段。
以下表单对用户模型进行了假设，如果满足这些假设，则可以按原样使用:
\nPasswordResetForm ：假设用户模型有一个字段存储用户的电子邮件地址，其名称由 get_email_field_name() 返回（默认为电子邮件），这个方法用来标识用户，以及名为``is_active``的布尔字段，防止非活动用户重置密码。
最后，下面的表单和 User 绑定，如果需要和自定义的用户模型一起使用，则需要重写或者扩展。
如果自定义的用户模型是 AbstractUser 的子类，则可以使用下面的方式来扩展表单：
from django.contrib.auth.forms import UserCreationForm\nfrom myapp.models import CustomUser\n\n\nclass CustomUserCreationForm(UserCreationForm):\n class Meta(UserCreationForm.Meta):\n model = CustomUser\n fields = UserCreationForm.Meta.fields + ("custom_field",)\ndjango.contrib.adminLink to this heading#如果你希望自定义的用户模型也与管理后台一起使用，那么你的用户模型必须定义一些额外的属性和方法。这些方法允许管理员控制用户对管理后台内容的访问：
\n如果允许用户有访问 admin 页面就返回 True。
返回``True``，如果该用户的账号当前是激活状态
\n如果用户有指定的权限，则返回 True 。如果提供了参数 obj ，则需要对指定的对象实例进行权限检查。
如果用户有权限访问指定 app 里的模型，那么返回 True 。
你也需要在 admin 文件里注册自定义的用户模型。如果自定义的用户模型扩展了 django.contrib.auth.models.AbstractUser ，你可以直接使用Django已有的类 django.contrib.auth.admin.UserAdmin 。如果你的用户模型扩展了 AbstractBaseUser ，你将需要定义一个自定义的类 ModelAdmin 。不管怎样，你都将需要重写任何引用 django.contrib.auth.models.AbstractUser 上的字段的定义，这些字段不在你自定义的用户类中。
为了便于将Django的权限框架引入到你自己的用户类中，Django提供了 PermissionsMixin 。这是一个抽象模型，可以包含在用户模型的类层次结构中，为你提供支持Django权限模型所需的所有方法和数据库字段。
PermissionsMixin 提供下列方法和属性：
布尔值。指定该用户拥有所有权限，而不用一个个开启权限。
\n返回用户本身就自带的权限字符串集合。
\n如果传入了 obj ，则只返回指定对象的用户权限。
返回用户拥有权限的字符串集合，从用户所属组的权限中获取。
\n如果传入 obj 参数，则只返回指定对象所属组的权限。
返回用户拥有权限的字符串集合，同时从用户所属组及用户本身的权限中获取。
\n如果传入 ``obj``参数，则只返回指定对象和所属组的权限。
\n如果用户具有指定的权限，则返回 True ，其中 perm 的格式为 "<app label>.<permission codename>" (see permissions)。如果 User.is_active 和 is_superuser 都为 True，则这个方法一直返回 True 。
如果传入 obj 参数，则这个方法不会检查该模型权限，而只会检查这个出传入对象的权限。
如果用户具有指定权限列表里的每个权限，则返回 True ，其中perm的格式为 "<app label>.<permission codename>" 。如果 User.is_active 和 is_superuser 都返回 True ，则这个方法一直返回 True 。
如果传入参数 obj ，则这个方法不会检查指定的权限列表，只检查指定对象的权限。
如果用户拥有所给的 Django app 标签 (the Django app label) 里的任何权限，则会返回 True 。如果 User.is_active 和 is_superuser 都为 True ，则该方法一直返回 True 。
自定义用户模型的一个限制是安装自定义用户模型将破坏任何扩展 User 的代理模型。代理模型必须基于具体的基类；通过定义自定义用户模型，你就移除了Django可靠地识别基类的功能。
如果你的项目正在使用代理模型，你必须修改扩展用户模型的代理，或者把代理的行为都合并到 User 子类里去。
这里是一个兼容admin的自定义的用户app的例子。这个用户模型使用 email 地址作为username，并且生日是必填字段；除了用户账户上的 admin flag之外，它本身不提供权限检查。除用户创建的表单外，此模型和所有内置的身份验证表单和视图兼容。此例只是说明了大多数组件如何协同工作，不要直接复制到生产环境里。
这段代码将一直存在于 models.py 文件中，用于自定义身份验证 app:
from django.db import models\nfrom django.contrib.auth.models import BaseUserManager, AbstractBaseUser\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=None):\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\n然后，在 Django 管理后台里注册这个用户模型，下面这些代码必须在 app 的 admin.py 文件里：
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\nfrom django.core.exceptions import ValidationError\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\n password1 = forms.CharField(label="Password", widget=forms.PasswordInput)\n password2 = forms.CharField(\n label="Password confirmation", widget=forms.PasswordInput\n )\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 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 disabled password hash display field.\n """\n\n password = ReadOnlyPasswordHashField()\n\n class Meta:\n model = MyUser\n fields = ["email", "password", "date_of_birth", "is_active", "is_admin"]\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 (\n None,\n {\n "classes": ["wide"],\n "fields": ["email", "date_of_birth", "password1", "password2"],\n },\n ),\n ]\n search_fields = ["email"]\n ordering = ["email"]\n filter_horizontal = []\n\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)\n最后，在项目配置文件中的 AUTH_USER_MODEL 里指定自定义的用户模型为默认的用户模型。
AUTH_USER_MODEL = "customauth.MyUser"\nTo optimize performance when called from an async context authentication,\nbackends can implement async versions of each function - aget_user(user_id)\nand aauthenticate(request, **credentials). When an authentication backend\nextends BaseBackend and async versions of these functions are not provided,\nthey will be automatically synthesized with sync_to_async. This has\nperformance penalties.
While an async interface is optional, a synchronous interface is always\nrequired. There is no automatic synthesis for a synchronous interface if an\nasync interface is implemented.
\nDjango's out-of-the-box authentication backends have native async support. If\nthese native backends are extended take special care to make sure the async\nversions of modified functions are modified as well.
\n