本文档介绍了 Django 验证系统在默认配置下的使用方法。默认配置满足最常见的项目需求，可以处理相当多的任务，还有一个安全的密码和权限实现。对于验证需求与默认配置不同的项目，Django 支持对身份验证进行扩展和定制。
\nDjango 验证同时提供身份验证和授权，通常称为身份验证系统，因为这些功能在某种程度上是耦合的。
\nUser 对象Link to this heading#用户对象是认证系统的核心。它通常代表了与你的站点交互的人员，并用于允许诸如限制访问、注册用户配置文件、将内容与创建者关联等功能。Django 的认证框架中用户只有一个类，例如 “超级管理员”或“普通管理员”只是具有特殊属性集的用户对象，而不是用户对象的不同类。
\n默认用户的主要属性是：
\n请参阅完整的API文档 full API documentation 以获得完整的参考，下面的文档主要以任务为导向。
创建用户最直接的方法是使用包含 create_user() 的函数：
>>> from django.contrib.auth.models import User\n>>> user = User.objects.create_user('john', 'lennon@thebeatles.com', 'johnpassword')\n\n# At this point, user is a User object that has already been saved\n# to the database. You can continue to change its attributes\n# if you want to change other fields.\n>>> user.last_name = 'Lennon'\n>>> user.save()\n如果你已经安装了 Django admin 管理后台，你也可以在 admin 管理后台交互式地创建用户:ref:create users interactively <auth-admin> 。
\n通过命令行 createsuperuser 创建超级管理员：
$ python manage.py createsuperuser --username=joe --email=joe@example.com\n你将会被提示输入密码，完成之后，超级管理员就被创建成功了。如果你没有填写参数 --username <createsuperuser --username> ` or :option:--email <createsuperuser --email>` ，也将会被提示输入这些值。
Django 不会在用户模型里保存原始(明文)密码，而只会存储哈希值(请参阅文档 如何管理密码 documentation of how passwords are managed ) 。因此，请不要试图直接操作用户的密码，这就是创建用户需要辅助函数的原因。
\n更改一个用户的密码，你有几个选择：
\nmanage.py changepassword *username* 提供了在命令行修改用户密码的方法。它会提示你输入两次新密码，如果操作成功，新密码就立刻生效。如果你没有提供参数 username ，那么将会尝试修改当前系统用户的密码。
你也可以在代码里修改密码，使用 set_password():
>>> from django.contrib.auth.models import User\n>>> u = User.objects.get(username='john')\n>>> u.set_password('new password')\n>>> u.save()\n如果你已经按照了 Django admin 管理后台，你也可以在管理后台页面修改密码（请参阅 :ref:`authentication system's admin pages ` ）。
\nDjango 还提供了允许用户自行修改密码的 :ref:`views ` 和 :ref:`forms ` 。
\n修改密码将会注销用户的所有会话。查看详情请参阅 Session invalidation on password change 。
\n使用 authenticate() 来验证用户。它使用 username 和 password 作为参数来验证，对每个身份验证后端( authentication backend ` )进行检查。如果后端验证有效，则返回一个 :class:`~django.contrib.auth.models.User 对象。如果后端引发 PermissionDenied 错误，将返回 None。举例：
from django.contrib.auth import authenticate\nuser = authenticate(username='john', password='secret')\nif user is not None:\n # A backend authenticated the credentials\nelse:\n # No backend authenticated the credentials\nrequest 是可选的 HttpRequest ，它在身份验证后端上的 authenticate() 方法来传递。
Django 使用 sessions 和中间件将身份验证系统挂接到请求对象中。
\n它们在每次请求中都会提供 request.user 属性。如果当前没有用户登录，这个属性将会被设置为 AnonymousUser ，否则将会被设置为 User 实例。
你可以使用 is_authenticated 区分两者，例如：
if request.user.is_authenticated:\n # Do something for authenticated users.\n ...\nelse:\n # Do something for anonymous users.\n ...\n如果有一个已验证的用户想附加到当前会话(session)中，将通过 login() 函数完成。
要在视图中让用户登录，使用 login() 。它需要 HttpRequest 对象和 User 对象。通过 Django 的 session 框架， login() 会在 session 中保存用户的ID。
注意，在匿名会话期间设置的任何数据都会在用户登录后保留在会话中。
\n这个例子展示了如何使用 authenticate() 和 login(): ：
from django.contrib.auth import authenticate, login\n\ndef my_view(request):\n username = request.POST['username']\n password = request.POST['password']\n user = authenticate(request, username=username, password=password)\n if user is not None:\n login(request, user)\n # Redirect to a success page.\n ...\n else:\n # Return an 'invalid login' error message.\n ...\n当用户登录时，用户 ID 和用于身份验证的后端会被保存在用户会话中。允许相同的 authentication backend 在未来的请求中获取用户详情。选择要在会话中保存的验证后端如下：
\n使用提供了的可选 backend 参数值。
使用 user.backend 的值。允许配对 authenticate() 和 login() ：当返回用户对象时 authenticate() 设置 user.backend 属性。
使用 AUTHENTICATION_BACKENDS 存在的 backend 。
否则，抛出一个异常。
在1和2中，backend 参数和 user.backend 属性应该是完整的导入路径（像 AUTHENTICATION_BACKENDS 里的路径一样），而不是真实的后端类。
如果已经通过 django.contrib.auth.login() 登录的用户想退出登录，可以在视图中使用 django.contrib.auth.logout() 。需要传入 HttpRequest 对象，并且该函数不会返回值。例如：
from django.contrib.auth import logout\n\ndef logout_view(request):\n logout(request)\n # Redirect to a success page.\n注意，如果用户未登录，logout() 不会报错。
调用 logout() 后，当前请求的会话数据会被全部清除。这是为了防止其他使用同一个浏览器的用户访问前一名用户的会话数据。如果想在登出后立即向用户提供的会话中放入任何内容，请在调用 django.contrib.auth.logout() 之后执行此操作。
限制访问页面最简单的办法就是检查 request.user.is_authenticated 并重定向到登录页面。
from django.conf import settings\nfrom django.shortcuts import redirect\n\ndef my_view(request):\n if not request.user.is_authenticated:\n return redirect('%s?next=%s' % (settings.LOGIN_URL, request.path))\n # ...\n或者显示一个错误信息：
\nfrom django.shortcuts import render\n\ndef my_view(request):\n if not request.user.is_authenticated:\n return render(request, 'myapp/login_error.html')\n # ...\nlogin_required 装饰器Link to this heading#作为快捷方式，你可以使用 login_required() 装饰器:
from django.contrib.auth.decorators import login_required\n\n@login_required\ndef my_view(request):\n ...\nlogin_required() 会执行以下操作：
如果用户没有登录，会重定向到 settings.LOGIN_URL ，并传递绝对路径到查询字符串中。例如： /accounts/login/?next=/polls/3/ 。
如果用户已经登录，则正常执行视图。视图里的代码可以假设用户已经登录了。
默认情况下，成功验证时用户跳转的路径保存在名为 "next" 的查询字符串参数中。如果你希望这个参数使用不同名称，请在 login_required() 中传递可选参数 redirect_field_name ：
from django.contrib.auth.decorators import login_required\n\n@login_required(redirect_field_name='my_redirect_field')\ndef my_view(request):\n ...\n注意，如果你提供了 redirect_field_name 值，则很可能也需要自定义登录模板，因为存储重定向路径的模板上下文变量使用的是 redirect_field_name 值，而不是 "next" （默认情况下）。
login_required() 也有可选参数 login_url 。例如：
from django.contrib.auth.decorators import login_required\n\n@login_required(login_url='/accounts/login/')\ndef my_view(request):\n ...\n注意，如果你没有指定参数 login_url ，你需要确认 settings.LOGIN_URL 和登录视图是正确关联的。例如，使用默认方式，在 URL 配置文件里添加下面这行：
from django.contrib.auth import views as auth_views\n\npath('accounts/login/', auth_views.LoginView.as_view()),\nsettings.LOGIN_URL 也接受视图方法名和 named URL patterns 。这样你可以在 URLconf 里自由地重新映射你的登录视图，而不需更新配置文件。
LoginRequired MixinLink to this heading#使用基于类的视图时，可以使用 LoginRequiredMixin 实现和 login_required 相同的行为。这个 Mixin 应该在继承列表中最左侧的位置。
如果一个视图使用 Mixin ，那么未经验证用户的所有请求都会被重定向到登录页面或者显示 HTTP 403 Forbidden 错误，这取决于 raise_exception 参数。
你可以设置 AccessMixin 的任何参数来自定义未验证用户的处理：
from django.contrib.auth.mixins import LoginRequiredMixin\n\nclass MyView(LoginRequiredMixin, View):\n login_url = '/login/'\n redirect_field_name = 'redirect_to'\n根据某些权限或者其他测试来限制访问，你基本上可以执行和上一节所述同样的操作。
\n最简单的方法是在视图里直接对 request.user 进行测试。举例，这个视图检查用户是否拥有特定域名的邮箱，否则会重定向到登录页：
from django.shortcuts import redirect\n\ndef my_view(request):\n if not request.user.email.endswith('@example.com'):\n return redirect('/login/?next=%s' % request.path)\n # ...\n作为快捷方式，你可以方便的调用 user_passes_test 装饰器，当调用返回 False 时会执行重定向。
from django.contrib.auth.decorators import user_passes_test\n\ndef email_check(user):\n return user.email.endswith('@example.com')\n\n@user_passes_test(email_check)\ndef my_view(request):\n ...\nuser_passes_test() 接受一个必要的参数：一个带有:class:~django.contrib.auth.models.User 对象的调用，如果允许用户访问这个页面，则返回 True 。注意，user_passes_test() 不会自动检查用户是否匿名。
user_passes_test() 可以传递两个可选参数：
login_url允许你指定用户没有通过测试时跳转的地址。它可能是一个登录页面，如果你没指定，默认是 settings.LOGIN_URL 。
redirect_field_name与 login_required() 相同。如果你想把没通过检查的用户重定向到没有 "next page" 的非登录页面时，把它设置为 None ，这样它会在 URL 中移除。
例如:
\n@user_passes_test(email_check, login_url='/login/')\ndef my_view(request):\n ...\n使用基于类的视图时，可以使用 UserPassesTestMixin 执行此操作。
你必须覆盖类方法 test_func() 以提供执行的测试。此外，还可以设置 AccessMixin 的任何参数来自定义处理未授权用户：
from django.contrib.auth.mixins import UserPassesTestMixin\n\nclass MyView(UserPassesTestMixin, View):\n\n def test_func(self):\n return self.request.user.email.endswith('@example.com')\n你也可以覆盖 get_test_func() 方法，以使 mixin 对其检查使用不同名称的函数（而不是 test_func() ）。
permission_required 装饰器Link to this heading#It's a relatively common task to check whether a user has a particular\npermission. For that reason, Django provides a shortcut for that case: the\npermission_required() decorator.:
from django.contrib.auth.decorators import permission_required\n\n@permission_required('polls.can_vote')\ndef my_view(request):\n ...\nJust like the has_perm() method,\npermission names take the form "<app label>.<permission codename>"\n(i.e. polls.can_vote for a permission on a model in the polls\napplication).
The decorator may also take an iterable of permissions, in which case the\nuser must have all of the permissions in order to access the view.
\nNote that permission_required()\nalso takes an optional login_url parameter:
from django.contrib.auth.decorators import permission_required\n\n@permission_required('polls.can_vote', login_url='/loginpage/')\ndef my_view(request):\n ...\nAs in the login_required() decorator,\nlogin_url defaults to settings.LOGIN_URL.
If the raise_exception parameter is given, the decorator will raise\nPermissionDenied, prompting the 403\n(HTTP Forbidden) view instead of redirecting to the\nlogin page.
If you want to use raise_exception but also give your users a chance to\nlogin first, you can add the\nlogin_required() decorator:
from django.contrib.auth.decorators import login_required, permission_required\n\n@login_required\n@permission_required('polls.can_vote', raise_exception=True)\ndef my_view(request):\n ...\nThis also avoids a redirect loop when LoginView's\nredirect_authenticated_user=True and the logged-in user doesn't have\nall of the required permissions.
PermissionRequiredMixin mixinLink to this heading#To apply permission checks to class-based views, you can use the PermissionRequiredMixin:
This mixin, just like the permission_required\ndecorator, checks whether the user accessing a view has all given\npermissions. You should specify the permission (or an iterable of\npermissions) using the permission_required parameter:
from django.contrib.auth.mixins import PermissionRequiredMixin\n\nclass MyView(PermissionRequiredMixin, View):\n permission_required = 'polls.can_vote'\n # Or multiple of permissions:\n permission_required = ('polls.can_open', 'polls.can_edit')\nYou can set any of the parameters of\nAccessMixin to customize the handling\nof unauthorized users.
你可能同样需要重写这些方法：
\nReturns an iterable of permission names used by the mixin. Defaults to\nthe permission_required attribute, converted to a tuple if\nnecessary.
Returns a boolean denoting whether the current user has permission to\nexecute the decorated view. By default, this returns the result of\ncalling has_perms() with the\nlist of permissions returned by get_permission_required().
Django provides several views that you can use for handling login, logout, and\npassword management. These make use of the stock auth forms but you can pass in your own forms as well.
\nDjango provides no default template for the authentication views. You should\ncreate your own templates for the views you want to use. The template context\nis documented in each view, see All authentication views.
\nThere are different methods to implement these views in your project. The\neasiest way is to include the provided URLconf in django.contrib.auth.urls\nin your own URLconf, for example:
urlpatterns = [\n path('accounts/', include('django.contrib.auth.urls')),\n]\nThis will include the following URL patterns:
\naccounts/login/ [name='login']\naccounts/logout/ [name='logout']\naccounts/password_change/ [name='password_change']\naccounts/password_change/done/ [name='password_change_done']\naccounts/password_reset/ [name='password_reset']\naccounts/password_reset/done/ [name='password_reset_done']\naccounts/reset/<uidb64>/<token>/ [name='password_reset_confirm']\naccounts/reset/done/ [name='password_reset_complete']\nThe views provide a URL name for easier reference. See the URL\ndocumentation for details on using named URL patterns.
\nIf you want more control over your URLs, you can reference a specific view in\nyour URLconf:
\nfrom django.contrib.auth import views as auth_views\n\nurlpatterns = [\n path('change-password/', auth_views.PasswordChangeView.as_view()),\n]\nThe views have optional arguments you can use to alter the behavior of the\nview. For example, if you want to change the template name a view uses, you can\nprovide the template_name argument. A way to do this is to provide keyword\narguments in the URLconf, these will be passed on to the view. For example:
urlpatterns = [\n path(\n 'change-password/',\n auth_views.PasswordChangeView.as_view(template_name='change-password.html'),\n ),\n]\nAll views are class-based, which allows\nyou to easily customize them by subclassing.
\nThis is a list with all the views django.contrib.auth provides. For\nimplementation details see Using the views.
URL name: login
See the URL documentation for details on using\nnamed URL patterns.
\nAttributes:
\ntemplate_name: The name of a template to display for the view used to\nlog the user in. Defaults to registration/login.html.
redirect_field_name: The name of a GET field containing the\nURL to redirect to after login. Defaults to next.
authentication_form: A callable (typically just a form class) to\nuse for authentication. Defaults to\nAuthenticationForm.
extra_context: A dictionary of context data that will be added to the\ndefault context data passed to the template.
redirect_authenticated_user: A boolean that controls whether or not\nauthenticated users accessing the login page will be redirected as if\nthey had just successfully logged in. Defaults to False.
success_url_allowed_hosts: A set of hosts, in addition to\nrequest.get_host(), that are\nsafe for redirecting after login. Defaults to an empty set.
Here's what LoginView does:
If called via GET, it displays a login form that POSTs to the\nsame URL. More on this in a bit.
If called via POST with user submitted credentials, it tries to log\nthe user in. If login is successful, the view redirects to the URL\nspecified in next. If next isn't provided, it redirects to\nsettings.LOGIN_REDIRECT_URL (which\ndefaults to /accounts/profile/). If login isn't successful, it\nredisplays the login form.
It's your responsibility to provide the html for the login template\n, called registration/login.html by default. This template gets passed\nfour template context variables:
form: A Form object representing the\nAuthenticationForm.
next: The URL to redirect to after successful login. This may\ncontain a query string, too.
site: The current Site,\naccording to the SITE_ID setting. If you don't have the\nsite framework installed, this will be set to an instance of\nRequestSite, which derives the\nsite name and domain from the current\nHttpRequest.
site_name: An alias for site.name. If you don't have the site\nframework installed, this will be set to the value of\nrequest.META['SERVER_NAME'].\nFor more on sites, see The "sites" framework.
If you'd prefer not to call the template registration/login.html,\nyou can pass the template_name parameter via the extra arguments to\nthe as_view method in your URLconf. For example, this URLconf line would\nuse myapp/login.html instead:
path('accounts/login/', auth_views.LoginView.as_view(template_name='myapp/login.html')),\nYou can also specify the name of the GET field which contains the URL\nto redirect to after login using redirect_field_name. By default, the\nfield is called next.
Here's a sample registration/login.html template you can use as a\nstarting point. It assumes you have a base.html template that\ndefines a content block:
{% extends "base.html" %}\n\n{% block content %}\n\n{% if form.errors %}\n<p>Your username and password didn't match. Please try again.</p>\n{% endif %}\n\n{% if next %}\n {% if user.is_authenticated %}\n <p>Your account doesn't have access to this page. To proceed,\n please login with an account that has access.</p>\n {% else %}\n <p>Please login to see this page.</p>\n {% endif %}\n{% endif %}\n\n<form method="post" action="{% url 'login' %}">\n{% csrf_token %}\n<table>\n<tr>\n <td>{{ form.username.label_tag }}</td>\n <td>{{ form.username }}</td>\n</tr>\n<tr>\n <td>{{ form.password.label_tag }}</td>\n <td>{{ form.password }}</td>\n</tr>\n</table>\n\n<input type="submit" value="login">\n<input type="hidden" name="next" value="{{ next }}">\n</form>\n\n{# Assumes you setup the password_reset view in your URLconf #}\n<p><a href="{% url 'password_reset' %}">Lost password?</a></p>\n\n{% endblock %}\nIf you have customized authentication (see Customizing Authentication) you can use a custom authentication form by\nsetting the authentication_form attribute. This form must accept a\nrequest keyword argument in its __init__() method and provide a\nget_user() method which returns the authenticated user object (this\nmethod is only ever called after successful form validation).
Logs a user out.
\nURL name: logout
Attributes:
\nnext_page: The URL to redirect to after logout. Defaults to\nsettings.LOGOUT_REDIRECT_URL.
template_name: The full name of a template to display after\nlogging the user out. Defaults to registration/logged_out.html.
redirect_field_name: The name of a GET field containing the\nURL to redirect to after log out. Defaults to next. Overrides the\nnext_page URL if the given GET parameter is passed.
extra_context: A dictionary of context data that will be added to the\ndefault context data passed to the template.
success_url_allowed_hosts: A set of hosts, in addition to\nrequest.get_host(), that are\nsafe for redirecting after logout. Defaults to an empty set.
Template context:
\ntitle: The string "Logged out", localized.
site: The current Site,\naccording to the SITE_ID setting. If you don't have the\nsite framework installed, this will be set to an instance of\nRequestSite, which derives the\nsite name and domain from the current\nHttpRequest.
site_name: An alias for site.name. If you don't have the site\nframework installed, this will be set to the value of\nrequest.META['SERVER_NAME'].\nFor more on sites, see The "sites" framework.
Logs a user out, then redirects to the login page.
\nURL name: No default URL provided
\nOptional arguments:
\nlogin_url: The URL of the login page to redirect to.\nDefaults to settings.LOGIN_URL if not supplied.
URL name: password_change
Allows a user to change their password.
\nAttributes:
\ntemplate_name: The full name of a template to use for\ndisplaying the password change form. Defaults to\nregistration/password_change_form.html if not supplied.
success_url: The URL to redirect to after a successful password\nchange.
form_class: A custom "change password" form which must accept a\nuser keyword argument. The form is responsible for actually changing\nthe user's password. Defaults to\nPasswordChangeForm.
extra_context: A dictionary of context data that will be added to the\ndefault context data passed to the template.
Template context:
\nform: The password change form (see form_class above).
URL name: password_change_done
The page shown after a user has changed their password.
\nAttributes:
\ntemplate_name: The full name of a template to use.\nDefaults to registration/password_change_done.html if not\nsupplied.
extra_context: A dictionary of context data that will be added to the\ndefault context data passed to the template.
URL name: password_reset
Allows a user to reset their password by generating a one-time use link\nthat can be used to reset the password, and sending that link to the\nuser's registered email address.
\nIf the email address provided does not exist in the system, this view\nwon't send an email, but the user won't receive any error message either.\nThis prevents information leaking to potential attackers. If you want to\nprovide an error message in this case, you can subclass\nPasswordResetForm and use the\nform_class attribute.
Users flagged with an unusable password (see\nset_unusable_password() aren't\nallowed to request a password reset to prevent misuse when using an\nexternal authentication source like LDAP. Note that they won't receive any\nerror message since this would expose their account's existence but no\nmail will be sent either.
Attributes:
\ntemplate_name: The full name of a template to use for\ndisplaying the password reset form. Defaults to\nregistration/password_reset_form.html if not supplied.
form_class: Form that will be used to get the email of\nthe user to reset the password for. Defaults to\nPasswordResetForm.
email_template_name: The full name of a template to use for\ngenerating the email with the reset password link. Defaults to\nregistration/password_reset_email.html if not supplied.
subject_template_name: The full name of a template to use for\nthe subject of the email with the reset password link. Defaults\nto registration/password_reset_subject.txt if not supplied.
token_generator: Instance of the class to check the one time link.\nThis will default to default_token_generator, it's an instance of\ndjango.contrib.auth.tokens.PasswordResetTokenGenerator.
success_url: The URL to redirect to after a successful password reset\nrequest.
from_email: A valid email address. By default Django uses\nthe DEFAULT_FROM_EMAIL.
extra_context: A dictionary of context data that will be added to the\ndefault context data passed to the template.
html_email_template_name: The full name of a template to use\nfor generating a text/html multipart email with the password reset\nlink. By default, HTML email is not sent.
extra_email_context: A dictionary of context data that will be\navailable in the email template.
Template context:
\nform: The form (see form_class above) for resetting the user's\npassword.
Email template context:
\nemail: An alias for user.email
user: The current User,\naccording to the email form field. Only active users are able to\nreset their passwords (User.is_active is True).
site_name: An alias for site.name. If you don't have the site\nframework installed, this will be set to the value of\nrequest.META['SERVER_NAME'].\nFor more on sites, see The "sites" framework.
domain: An alias for site.domain. If you don't have the site\nframework installed, this will be set to the value of\nrequest.get_host().
protocol: http or https
uid: The user's primary key encoded in base 64.
token: Token to check that the reset link is valid.
Sample registration/password_reset_email.html (email body template):
Someone asked for password reset for email {{ email }}. Follow the link below:\n{{ protocol}}://{{ domain }}{% url 'password_reset_confirm' uidb64=uid token=token %}\nThe same template context is used for subject template. Subject must be\nsingle line plain text string.
\nURL name: password_reset_done
The page shown after a user has been emailed a link to reset their\npassword. This view is called by default if the PasswordResetView\ndoesn't have an explicit success_url URL set.
Attributes:
\ntemplate_name: The full name of a template to use.\nDefaults to registration/password_reset_done.html if not\nsupplied.
extra_context: A dictionary of context data that will be added to the\ndefault context data passed to the template.
URL name: password_reset_confirm
Presents a form for entering a new password.
\nKeyword arguments from the URL:
\nuidb64: The user's id encoded in base 64.
token: Token to check that the password is valid.
Attributes:
\ntemplate_name: The full name of a template to display the confirm\npassword view. Default value is\nregistration/password_reset_confirm.html.
token_generator: Instance of the class to check the password. This\nwill default to default_token_generator, it's an instance of\ndjango.contrib.auth.tokens.PasswordResetTokenGenerator.
post_reset_login: A boolean indicating if the user should be\nautomatically authenticated after a successful password reset. Defaults\nto False.
post_reset_login_backend: A dotted path to the authentication\nbackend to use when authenticating a user if post_reset_login is\nTrue. Required only if you have multiple\nAUTHENTICATION_BACKENDS configured. Defaults to None.
form_class: Form that will be used to set the password. Defaults to\nSetPasswordForm.
success_url: URL to redirect after the password reset done. Defaults\nto 'password_reset_complete'.
extra_context: A dictionary of context data that will be added to the\ndefault context data passed to the template.
Template context:
\nform: The form (see form_class above) for setting the new user's\npassword.
validlink: Boolean, True if the link (combination of uidb64 and\ntoken) is valid or unused yet.
URL name: password_reset_complete
Presents a view which informs the user that the password has been\nsuccessfully changed.
\nAttributes:
\ntemplate_name: The full name of a template to display the view.\nDefaults to registration/password_reset_complete.html.
extra_context: A dictionary of context data that will be added to the\ndefault context data passed to the template.
Redirects to the login page, and then back to another URL after a\nsuccessful login.
\nRequired arguments:
\nnext: The URL to redirect to after a successful login.
Optional arguments:
\nlogin_url: The URL of the login page to redirect to.\nDefaults to settings.LOGIN_URL if not supplied.
redirect_field_name: The name of a GET field containing the\nURL to redirect to after log out. Overrides next if the given\nGET parameter is passed.
If you don't want to use the built-in views, but want the convenience of not\nhaving to write forms for this functionality, the authentication system\nprovides several built-in forms located in django.contrib.auth.forms:
A form used in the admin interface to change a user's password.
\nTakes the user as the first positional argument.
A form for logging a user in.
\nTakes request as its first positional argument, which is stored on the\nform instance for use by sub-classes.
By default, AuthenticationForm rejects users whose is_active\nflag is set to False. You may override this behavior with a custom\npolicy to determine which users can log in. Do this with a custom form\nthat subclasses AuthenticationForm and overrides the\nconfirm_login_allowed() method. This method should raise a\nValidationError if the given user may\nnot log in.
For example, to allow all users to log in regardless of "active"\nstatus:
\nfrom django.contrib.auth.forms import AuthenticationForm\n\nclass AuthenticationFormWithInactiveUsersOkay(AuthenticationForm):\n def confirm_login_allowed(self, user):\n pass\n(In this case, you'll also need to use an authentication backend that\nallows inactive users, such as\nAllowAllUsersModelBackend.)
Or to allow only some active users to log in:
\nclass PickyAuthenticationForm(AuthenticationForm):\n def confirm_login_allowed(self, user):\n if not user.is_active:\n raise forms.ValidationError(\n _("This account is inactive."),\n code='inactive',\n )\n if user.username.startswith('b'):\n raise forms.ValidationError(\n _("Sorry, accounts starting with 'b' aren't welcome here."),\n code='no_b_users',\n )\nA form for allowing a user to change their password.
\nA form for generating and emailing a one-time use link to reset a\nuser's password.
\nUses the arguments to send an EmailMultiAlternatives.\nCan be overridden to customize how the email is sent to the user.
subject_template_name -- the template for the subject.
email_template_name -- the template for the email body.
context -- context passed to the subject_template,\nemail_template, and html_email_template (if it is not\nNone).
from_email -- the sender's email.
to_email -- the email of the requester.
html_email_template_name -- the template for the HTML body;\ndefaults to None, in which case a plain text email is sent.
By default, save() populates the context with the\nsame variables that\nPasswordResetView passes to its\nemail context.
A form that lets a user change their password without entering the old\npassword.
\nA form used in the admin interface to change a user's information and\npermissions.
\nA ModelForm for creating a new user.
It has three fields: username (from the user model), password1,\nand password2. It verifies that password1 and password2 match,\nvalidates the password using\nvalidate_password(), and\nsets the user's password using\nset_password().
The currently logged-in user and their permissions are made available in the\ntemplate context when you use\nRequestContext.
When rendering a template RequestContext, the\ncurrently logged-in user, either a User\ninstance or an AnonymousUser instance, is\nstored in the template variable {{ user }}:
{% if user.is_authenticated %}\n <p>Welcome, {{ user.username }}. Thanks for logging in.</p>\n{% else %}\n <p>Welcome, new user. Please log in.</p>\n{% endif %}\nThis template context variable is not available if a RequestContext is not\nbeing used.
The currently logged-in user's permissions are stored in the template variable\n{{ perms }}. This is an instance of\ndjango.contrib.auth.context_processors.PermWrapper, which is a\ntemplate-friendly proxy of permissions.
Evaluating a single-attribute lookup of {{ perms }} as a boolean is a proxy\nto User.has_module_perms(). For example, to check if\nthe logged-in user has any permissions in the foo app:
{% if perms.foo %}\nEvaluating a two-level-attribute lookup as a boolean is a proxy to\nUser.has_perm(). For example,\nto check if the logged-in user has the permission foo.can_vote:
{% if perms.foo.can_vote %}\n以下是一个在模板中检查权限的更完整的示例：
\n{% if perms.foo %}\n <p>You have permission to do something in the foo app.</p>\n {% if perms.foo.can_vote %}\n <p>You can vote!</p>\n {% endif %}\n {% if perms.foo.can_drive %}\n <p>You can drive!</p>\n {% endif %}\n{% else %}\n <p>You don't have permission to do anything in the foo app.</p>\n{% endif %}\nIt is possible to also look permissions up by {% if in %} statements.\nFor example:
{% if 'foo' in perms %}\n {% if 'foo.can_vote' in perms %}\n <p>In lookup works, too.</p>\n {% endif %}\n{% endif %}\nWhen you have both django.contrib.admin and django.contrib.auth\ninstalled, the admin provides a convenient way to view and manage users,\ngroups, and permissions. Users can be created and deleted like any Django\nmodel. Groups can be created, and permissions can be assigned to users or\ngroups. A log of user edits to models made within the admin is also stored and\ndisplayed.
You should see a link to "Users" in the "Auth"\nsection of the main admin index page. The "Add user" admin page is different\nthan standard admin pages in that it requires you to choose a username and\npassword before allowing you to edit the rest of the user's fields.
\nAlso note: if you want a user account to be able to create users using the\nDjango admin site, you'll need to give them permission to add users and\nchange users (i.e., the "Add user" and "Change user" permissions). If an\naccount has permission to add users but not to change them, that account won't\nbe able to add users. Why? Because if you have permission to add users, you\nhave the power to create superusers, which can then, in turn, change other\nusers. So Django requires add and change permissions as a slight security\nmeasure.
\nBe thoughtful about how you allow users to manage permissions. If you give a\nnon-superuser the ability to edit users, this is ultimately the same as giving\nthem superuser status because they will be able to elevate permissions of\nusers including themselves!
\nUser passwords are not displayed in the admin (nor stored in the database), but\nthe password storage details are displayed.\nIncluded in the display of this information is a link to\na password change form that allows admins to change user passwords.
\n