이 문서는 기본 설정 상태에서의 Django 인증 시스템 사용법을 설명합니다. 이 설정은 가장 일반적인 프로젝트의 요구 사항을 충족하기 위해 발전해 왔으며, 상당히 넓은 범위의 작업을 처리할 수 있고 비밀번호 및 권한 관리도 매우 정교하게 구현되어 있습니다. 인증 요구 사항이 기본 설정과 다른 프로젝트의 경우, Django는 인증 시스템의 광범위한 :doc:` 확장 및 커스터마이징 을 지원합니다.
\nDjango 인증 시스템은 인증과 권한 부여 기능을 함께 제공하며, 이 두 기능이 서로 어느 정도 결합되어 있기 때문에 일반적으로는 이를 통칭하여 인증 시스템이라고 부릅니다.
\n사용자 객체Link to this heading#User 객체는 Django 인증 시스템의 핵심입니다. 이들은 일반적으로 사이트와 상호작용하는 사람을 나타내며, 접근 제한, 사용자 프로필 등록, 콘텐츠와 작성자 연결 등의 기능을 활성화하는 데 사용됩니다. Django 인증 프레임워크에는 단 한 종류의 사용자 클래스만 존재합니다. 즉, :attr:’superusers’ 슈퍼유저의<django.contrib.auth.models.User.is_superuser> 또는 관리용 :attr:’staff’ <django.contrib.auth.models.User.is_staff> 스태프 사용자는 별도의 사용자 클래스가 아니라, 특정 속성이 설정된 일반 사용자 객체일 뿐입니다.
디폴트 사용자의 주요 속성은 :
\nSee the User API documentation for a\ncomplete reference. The documentation that follows is more task-oriented.
The most direct way to create users is to use the included\ncreate_user() helper function:
>>> 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 이 설치되어 있다면, :ref:` 사용자를 상호작용적으로 추가<auth-admin>` 할 수 있다.
\nCreate superusers using the createsuperuser command:
Linux / macOS
$ python manage.py createsuperuser --username=joe --email=joe@example.com\nWindows
...\\> py manage.py createsuperuser --username=joe --email=joe@example.com\n당신은 프롬프트를 통해 패스워드 입력을 해야할 것 입니다. 패스워드를 입력한 뒤, 사용자가 바로 생성될 것입니다. 만약 --username or --email 옵션들을 사용하지 않으면, 이들의 값을 위해 프롬프트로 물어볼 것입니다.
Django 는 사용자 모델에 원본 패스워드(일반 텍스트)를 저장하지 않고, 오직 해쉬만 저장합니다. (디테일하게 보기 비밀번호 조작하기 문서 ). 이로 인해, 사용자의 패스워드 속성을 직접적으로 조작하려 시도하지 마십시오. 이는 사용자 생성을 위해 헬퍼 함수를 사용하는 이유입니다.
\n사용자의 패스워드를 변경하기 위해, 여러 옵션이 있습니다.
\nmanage.py changepassword *username* offers a method\nof changing a user’s password from the command line. It prompts you to\nchange the password of a given user which you must enter twice. If\nthey both match, the new password will be changed immediately. If you\ndo not supply a user, the command will attempt to change the password\nwhose username matches the current system user.
You can also change a password programmatically, using\nset_password():
>>> from django.contrib.auth.models import User\n>>> u = User.objects.get(username="john")\n>>> u.set_password("new password")\n>>> u.save()\nIf you have the Django admin installed, you can also change user’s passwords\non the authentication system’s admin pages.
\nDjango also provides views and forms that may be used to allow users to change their own\npasswords.
\nChanging a user’s password will log out all their sessions. See\n패스워드 변경시 세션 무효화 for details.
\nAsynchronous version: aauthenticate()
Use authenticate() to verify a set of\ncredentials. It takes credentials as keyword arguments, username and\npassword for the default case, checks them against each\nauthentication backend, and returns a\nUser object if the credentials are\nvalid for a backend. If the credentials aren’t valid for any backend or if\na backend raises PermissionDenied, it\nreturns None. For example:
from django.contrib.auth import authenticate\n\nuser = authenticate(username="john", password="secret")\nif user is not None:\n # A backend authenticated the credentials\n ...\nelse:\n # No backend authenticated the credentials\n ...\nrequest is an optional HttpRequest which is\npassed on the authenticate() method of the authentication backends.
Django uses sessions and middleware to hook the\nauthentication system into HttpRequest objects.
These provide a request.user attribute\nand a request.auser async method\non every request which represents the current user. If the current user has not\nlogged in, this attribute will be set to an instance\nof AnonymousUser, otherwise it will be an\ninstance of User.
그것들을 다음과 같이 :attr:`~django.contrib.auth.models.User.is_authenticated`로 구분할 수 있다.
\nif request.user.is_authenticated:\n # Do something for authenticated users.\n ...\nelse:\n # Do something for anonymous users.\n ...\nOr in an asynchronous view:
\nuser = await request.auser()\nif user.is_authenticated:\n # Do something for authenticated users.\n ...\nelse:\n # Do something for anonymous users.\n ...\n현재 세션에 연결하려는 인증된 사용자가 있는 경우 - 이것은 login() 기능으로 수행된다.
Asynchronous version: alogin()
To log a user in, from a view, use login(). It\ntakes an HttpRequest object and a\nUser object.\nlogin() saves the user’s ID in the session,\nusing Django’s session framework.
익명 세션 동안 설정된 모든 데이터는 사용자가 로그인한 후에도 세션에 유지된다.
\nThis example shows how you might use both\nauthenticate() and\nlogin():
from django.contrib.auth import authenticate, login\n\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와 인증에 사용된 백엔드가 저장된다. 이렇게 하면 동일한 :ref:`authentication backend <authentication-backends>`가 향후 요청에서 사용자의 세부 정보를 가져올 수 있다. 세션에 저장할 인증 백엔드는 다음과 같이 선택된다.
\n제공되는 경우 선택적 backend 인수 값을 사용한다.
Use the value of the user.backend attribute, if present. This allows\npairing authenticate() and\nlogin():\nauthenticate()\nsets the user.backend attribute on the user object it returns.
하나뿐인 경우 :setting:`AUTHENTICATION_BACKENDS`에 ``backend``를 사용한다
그렇지 않으면 예외를 발생시킨다.
사례 1과 2의 경우 backend 인수 또는 user.backend 속성의 값은 실제 백엔드 클래스가 아니라 점으로 구분된 import 경로 문자열(예: :setting:`AUTHENTICATION_BACKENDS`에 있음)이어야 한다.
Asynchronous version: alogout()
To log out a user who has been logged in via\ndjango.contrib.auth.login(), use\ndjango.contrib.auth.logout() within your view. It takes an\nHttpRequest object and has no return value.\nExample:
from django.contrib.auth import logout\n\n\ndef logout_view(request):\n logout(request)\n # Redirect to a success page.\nNote that logout() doesn’t throw any errors if\nthe user wasn’t logged in.
When you call logout(), the session data for\nthe current request is completely cleaned out. All existing data is\nremoved. This is to prevent another person from using the same web browser\nto log in and have access to the previous user’s session data. If you want\nto put anything into the session that will be available to the user\nimmediately after logging out, do that after calling\ndjango.contrib.auth.logout().
페이지에 대한 액세스를 제한하는 기본적인 방법은 :attr:`request.user.is_authenticated <django.contrib.auth.models.User.is_authenticated>`를 확인하고 로그인 페이지로 리디렉션하는 것이다.
\nfrom django.conf import settings\nfrom django.shortcuts import redirect\n\n\ndef my_view(request):\n if not request.user.is_authenticated:\n return redirect(f"{settings.LOGIN_URL}?next={request.path}")\n # ...\n…또는 오류 메시지 표시한다.
\nfrom django.shortcuts import render\n\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() decorator::를 사용할 수 있다.
from django.contrib.auth.decorators import login_required\n\n\n@login_required\ndef my_view(request): ...\n:func:`~django.contrib.auth.decorators.login_required`는 다음을 수행한다.
\n사용자가 로그인하지 않은 경우 쿼리 문자열에 현재 절대 경로를 전달하여 settings.LOGIN_URL<LOGIN_URL> `로 리디렉션한다. 예: `/accounts/login/?next=/polls/3/``.
사용자가 로그인되어 있으면 정상적으로 뷰를 실행한다. 뷰 코드는 사용자가 로그인했다고 가정할 수 있다.
기본적으로 인증 성공 시 사용자가 리디렉션되어야 하는 경로는 "next"``라는 쿼리 문자열 매개변수에 저장된다. 이 매개변수에 다른 이름을 사용하고 싶다면 :func:`~django.contrib.auth.decorators.login_required`는 선택적 ``redirect_field_name 매개변수::를 사용한다.
from django.contrib.auth.decorators import login_required\n\n\n@login_required(redirect_field_name="my_redirect_field")\ndef my_view(request): ...\nredirect_field_name``에 값을 제공하면 리디렉션 경로를 저장하는 템플릿 컨텍스트 변수가 ``"next" (기본값) 이 아닌 redirect_field_name 값을 키로 사용하기 때문에 로그인 템플릿도 커스터마이즈해야 할 가능성이 크다.
login_required`는 선택적 ``login_url`() 매개변수도 사용한다. 예시:
from django.contrib.auth.decorators import login_required\n\n\n@login_required(login_url="/accounts/login/")\ndef my_view(request): ...\nlogin_url 매개변수를 지정하지 않으면 :setting:`settings.LOGIN_URL <LOGIN_URL>`과 로그인 보기가 제대로 연결되어 있는지 확인해야 합니다. 예를 들어 기본값을 사용하여 URLconf에 다음 줄을 추가한다.
from django.contrib.auth import views as auth_views\n\npath("accounts/login/", auth_views.LoginView.as_view()),\n:setting:`settings.LOGIN_URL <LOGIN_URL>`은 뷰 함수 이름과 :ref:`named URL patterns <naming-url-patterns>`도 허용한다. 이렇게 하면 설정을 업데이트하지 않고도 URLconf 내에서 로그인 뷰를 자유롭게 다시 매핑할 수 있다.
\nLoginRequiredMixin mixinLink to this heading#:doc:class-based views </topics/class-based-views/index>`를 사용할 때 ``LoginRequiredMixin``을 사용하여 ``login_required``와 동일한 동작을 얻을 수 있다. 이 믹스인은 상속 목록에서 가장 왼쪽에 있어야 한다.
\n뷰가 이 믹스인을 사용하는 경우 인증되지 않은 사용자의 모든 요청은 로그인 페이지로 리디렉션되거나 raise_exception 매개변수에 따라 HTTP 403 Forbidden 오류가 표시된다.
:class:`~django.contrib.auth.mixins.AccessMixin`의 매개변수를 설정하여 권한이 없는 사용자 처리를 커스터마이즈할 수 있다.
\nfrom django.contrib.auth.mixins import LoginRequiredMixin\n\n\nclass MyView(LoginRequiredMixin, View):\n login_url = "/login/"\n redirect_field_name = "redirect_to"\nlogin_not_required decoratorLink to this heading#When LoginRequiredMiddleware is\ninstalled, all views require authentication by default. Some views, such as the\nlogin view, may need to disable this behavior.
Allows unauthenticated requests to this view when\nLoginRequiredMiddleware is\ninstalled.
특정 권한이나 다른 테스트를 기반으로 액세스를 제한하려면 기본적으로 이전 섹션에서 설명한 것과 동일한 작업을 수행한다.
\n뷰에서 직접 :attr:`request.user <django.http.HttpRequest.user>`에 대한 테스트를 실행할 수 있다. 예를 들어, 이 뷰는 사용자가 원하는 도메인에 이메일이 있는지 확인하고 그렇지 않은 경우 로그인 페이지로 리디렉션한다.
\nfrom django.shortcuts import redirect\n\n\ndef my_view(request):\n if not request.user.email.endswith("@example.com"):\n return redirect("/login/?next=%s" % request.path)\n # ...\n단축키로 콜러블이 False``를 반환할 때 리디렉션을 수행하는 편리한 ``user_passes_test decorator를 사용할 수 있다.
from django.contrib.auth.decorators import user_passes_test\n\n\ndef email_check(user):\n return user.email.endswith("@example.com")\n\n\n@user_passes_test(email_check)\ndef my_view(request): ...\nUser() 객체를 취하고 사용자가 페이지를 볼 수 있는 경우 ``True``를 반환하는 콜러블. :func:`~django.contrib.auth.decorators.user_passes_test`는 자동으로 :class:`~django.contrib.auth.models.User`가 익명이 아닌지 확인하지 않는다는 점에 유의해야 한다.
:func:`~django.contrib.auth.decorators.user_passes_test`는 두 개의 선택적 인수를 사용한다.
\nlogin_url테스트를 통과하지 못한 사용자가 리디렉션될 URL을 지정할 수 있다. 로그인 페이지일 수 있으며 지정하지 않으면 기본값은 :setting:`settings.LOGIN_URL <LOGIN_URL>`이다.
\nredirect_field_name:func:`~django.contrib.auth.decorators.login_required`와 동일하다. ``None``으로 설정하면 URL에서 제거된다. 테스트를 통과하지 못한 사용자를 “다음 페이지”가 없는 비로그인 페이지로 리디렉션하는 경우 이 작업을 수행할 수 있다.
\n예시:
\n@user_passes_test(email_check, login_url="/login/")\ndef my_view(request): ...\n:doc:`class-based views </topics/class-based-views/index>`를 사용하는 경우 ``UserPassesTestMixin``을 사용하여 이를 수행할 수 있다.
\n수행되는 테스트를 제공하려면 클래스의 test_func() 메서드를 재정의해야 한다. 또한 :class:`~django.contrib.auth.mixins.AccessMixin`의 매개변수를 설정하여 권한이 없는 사용자 처리를 커스터마이즈할 수 있다.
from django.contrib.auth.mixins import UserPassesTestMixin\n\n\nclass MyView(UserPassesTestMixin, View):\n def test_func(self):\n return self.request.user.email.endswith("@example.com")\n또한 get_test_func() 메소드를 재정의하여 mixin이 검사를 위해 (test_func() 대신) 다른 이름의 함수를 사용하도록 할 수도 있다.
permission_required decoratorLink 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\n@permission_required("polls.add_choice")\ndef my_view(request): ...\nhas_perm() 메서드와 마찬가지로 권한 이름은 "<app label>.<permission codename>" 형식을 취한다(즉, polls 애플리케이션의 모델에 대한 권한의 경우 polls.add_choice).
decorator는 반복 가능한 권한을 가질 수도 있습니다. 이 경우 사용자는 뷰에 액세스하기 위해 모든 권한을 가지고 있어야 한다.
\nNote that permission_required()\nalso takes an optional login_url parameter:
from django.contrib.auth.decorators import permission_required\n\n\n@permission_required("polls.add_choice", login_url="/loginpage/")\ndef my_view(request): ...\nlogin_required() 데코레이터에서와 같이 ``login_url``의 기본값은 :setting:`settings.LOGIN_URL <LOGIN_URL>`이다.
raise_exception 매개변수가 지정되면 데코레이터는 로그인 페이지로 리디렉션하는 대신 :exc:`~django.core.exceptions.PermissionDenied`를 발생시켜 :ref:`403(HTTP Forbidden) view<http_forbidden_view>’를 표시한다.
``raise_exception``을 사용하고 사용자에게 먼저 로그인할 기회를 주고 싶다면 login_required() 데코레이터를 추가할 수 있다:
from django.contrib.auth.decorators import login_required, permission_required\n\n\n@login_required\n@permission_required("polls.add_choice", raise_exception=True)\ndef my_view(request): ...\n이는 또한 :class:`.LoginView`의 ``redirect_authenticated_user=True``이고 로그인한 사용자에게 필요한 모든 권한이 없는 경우 리디렉션 루프를 방지한다.
\nPermissionRequiredMixin 믹스인Link to this heading#:doc:`class-based views`에 권한 검사를 적용하려면 ``PermissionRequiredMixin``을 사용할 수 있다.
\n이 믹스인은 permission_required decorator와 마찬가지로 뷰에 액세스하는 사용자에게 주어진 권한이 모두 있는지 여부를 확인하다. permission_required 매개변수를 사용하여 권한(또는 권한의 이터러블)을 지정해야 한다.
from django.contrib.auth.mixins import PermissionRequiredMixin\n\n\nclass MyView(PermissionRequiredMixin, View):\n permission_required = "polls.add_choice"\n # Or multiple of permissions:\n permission_required = ["polls.view_choice", "polls.change_choice"]\n:class:`~django.contrib.auth.mixins.AccessMixin`의 매개변수 중 하나를 설정하여 권한이 없는 사용자의 처리를 커스터마이즈할 수 있다.
\n다음 메서드를 재정의할 수도 있다.
\n믹스인에서 사용하는 권한 이름의 이터러블을 반환한다. 기본값은 permission_required 속성으로, 필요한 경우 튜플로 변환된다.
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\nallows you 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.
\nMethods and Attributes
\nThe name of a template to display for the view used to log the user in.\nDefaults to registration/login.html.
The URL to redirect to after login. Defaults to\nLOGIN_REDIRECT_URL.
The name of a GET field containing the URL to redirect to after\nlogin. Defaults to next. Overrides the\nget_default_redirect_url() URL if the given GET parameter is\npassed.
A callable (typically a form class) to use for authentication. Defaults\nto AuthenticationForm.
A dictionary of context data that will be added to the default context\ndata passed to the template.
\nA boolean that controls whether or not authenticated users accessing\nthe login page will be redirected as if they had just successfully\nlogged in. Defaults to False.
A set of hosts, in addition to request.get_host(), that are safe for redirecting\nafter login. Defaults to an empty set.
Returns the URL to redirect to after login. The default implementation\nresolves and returns next_page if set, or\nLOGIN_REDIRECT_URL otherwise.
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 “sites” 프레임워크.
If you’d prefer not to call the template registration/login.html,\nyou can pass the template_name parameter via the extra arguments to the\nas_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 set up 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 on POST requests.
URL name: logout
Attributes:
\nThe URL to redirect to after logout. Defaults to\nLOGOUT_REDIRECT_URL.
The full name of a template to display after logging the user out.\nDefaults to registration/logged_out.html.
The name of a GET field containing the URL to redirect to after log\nout. Defaults to 'next'. Overrides the\nnext_page URL if the given GET parameter is\npassed.
A dictionary of context data that will be added to the default context\ndata passed to the template.
\nA set of hosts, in addition to request.get_host(), that are safe for redirecting\nafter 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 “sites” 프레임워크.
Logs a user out on POST requests, then redirects to the login page.
URL 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:
\nThe full name of a template to use for displaying the password change\nform. Defaults to registration/password_change_form.html if not\nsupplied.
The URL to redirect to after a successful password change. Defaults to\n'password_change_done'.
A custom “change password” form which must accept a user keyword\nargument. The form is responsible for actually changing the user’s\npassword. Defaults to\nPasswordChangeForm.
A dictionary of context data that will be added to the default context\ndata passed to the template.
\nTemplate 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:
\nThe full name of a template to use. Defaults to\nregistration/password_change_done.html if not supplied.
A dictionary of context data that will be added to the default context\ndata passed to the template.
\nURL 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.
\nThis view will send an email if the following conditions are met:
\nThe email address provided exists in the system.
The requested user is active (User.is_active is True).
The requested user has a usable password. Users flagged with an unusable\npassword (see\nset_unusable_password()) aren’t\nallowed to request a password reset to prevent misuse when using an\nexternal authentication source like LDAP.
If any of these conditions are not met, no email will be sent, but the\nuser won’t receive any error message either. This prevents information\nleaking to potential attackers. If you want to provide an error message in\nthis case, you can subclass\nPasswordResetForm and use the\nform_class attribute.
Attributes:
\nThe full name of a template to use for displaying the password reset\nform. Defaults to registration/password_reset_form.html if not\nsupplied.
Form that will be used to get the email of the user to reset the\npassword for. Defaults to\nPasswordResetForm.
The full name of a template to use for generating the email with the\nreset password link. Defaults to\nregistration/password_reset_email.html if not supplied.
The full name of a template to use for the subject of the email with\nthe reset password link. Defaults to\nregistration/password_reset_subject.txt if not supplied.
Instance of the class to check the one time link. This will default to\ndefault_token_generator, it’s an instance of\ndjango.contrib.auth.tokens.PasswordResetTokenGenerator.
The URL to redirect to after a successful password reset request.\nDefaults to 'password_reset_done'.
A valid email address. By default Django uses the\nDEFAULT_FROM_EMAIL.
A dictionary of context data that will be added to the default context\ndata passed to the template.
\nThe full name of a template to use for generating a\ntext/html multipart email with the password reset link. By\ndefault, HTML email is not sent.
\nA dictionary of context data that will be available in the email\ntemplate. It can be used to override default template context values\nlisted below e.g. domain.
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 “sites” 프레임워크.
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:
\nThe full name of a template to use. Defaults to\nregistration/password_reset_done.html if not supplied.
A dictionary of context data that will be added to the default context\ndata passed to the template.
\nURL 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:
\nThe full name of a template to display the confirm password view.\nDefault value is registration/password_reset_confirm.html.
Instance of the class to check the password. This will default to\ndefault_token_generator, it’s an instance of\ndjango.contrib.auth.tokens.PasswordResetTokenGenerator.
A boolean indicating if the user should be automatically authenticated\nafter a successful password reset. Defaults to False.
A dotted path to the authentication backend to use when authenticating\na user if post_reset_login is True. Required only if you have\nmultiple AUTHENTICATION_BACKENDS configured. Defaults to\nNone.
Form that will be used to set the password. Defaults to\nSetPasswordForm.
URL to redirect after the password reset done. Defaults to\n'password_reset_complete'.
A dictionary of context data that will be added to the default context\ndata passed to the template.
\nToken parameter displayed as a component of password reset URLs.\nDefaults to 'set-password'.
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:
\nThe full name of a template to display the view. Defaults to\nregistration/password_reset_complete.html.
A dictionary of context data that will be added to the default context\ndata passed to the template.
\nRedirects 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 login. 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, including\nthe ability to set an unusable password (via\nset_unusable_password()), which\nblocks the user from logging in with password-based authentication.
Takes the user as the first positional argument.
A form used in the admin interface to create a new user. Inherits from\nUserCreationForm.
It includes an additional usable_password field, enabled by default. If\nusable_password is enabled, it verifies that password1 and\npassword2 are non empty and match, validates the password using\nvalidate_password(), and\nsets the user’s password using\nset_password().\nIf usable_password is disabled, no password validation is done, and\npassword-based authentication is disabled for the user by calling\nset_unusable_password().
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\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 ValidationError(\n _("This account is inactive."),\n code="inactive",\n )\n if user.username.startswith("b"):\n raise ValidationError(\n _("Sorry, accounts starting with 'b' aren't welcome here."),\n code="no_b_users",\n )\nA ModelForm for creating a new user. This is the\nrecommended base class if you need to customize the user creation form.
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().
A 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. If\nyou choose to override this method, be mindful of handling potential\nexceptions raised due to email sending failures.
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.
\nInherits from BaseUserCreationForm. To help prevent confusion with\nsimilar usernames, the form doesn’t allow usernames that differ only in\ncase.
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\nexample, to check if the logged-in user has the permission foo.add_vote:
{% if perms.foo.add_vote %}\nHere’s a more complete example of checking permissions in a template:
\n{% if perms.foo %}\n <p>You have permission to do something in the foo app.</p>\n {% if perms.foo.add_vote %}\n <p>You can vote!</p>\n {% endif %}\n {% if perms.foo.add_driving %}\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.add_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.\nAlternatively, on this page, you can choose a username and disable\npassword-based authentication for the user.
\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 or unset user passwords.
\n