Django authenticate error

>>> from django.contrib.auth.models import User
>>> user = User.objects.create_user('john', 'lennon@thebeatles.com', 'johnpassword')

# At this point, user is a User object that has already been saved
# to the database. You can continue to change its attributes
# if you want to change other fields.
>>> user.last_name = 'Lennon'
>>> user.save()

$ python manage.py createsuperuser --username=joe --email=joe@example.com

>>> from django.contrib.auth.models import User
>>> u = User.objects.get(username='john')
>>> u.set_password('new password')
>>> u.save()

from myapp.models import BlogPost
from django.contrib.auth.models import Permission
from django.contrib.contenttypes.models import ContentType

content_type = ContentType.objects.get_for_model(BlogPost)
permission = Permission.objects.create(
    codename='can_publish',
    name='Can Publish Posts',
    content_type=content_type,
)

Proxy models need their own content type

If you want to create permissions for a proxy model, pass for_concrete_model=False to
ContentTypeManager.get_for_model() to get the appropriate
ContentType:

content_type = ContentType.objects.get_for_model(BlogPostProxy, for_concrete_model=False)

from django.contrib.auth.models import Permission, User
from django.contrib.contenttypes.models import ContentType
from django.shortcuts import get_object_or_404

from myapp.models import BlogPost

def user_gains_perms(request, user_id):
    user = get_object_or_404(User, pk=user_id)
    # any permission check will cache the current set of permissions
    user.has_perm('myapp.change_blogpost')

    content_type = ContentType.objects.get_for_model(BlogPost)
    permission = Permission.objects.get(
        codename='change_blogpost',
        content_type=content_type,
    )
    user.user_permissions.add(permission)

    # Checking the cached permission set
    user.has_perm('myapp.change_blogpost')  # False

    # Request new instance of User
    # Be aware that user.refresh_from_db() won't clear the cache.
    user = get_object_or_404(User, pk=user_id)

    # Permission cache is repopulated from the database
    user.has_perm('myapp.change_blogpost')  # True

    ...

class Person(models.Model):
    class Meta:
        permissions = [('can_eat_pizzas', 'Can eat pizzas')]

class Student(Person):
    class Meta:
        proxy = True
        permissions = [('can_deliver_pizzas', 'Can deliver pizzas')]

>>> # Fetch the content type for the proxy model.
>>> content_type = ContentType.objects.get_for_model(Student, for_concrete_model=False)
>>> student_permissions = Permission.objects.filter(content_type=content_type)
>>> [p.codename for p in student_permissions]
['add_student', 'change_student', 'delete_student', 'view_student',
'can_deliver_pizzas']
>>> for permission in student_permissions:
...     user.user_permissions.add(permission)
>>> user.has_perm('app.add_person')
False
>>> user.has_perm('app.can_eat_pizzas')
False
>>> user.has_perms(('app.add_student', 'app.can_deliver_pizzas'))
True

Selecting the authentication backend¶

When a user logs in, the user’s ID and the backend that was used for
authentication are saved in the user’s session. This allows the same
authentication backend to fetch the user’s
details on a future request. The authentication backend to save in the session
is selected as follows:

1. Use the value of the optional backend argument, if provided.
2. Use the value of the user.backend attribute, if present. This allows
   pairing authenticate() and
   login():
   authenticate()
   sets the user.backend attribute on the user object it returns.
3. Use the backend in AUTHENTICATION_BACKENDS, if there is only
   one.
4. Otherwise, raise an exception.

In cases 1 and 2, the value of the backend argument or the user.backend
attribute should be a dotted import path string (like that found in
AUTHENTICATION_BACKENDS), not the actual backend class.

The raw way¶

The raw way to limit access to pages is to check
request.user.is_authenticated and either redirect to a
login page:

from django.conf import settings
from django.shortcuts import redirect

def my_view(request):
    if not request.user.is_authenticated:
        return redirect('%s?next=%s' % (settings.LOGIN_URL, request.path))
    # ...

…or display an error message:

from django.shortcuts import render

def my_view(request):
    if not request.user.is_authenticated:
        return render(request, 'myapp/login_error.html')
    # ...

The login_required decorator¶

login_required(redirect_field_name=‘next’, login_url=None)¶

As a shortcut, you can use the convenient
login_required() decorator:

from django.contrib.auth.decorators import login_required

@login_required
def my_view(request):
    ...

login_required() does the following:

• If the user isn’t logged in, redirect to
  settings.LOGIN_URL, passing the current absolute
  path in the query string. Example: /accounts/login/?next=/polls/3/.
• If the user is logged in, execute the view normally. The view code is
  free to assume the user is logged in.

By default, the path that the user should be redirected to upon
successful authentication is stored in a query string parameter called
"next". If you would prefer to use a different name for this parameter,
login_required() takes an
optional redirect_field_name parameter:

from django.contrib.auth.decorators import login_required

@login_required(redirect_field_name='my_redirect_field')
def my_view(request):
    ...

Note that if you provide a value to redirect_field_name, you will most
likely need to customize your login template as well, since the template
context variable which stores the redirect path will use the value of
redirect_field_name as its key rather than "next" (the default).

login_required() also takes an
optional login_url parameter. Example:

from django.contrib.auth.decorators import login_required

@login_required(login_url='/accounts/login/')
def my_view(request):
    ...

Note that if you don’t specify the login_url parameter, you’ll need to
ensure that the settings.LOGIN_URL and your login
view are properly associated. For example, using the defaults, add the
following lines to your URLconf:

from django.contrib.auth import views as auth_views

path('accounts/login/', auth_views.LoginView.as_view()),

The settings.LOGIN_URL also accepts view function
names and named URL patterns. This allows you
to freely remap your login view within your URLconf without having to
update the setting.

The LoginRequiredMixin mixin¶

When using class-based views, you can
achieve the same behavior as with login_required by using the
LoginRequiredMixin. This mixin should be at the leftmost position in the
inheritance list.

class LoginRequiredMixin¶

If a view is using this mixin, all requests by non-authenticated users will
be redirected to the login page or shown an HTTP 403 Forbidden error,
depending on the
raise_exception parameter.

You can set any of the parameters of
AccessMixin to customize the handling
of unauthorized users:

from django.contrib.auth.mixins import LoginRequiredMixin

class MyView(LoginRequiredMixin, View):
    login_url = '/login/'
    redirect_field_name = 'redirect_to'

Limiting access to logged-in users that pass a test¶

To limit access based on certain permissions or some other test, you’d do
essentially the same thing as described in the previous section.

You can run your test on request.user in
the view directly. For example, this view checks to make sure the user has an
email in the desired domain and if not, redirects to the login page:

from django.shortcuts import redirect

def my_view(request):
    if not request.user.email.endswith('@example.com'):
        return redirect('/login/?next=%s' % request.path)
    # ...

user_passes_test(test_func, login_url=None, redirect_field_name=‘next’)¶

As a shortcut, you can use the convenient user_passes_test decorator
which performs a redirect when the callable returns False:

from django.contrib.auth.decorators import user_passes_test

def email_check(user):
    return user.email.endswith('@example.com')

@user_passes_test(email_check)
def my_view(request):
    ...

user_passes_test() takes a required
argument: a callable that takes a
User object and returns True if
the user is allowed to view the page. Note that
user_passes_test() does not
automatically check that the User is
not anonymous.

user_passes_test() takes two
optional arguments:

login_url

Lets you specify the URL that users who don’t pass the test will be
redirected to. It may be a login page and defaults to
settings.LOGIN_URL if you don’t specify one.

redirect_field_name

Same as for login_required().
Setting it to None removes it from the URL, which you may want to do
if you are redirecting users that don’t pass the test to a non-login
page where there’s no “next page”.

For example:

@user_passes_test(email_check, login_url='/login/')
def my_view(request):
    ...

class UserPassesTestMixin¶

When using class-based views, you
can use the UserPassesTestMixin to do this.

test_func()¶

You have to override the test_func() method of the class to
provide the test that is performed. Furthermore, you can set any of the
parameters of AccessMixin to
customize the handling of unauthorized users:

from django.contrib.auth.mixins import UserPassesTestMixin

class MyView(UserPassesTestMixin, View):

    def test_func(self):
        return self.request.user.email.endswith('@example.com')

get_test_func()¶

You can also override the get_test_func() method to have the mixin
use a differently named function for its checks (instead of
test_func()).

Stacking UserPassesTestMixin

Due to the way UserPassesTestMixin is implemented, you cannot stack
them in your inheritance list. The following does NOT work:

class TestMixin1(UserPassesTestMixin):
    def test_func(self):
        return self.request.user.email.endswith('@example.com')

class TestMixin2(UserPassesTestMixin):
    def test_func(self):
        return self.request.user.username.startswith('django')

class MyView(TestMixin1, TestMixin2, View):
    ...

If TestMixin1 would call super() and take that result into
account, TestMixin1 wouldn’t work standalone anymore.

The permission_required decorator¶

permission_required(perm, login_url=None, raise_exception=False)¶

It’s a relatively common task to check whether a user has a particular
permission. For that reason, Django provides a shortcut for that case: the
permission_required() decorator.:

from django.contrib.auth.decorators import permission_required

@permission_required('polls.add_choice')
def my_view(request):
    ...

Just like the has_perm() method,
permission names take the form "<app label>.<permission codename>"
(i.e. polls.add_choice for a permission on a model in the polls
application).

The decorator may also take an iterable of permissions, in which case the
user must have all of the permissions in order to access the view.

Note that permission_required()
also takes an optional login_url parameter:

from django.contrib.auth.decorators import permission_required

@permission_required('polls.add_choice', login_url='/loginpage/')
def my_view(request):
    ...

As in the login_required() decorator,
login_url defaults to settings.LOGIN_URL.

If the raise_exception parameter is given, the decorator will raise
PermissionDenied, prompting the 403
(HTTP Forbidden) view instead of redirecting to the
login page.

If you want to use raise_exception but also give your users a chance to
login first, you can add the
login_required() decorator:

from django.contrib.auth.decorators import login_required, permission_required

@login_required
@permission_required('polls.add_choice', raise_exception=True)
def my_view(request):
    ...

This also avoids a redirect loop when LoginView’s
redirect_authenticated_user=True and the logged-in user doesn’t have
all of the required permissions.

The PermissionRequiredMixin mixin¶

To apply permission checks to class-based views, you can use the PermissionRequiredMixin:

class PermissionRequiredMixin¶

This mixin, just like the permission_required
decorator, checks whether the user accessing a view has all given
permissions. You should specify the permission (or an iterable of
permissions) using the permission_required parameter:

from django.contrib.auth.mixins import PermissionRequiredMixin

class MyView(PermissionRequiredMixin, View):
    permission_required = 'polls.add_choice'
    # Or multiple of permissions:
    permission_required = ('polls.view_choice', 'polls.change_choice')

You can set any of the parameters of
AccessMixin to customize the handling
of unauthorized users.

You may also override these methods:

get_permission_required()¶

Returns an iterable of permission names used by the mixin. Defaults to
the permission_required attribute, converted to a tuple if
necessary.

has_permission()¶

Returns a boolean denoting whether the current user has permission to
execute the decorated view. By default, this returns the result of
calling has_perms() with the
list of permissions returned by get_permission_required().

Session invalidation on password change¶

If your AUTH_USER_MODEL inherits from
AbstractBaseUser or implements its own
get_session_auth_hash()
method, authenticated sessions will include the hash returned by this function.
In the AbstractBaseUser case, this is an
HMAC of the password field. Django verifies that the hash in the session for
each request matches the one that’s computed during the request. This allows a
user to log out all of their sessions by changing their password.

The default password change views included with Django,
PasswordChangeView and the
user_change_password view in the django.contrib.auth admin, update
the session with the new password hash so that a user changing their own
password won’t log themselves out. If you have a custom password change view
and wish to have similar behavior, use the update_session_auth_hash()
function.

update_session_auth_hash(request, user)¶

This function takes the current request and the updated user object from
which the new session hash will be derived and updates the session hash
appropriately. It also rotates the session key so that a stolen session
cookie will be invalidated.

Example usage:

from django.contrib.auth import update_session_auth_hash

def password_change(request):
    if request.method == 'POST':
        form = PasswordChangeForm(user=request.user, data=request.POST)
        if form.is_valid():
            form.save()
            update_session_auth_hash(request, form.user)
    else:
        ...

Using the views¶

There are different methods to implement these views in your project. The
easiest way is to include the provided URLconf in django.contrib.auth.urls
in your own URLconf, for example:

urlpatterns = [
    path('accounts/', include('django.contrib.auth.urls')),
]

This will include the following URL patterns:

accounts/login/ [name='login']
accounts/logout/ [name='logout']
accounts/password_change/ [name='password_change']
accounts/password_change/done/ [name='password_change_done']
accounts/password_reset/ [name='password_reset']
accounts/password_reset/done/ [name='password_reset_done']
accounts/reset/<uidb64>/<token>/ [name='password_reset_confirm']
accounts/reset/done/ [name='password_reset_complete']

The views provide a URL name for easier reference. See the URL
documentation for details on using named URL patterns.

If you want more control over your URLs, you can reference a specific view in
your URLconf:

from django.contrib.auth import views as auth_views

urlpatterns = [
    path('change-password/', auth_views.PasswordChangeView.as_view()),
]

The views have optional arguments you can use to alter the behavior of the
view. For example, if you want to change the template name a view uses, you can
provide the template_name argument. A way to do this is to provide keyword
arguments in the URLconf, these will be passed on to the view. For example:

urlpatterns = [
    path(
        'change-password/',
        auth_views.PasswordChangeView.as_view(template_name='change-password.html'),
    ),
]

All views are class-based, which allows
you to easily customize them by subclassing.

All authentication views¶

This is a list with all the views django.contrib.auth provides. For
implementation details see Using the views.

class LoginView¶

URL name: login

See the URL documentation for details on using
named URL patterns.

Methods and Attributes

template_name¶

The name of a template to display for the view used to log the user in.
Defaults to registration/login.html.

next_page¶

New in Django 4.0.

The URL to redirect to after login. Defaults to
LOGIN_REDIRECT_URL.

redirect_field_name¶

The name of a GET field containing the URL to redirect to after
login. Defaults to next. Overrides the
get_default_redirect_url() URL if the given GET parameter is
passed.

authentication_form¶

A callable (typically a form class) to use for authentication. Defaults
to AuthenticationForm.

extra_context¶

A dictionary of context data that will be added to the default context
data passed to the template.

redirect_authenticated_user¶

A boolean that controls whether or not authenticated users accessing
the login page will be redirected as if they had just successfully
logged in. Defaults to False.

Warning

If you enable redirect_authenticated_user, other websites will
be able to determine if their visitors are authenticated on your
site by requesting redirect URLs to image files on your website. To
avoid this “social media fingerprinting” information
leakage, host all images and your favicon on a separate domain.

Enabling redirect_authenticated_user can also result in a
redirect loop when using the permission_required() decorator
unless the raise_exception parameter is used.

success_url_allowed_hosts¶

A set of hosts, in addition to request.get_host(), that are safe for redirecting
after login. Defaults to an empty set.

get_default_redirect_url()¶

New in Django 4.0.

Returns the URL to redirect to after login. The default implementation
resolves and returns next_page if set, or
LOGIN_REDIRECT_URL otherwise.

Here’s what LoginView does:

• If called via GET, it displays a login form that POSTs to the
  same URL. More on this in a bit.
• If called via POST with user submitted credentials, it tries to log
  the user in. If login is successful, the view redirects to the URL
  specified in next. If next isn’t provided, it redirects to
  settings.LOGIN_REDIRECT_URL (which
  defaults to /accounts/profile/). If login isn’t successful, it
  redisplays the login form.

It’s your responsibility to provide the html for the login template
, called registration/login.html by default. This template gets passed
four template context variables:

• form: A Form object representing the
  AuthenticationForm.
• next: The URL to redirect to after successful login. This may
  contain a query string, too.
• site: The current Site,
  according to the SITE_ID setting. If you don’t have the
  site framework installed, this will be set to an instance of
  RequestSite, which derives the
  site name and domain from the current
  HttpRequest.
• site_name: An alias for site.name. If you don’t have the site
  framework installed, this will be set to the value of
  request.META['SERVER_NAME'].
  For more on sites, see The “sites” framework.

If you’d prefer not to call the template registration/login.html,
you can pass the template_name parameter via the extra arguments to
the as_view method in your URLconf. For example, this URLconf line would
use myapp/login.html instead:

path('accounts/login/', auth_views.LoginView.as_view(template_name='myapp/login.html')),

You can also specify the name of the GET field which contains the URL
to redirect to after login using redirect_field_name. By default, the
field is called next.

Here’s a sample registration/login.html template you can use as a
starting point. It assumes you have a base.html template that
defines a content block:

{% extends "base.html" %}

{% block content %}

{% if form.errors %}
<p>Your username and password didn't match. Please try again.</p>
{% endif %}

{% if next %}
    {% if user.is_authenticated %}
    <p>Your account doesn't have access to this page. To proceed,
    please login with an account that has access.</p>
    {% else %}
    <p>Please login to see this page.</p>
    {% endif %}
{% endif %}

<form method="post" action="{% url 'login' %}">
{% csrf_token %}
<table>
<tr>
    <td>{{ form.username.label_tag }}</td>
    <td>{{ form.username }}</td>
</tr>
<tr>
    <td>{{ form.password.label_tag }}</td>
    <td>{{ form.password }}</td>
</tr>
</table>

<input type="submit" value="login">
<input type="hidden" name="next" value="{{ next }}">
</form>

{# Assumes you set up the password_reset view in your URLconf #}
<p><a href="{% url 'password_reset' %}">Lost password?</a></p>

{% endblock %}

If you have customized authentication (see Customizing Authentication) you can use a custom authentication form by
setting the authentication_form attribute. This form must accept a
request keyword argument in its __init__() method and provide a
get_user() method which returns the authenticated user object (this
method is only ever called after successful form validation).

class LogoutView¶

Logs a user out on POST requests.

Deprecated since version 4.1: Support for logging out on GET requests is deprecated and will be
removed in Django 5.0.

URL name: logout

Attributes:

next_page¶

The URL to redirect to after logout. Defaults to
LOGOUT_REDIRECT_URL.

template_name¶

The full name of a template to display after logging the user out.
Defaults to registration/logged_out.html.

redirect_field_name¶

The name of a GET field containing the URL to redirect to after log
out. Defaults to 'next'. Overrides the
next_page URL if the given GET parameter is
passed.

extra_context¶

A dictionary of context data that will be added to the default context
data passed to the template.

success_url_allowed_hosts¶

A set of hosts, in addition to request.get_host(), that are safe for redirecting
after logout. Defaults to an empty set.

Template context:

• title: The string “Logged out”, localized.
• site: The current Site,
  according to the SITE_ID setting. If you don’t have the
  site framework installed, this will be set to an instance of
  RequestSite, which derives the
  site name and domain from the current
  HttpRequest.
• site_name: An alias for site.name. If you don’t have the site
  framework installed, this will be set to the value of
  request.META['SERVER_NAME'].
  For more on sites, see The “sites” framework.

logout_then_login(request, login_url=None)¶

Logs a user out on POST requests, then redirects to the login page.

URL name: No default URL provided

Optional arguments:

• login_url: The URL of the login page to redirect to.
  Defaults to settings.LOGIN_URL if not supplied.

Deprecated since version 4.1: Support for logging out on GET requests is deprecated and will be
removed in Django 5.0.

class PasswordChangeView¶

URL name: password_change

Allows a user to change their password.

Attributes:

template_name¶

The full name of a template to use for displaying the password change
form. Defaults to registration/password_change_form.html if not
supplied.

success_url¶

The URL to redirect to after a successful password change. Defaults to
'password_change_done'.

form_class¶

A custom “change password” form which must accept a user keyword
argument. The form is responsible for actually changing the user’s
password. Defaults to
PasswordChangeForm.

extra_context¶

A dictionary of context data that will be added to the default context
data passed to the template.

Template context:

• form: The password change form (see form_class above).

class PasswordChangeDoneView¶

URL name: password_change_done

The page shown after a user has changed their password.

Attributes:

template_name¶

The full name of a template to use. Defaults to
registration/password_change_done.html if not supplied.

extra_context¶

A dictionary of context data that will be added to the default context
data passed to the template.

class PasswordResetView¶

URL name: password_reset

Allows a user to reset their password by generating a one-time use link
that can be used to reset the password, and sending that link to the
user’s registered email address.

This view will send an email if the following conditions are met:

• The 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
  password (see
  set_unusable_password()) aren’t
  allowed to request a password reset to prevent misuse when using an
  external authentication source like LDAP.

If any of these conditions are not met, no email will be sent, but the
user won’t receive any error message either. This prevents information
leaking to potential attackers. If you want to provide an error message in
this case, you can subclass
PasswordResetForm and use the
form_class attribute.

Note

Be aware that sending an email costs extra time, hence you may be
vulnerable to an email address enumeration timing attack due to a
difference between the duration of a reset request for an existing
email address and the duration of a reset request for a nonexistent
email address. To reduce the overhead, you can use a 3rd party package
that allows to send emails asynchronously, e.g. django-mailer.

Attributes:

template_name¶

The full name of a template to use for displaying the password reset
form. Defaults to registration/password_reset_form.html if not
supplied.

form_class¶

Form that will be used to get the email of the user to reset the
password for. Defaults to
PasswordResetForm.

email_template_name¶

The full name of a template to use for generating the email with the
reset password link. Defaults to
registration/password_reset_email.html if not supplied.

subject_template_name¶

The full name of a template to use for the subject of the email with
the reset password link. Defaults to
registration/password_reset_subject.txt if not supplied.

token_generator¶

Instance of the class to check the one time link. This will default to
default_token_generator, it’s an instance of
django.contrib.auth.tokens.PasswordResetTokenGenerator.

success_url¶

The URL to redirect to after a successful password reset request.
Defaults to 'password_reset_done'.

from_email¶

A valid email address. By default Django uses the
DEFAULT_FROM_EMAIL.

extra_context¶

A dictionary of context data that will be added to the default context
data passed to the template.

html_email_template_name¶

The full name of a template to use for generating a
text/html multipart email with the password reset link. By
default, HTML email is not sent.

extra_email_context¶

A dictionary of context data that will be available in the email
template. It can be used to override default template context values
listed below e.g. domain.

Template context:

• form: The form (see form_class above) for resetting the user’s
  password.

Email template context:

• email: An alias for user.email
• user: The current User,
  according to the email form field. Only active users are able to
  reset their passwords (User.is_active is True).
• site_name: An alias for site.name. If you don’t have the site
  framework installed, this will be set to the value of
  request.META['SERVER_NAME'].
  For more on sites, see The “sites” framework.
• domain: An alias for site.domain. If you don’t have the site
  framework installed, this will be set to the value of
  request.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:
{{ protocol}}://{{ domain }}{% url 'password_reset_confirm' uidb64=uid token=token %}

The same template context is used for subject template. Subject must be
single line plain text string.

class PasswordResetDoneView¶

URL name: password_reset_done

The page shown after a user has been emailed a link to reset their
password. This view is called by default if the PasswordResetView
doesn’t have an explicit success_url URL set.

Note

If the email address provided does not exist in the system, the user is
inactive, or has an unusable password, the user will still be
redirected to this view but no email will be sent.

Attributes:

template_name¶

The full name of a template to use. Defaults to
registration/password_reset_done.html if not supplied.

extra_context¶

A dictionary of context data that will be added to the default context
data passed to the template.

class PasswordResetConfirmView¶

URL name: password_reset_confirm

Presents a form for entering a new password.

Keyword arguments from the URL:

• uidb64: The user’s id encoded in base 64.
• token: Token to check that the password is valid.

Attributes:

template_name¶

The full name of a template to display the confirm password view.
Default value is registration/password_reset_confirm.html.

token_generator¶

Instance of the class to check the password. This will default to
default_token_generator, it’s an instance of
django.contrib.auth.tokens.PasswordResetTokenGenerator.

post_reset_login¶

A boolean indicating if the user should be automatically authenticated
after a successful password reset. Defaults to False.

post_reset_login_backend¶

A dotted path to the authentication backend to use when authenticating
a user if post_reset_login is True. Required only if you have
multiple AUTHENTICATION_BACKENDS configured. Defaults to
None.

form_class¶

Form that will be used to set the password. Defaults to
SetPasswordForm.

success_url¶

URL to redirect after the password reset done. Defaults to
'password_reset_complete'.

extra_context¶

A dictionary of context data that will be added to the default context
data passed to the template.

reset_url_token¶

Token parameter displayed as a component of password reset URLs.
Defaults to 'set-password'.

Template context:

• form: The form (see form_class above) for setting the new user’s
  password.
• validlink: Boolean, True if the link (combination of uidb64 and
  token) is valid or unused yet.

class PasswordResetCompleteView¶

URL name: password_reset_complete

Presents a view which informs the user that the password has been
successfully changed.

Attributes:

template_name¶

The full name of a template to display the view. Defaults to
registration/password_reset_complete.html.

extra_context¶

A dictionary of context data that will be added to the default context
data passed to the template.

Technicality

Technically, these variables are only made available in the template
context if you use RequestContext and the
'django.contrib.auth.context_processors.auth' context processor is
enabled. It is in the default generated settings file. For more, see the
RequestContext docs.

Users¶

When rendering a template RequestContext, the
currently logged-in user, either a User
instance or an AnonymousUser instance, is
stored in the template variable {{ user }}:

{% if user.is_authenticated %}
    <p>Welcome, {{ user.username }}. Thanks for logging in.</p>
{% else %}
    <p>Welcome, new user. Please log in.</p>
{% endif %}

This template context variable is not available if a RequestContext is not
being used.

Permissions¶

The currently logged-in user’s permissions are stored in the template variable
{{ perms }}. This is an instance of
django.contrib.auth.context_processors.PermWrapper, which is a
template-friendly proxy of permissions.

Evaluating a single-attribute lookup of {{ perms }} as a boolean is a proxy
to User.has_module_perms(). For example, to check if
the logged-in user has any permissions in the foo app:

Evaluating a two-level-attribute lookup as a boolean is a proxy to
User.has_perm(). For example,
to check if the logged-in user has the permission foo.add_vote:

{% if perms.foo.add_vote %}

Here’s a more complete example of checking permissions in a template:

{% if perms.foo %}
    <p>You have permission to do something in the foo app.</p>
    {% if perms.foo.add_vote %}
        <p>You can vote!</p>
    {% endif %}
    {% if perms.foo.add_driving %}
        <p>You can drive!</p>
    {% endif %}
{% else %}
    <p>You don't have permission to do anything in the foo app.</p>
{% endif %}

It is possible to also look permissions up by {% if in %} statements.
For example:

{% if 'foo' in perms %}
    {% if 'foo.add_vote' in perms %}
        <p>In lookup works, too.</p>
    {% endif %}
{% endif %}

>>> from django.contrib.auth.models import User
>>> user = User.objects.create_user('john', 'lennon@thebeatles.com', 'johnpassword')

# At this point, user is a User object that has already been saved
# to the database. You can continue to change its attributes
# if you want to change other fields.
>>> user.last_name = 'Lennon'
>>> user.save()

$ python manage.py createsuperuser --username=joe --email=joe@example.com

>>> from django.contrib.auth.models import User
>>> u = User.objects.get(username='john')
>>> u.set_password('new password')
>>> u.save()

from myapp.models import BlogPost
from django.contrib.auth.models import Permission
from django.contrib.contenttypes.models import ContentType

content_type = ContentType.objects.get_for_model(BlogPost)
permission = Permission.objects.create(
    codename='can_publish',
    name='Can Publish Posts',
    content_type=content_type,
)

Прокси-модели нуждаются в собственном типе содержимого

Если вы хотите создать permissions for a proxy model, передайте for_concrete_model=False в ContentTypeManager.get_for_model(), чтобы получить соответствующее ContentType:

content_type = ContentType.objects.get_for_model(BlogPostProxy, for_concrete_model=False)

from django.contrib.auth.models import Permission, User
from django.contrib.contenttypes.models import ContentType
from django.shortcuts import get_object_or_404

from myapp.models import BlogPost

def user_gains_perms(request, user_id):
    user = get_object_or_404(User, pk=user_id)
    # any permission check will cache the current set of permissions
    user.has_perm('myapp.change_blogpost')

    content_type = ContentType.objects.get_for_model(BlogPost)
    permission = Permission.objects.get(
        codename='change_blogpost',
        content_type=content_type,
    )
    user.user_permissions.add(permission)

    # Checking the cached permission set
    user.has_perm('myapp.change_blogpost')  # False

    # Request new instance of User
    # Be aware that user.refresh_from_db() won't clear the cache.
    user = get_object_or_404(User, pk=user_id)

    # Permission cache is repopulated from the database
    user.has_perm('myapp.change_blogpost')  # True

    ...

class Person(models.Model):
    class Meta:
        permissions = [('can_eat_pizzas', 'Can eat pizzas')]

class Student(Person):
    class Meta:
        proxy = True
        permissions = [('can_deliver_pizzas', 'Can deliver pizzas')]

>>> # Fetch the content type for the proxy model.
>>> content_type = ContentType.objects.get_for_model(Student, for_concrete_model=False)
>>> student_permissions = Permission.objects.filter(content_type=content_type)
>>> [p.codename for p in student_permissions]
['add_student', 'change_student', 'delete_student', 'view_student',
'can_deliver_pizzas']
>>> for permission in student_permissions:
...     user.user_permissions.add(permission)
>>> user.has_perm('app.add_person')
False
>>> user.has_perm('app.can_eat_pizzas')
False
>>> user.has_perms(('app.add_student', 'app.can_deliver_pizzas'))
True

Выбор бэкенда аутентификации¶

Когда пользователь входит в систему, его ID и бэкенд, который использовался для аутентификации, сохраняются в сессии пользователя. Это позволяет тому же authentication backend получить данные пользователя при последующем запросе. Бэкэнд аутентификации для сохранения в сессии выбирается следующим образом:

1. Используйте значение необязательного аргумента backend, если он предоставлен.
2. Используйте значение атрибута user.backend, если он присутствует. Это позволяет использовать пары authenticate() и login(): authenticate() устанавливает атрибут user.backend на возвращаемом объекте пользователя.
3. Используйте backend в AUTHENTICATION_BACKENDS, если есть только один.
4. В противном случае вызовите исключение.

В случаях 1 и 2 значением аргумента backend или атрибута user.backend должна быть строка пути импорта с точкой (как в AUTHENTICATION_BACKENDS), а не реальный класс бэкенда.

Сырой способ¶

Необработанный способ ограничения доступа к страницам заключается в проверке request.user.is_authenticated и либо перенаправлении на страницу входа:

from django.conf import settings
from django.shortcuts import redirect

def my_view(request):
    if not request.user.is_authenticated:
        return redirect('%s?next=%s' % (settings.LOGIN_URL, request.path))
    # ...

…или вывести сообщение об ошибке:

from django.shortcuts import render

def my_view(request):
    if not request.user.is_authenticated:
        return render(request, 'myapp/login_error.html')
    # ...

Декоратор login_required¶

login_required(redirect_field_name=‘next’, login_url=None)[исходный код]¶

В качестве сокращения можно использовать удобный декоратор login_required():

from django.contrib.auth.decorators import login_required

@login_required
def my_view(request):
    ...

login_required() делает следующее:

• Если пользователь не вошел в систему, перенаправьте его на settings.LOGIN_URL, передав текущий абсолютный путь в строке запроса. Пример: /accounts/login/?next=/polls/3/.
• Если пользователь вошел в систему, выполните представление нормально. Код представления может считать, что пользователь вошел в систему.

По умолчанию путь, на который пользователь должен быть перенаправлен после успешной аутентификации, хранится в параметре строки запроса под названием "next". Если вы предпочитаете использовать другое имя для этого параметра, login_required() принимает необязательный параметр redirect_field_name:

from django.contrib.auth.decorators import login_required

@login_required(redirect_field_name='my_redirect_field')
def my_view(request):
    ...

Обратите внимание, что если вы зададите значение redirect_field_name, то, скорее всего, вам также придется настроить шаблон входа в систему, так как контекстная переменная шаблона, хранящая путь перенаправления, будет использовать в качестве ключа значение redirect_field_name, а не "next" (по умолчанию).

login_required() также принимает необязательный параметр login_url. Пример:

from django.contrib.auth.decorators import login_required

@login_required(login_url='/accounts/login/')
def my_view(request):
    ...

Обратите внимание, что если вы не указываете параметр login_url, вам нужно убедиться, что параметр settings.LOGIN_URL и ваше представление входа правильно связаны. Например, используя значения по умолчанию, добавьте следующие строки в URLconf:

from django.contrib.auth import views as auth_views

path('accounts/login/', auth_views.LoginView.as_view()),

settings.LOGIN_URL также принимает имена функций представления и named URL patterns. Это позволяет вам свободно переназначать представление входа в URLconf без необходимости обновлять настройки.

The LoginRequiredMixin mixin¶

При использовании class-based views можно добиться того же поведения, что и при login_required, используя LoginRequiredMixin. Этот миксин должен находиться на самой левой позиции в списке наследования.

class LoginRequiredMixin¶

Если представление использует этот миксин, все запросы неаутентифицированных пользователей будут перенаправляться на страницу входа или отображаться ошибка HTTP 403 Forbidden, в зависимости от параметра raise_exception.

Вы можете установить любой из параметров AccessMixin для настройки обработки неавторизованных пользователей:

from django.contrib.auth.mixins import LoginRequiredMixin

class MyView(LoginRequiredMixin, View):
    login_url = '/login/'
    redirect_field_name = 'redirect_to'

Ограничение доступа для вошедших в систему пользователей, которые прошли тест¶

Чтобы ограничить доступ на основе определенных разрешений или какого-либо другого теста, вы сделаете практически то же самое, что описано в предыдущем разделе.

Вы можете запустить свой тест на request.user непосредственно в представлении. Например, это представление проверяет, есть ли у пользователя email в нужном домене, и если нет, перенаправляет на страницу входа:

from django.shortcuts import redirect

def my_view(request):
    if not request.user.email.endswith('@example.com'):
        return redirect('/login/?next=%s' % request.path)
    # ...

user_passes_test(test_func, login_url=None, redirect_field_name=‘next’)[исходный код]¶

В качестве сокращения можно использовать удобный декоратор user_passes_test, который выполняет перенаправление, когда вызываемый объект возвращает False:

from django.contrib.auth.decorators import user_passes_test

def email_check(user):
    return user.email.endswith('@example.com')

@user_passes_test(email_check)
def my_view(request):
    ...

user_passes_test() принимает обязательный аргумент: вызываемый объект, который принимает объект User и возвращает True, если пользователю разрешено просматривать страницу. Обратите внимание, что user_passes_test() не проверяет автоматически, что User не является анонимным.

user_passes_test() принимает два необязательных аргумента:

login_url

Позволяет указать URL, на который будут перенаправлены пользователи, не прошедшие тест. Это может быть страница входа в систему и по умолчанию имеет значение settings.LOGIN_URL, если вы его не укажете.

redirect_field_name

То же самое, что и для login_required(). Установка значения None удаляет его из URL, что может понадобиться, если вы перенаправляете пользователей, не прошедших тест, на страницу без входа в систему, где нет «следующей страницы».

Например:

@user_passes_test(email_check, login_url='/login/')
def my_view(request):
    ...

class UserPassesTestMixin¶

При использовании class-based views, вы можете использовать UserPassesTestMixin для этого.

test_func()¶

Вы должны переопределить метод test_func() класса, чтобы указать выполняемый тест. Кроме того, вы можете установить любой из параметров AccessMixin для настройки обработки неавторизованных пользователей:

from django.contrib.auth.mixins import UserPassesTestMixin

class MyView(UserPassesTestMixin, View):

    def test_func(self):
        return self.request.user.email.endswith('@example.com')

get_test_func()¶

Вы также можете переопределить метод get_test_func(), чтобы миксин использовал для своих проверок функцию с другим именем (вместо test_func()).

Укладка UserPassesTestMixin

Из-за того, как реализовано UserPassesTestMixin, вы не можете складывать их в список наследования. Следующее НЕ работает:

class TestMixin1(UserPassesTestMixin):
    def test_func(self):
        return self.request.user.email.endswith('@example.com')

class TestMixin2(UserPassesTestMixin):
    def test_func(self):
        return self.request.user.username.startswith('django')

class MyView(TestMixin1, TestMixin2, View):
    ...

Если бы TestMixin1 вызывал super() и учитывал этот результат, TestMixin1 уже не работал бы автономно.

Декоратор permission_required¶

permission_required(perm, login_url=None, raise_exception=False)[исходный код]¶

Это довольно распространенная задача — проверить, есть ли у пользователя определенное разрешение. По этой причине Django предоставляет ярлык для этого случая: декоратор permission_required().:

from django.contrib.auth.decorators import permission_required

@permission_required('polls.add_choice')
def my_view(request):
    ...

Как и в методе has_perm(), имена разрешений принимают форму "<app label>.<permission codename>" (например, polls.add_choice для разрешения на модель в приложении polls).

Декоратор также может принимать итерацию разрешений, в этом случае пользователь должен иметь все разрешения, чтобы получить доступ к представлению.

Обратите внимание, что permission_required() также принимает необязательный параметр login_url:

from django.contrib.auth.decorators import permission_required

@permission_required('polls.add_choice', login_url='/loginpage/')
def my_view(request):
    ...

Как и в декораторе login_required(), login_url по умолчанию равен settings.LOGIN_URL.

Если задан параметр raise_exception, декоратор поднимет PermissionDenied, предлагая the 403 (HTTP Forbidden) view вместо перенаправления на страницу входа.

Если вы хотите использовать raise_exception, но при этом дать пользователям возможность сначала войти в систему, вы можете добавить декоратор login_required():

from django.contrib.auth.decorators import login_required, permission_required

@login_required
@permission_required('polls.add_choice', raise_exception=True)
def my_view(request):
    ...

Это также позволяет избежать цикла перенаправления, когда LoginView становится redirect_authenticated_user=True, а у вошедшего пользователя нет всех необходимых прав.

Миксин PermissionRequiredMixin¶

Чтобы применить проверку разрешений к class-based views, вы можете использовать PermissionRequiredMixin:

class PermissionRequiredMixin¶

Этот миксин, как и декоратор permission_required, проверяет, имеет ли пользователь, обращающийся к представлению, все заданные разрешения. Вы должны указать разрешение (или итерацию разрешений) с помощью параметра permission_required:

from django.contrib.auth.mixins import PermissionRequiredMixin

class MyView(PermissionRequiredMixin, View):
    permission_required = 'polls.add_choice'
    # Or multiple of permissions:
    permission_required = ('polls.view_choice', 'polls.change_choice')

Вы можете установить любой из параметров AccessMixin, чтобы настроить обработку неавторизованных пользователей.

Вы также можете переопределить эти методы:

get_permission_required()¶

Возвращает итерабель имен разрешений, используемых данным микшином. По умолчанию используется атрибут permission_required, при необходимости преобразуется в кортеж.

has_permission()¶

Возвращает булево значение, обозначающее, имеет ли текущий пользователь разрешение на выполнение декорированного представления. По умолчанию возвращается результат вызова has_perms() со списком разрешений, возвращаемым get_permission_required().

Аннулирование сессии при смене пароля¶

Если ваш AUTH_USER_MODEL наследует от AbstractBaseUser или реализует свой собственный метод get_session_auth_hash(), аутентифицированные сессии будут включать хэш, возвращаемый этой функцией. В случае AbstractBaseUser это HMAC поля пароля. Django проверяет, что хэш в сессии для каждого запроса совпадает с тем, который вычисляется во время запроса. Это позволяет пользователю выйти из всех своих сессий, изменив пароль.

Представления смены пароля по умолчанию, входящие в Django, PasswordChangeView и представление user_change_password в админке django.contrib.auth, обновляют сессию новым хэшем пароля, чтобы пользователь, меняющий свой пароль, не вышел из системы. Если у вас есть пользовательское представление смены пароля и вы хотите иметь подобное поведение, используйте функцию update_session_auth_hash().

update_session_auth_hash(request, user)[исходный код]¶

Эта функция принимает текущий запрос и обновленный объект пользователя, из которого будет получен новый хэш сессии, и соответствующим образом обновляет хэш сессии. Она также поворачивает ключ сессии, чтобы украденная сессионная cookie была недействительна.

Пример использования:

from django.contrib.auth import update_session_auth_hash

def password_change(request):
    if request.method == 'POST':
        form = PasswordChangeForm(user=request.user, data=request.POST)
        if form.is_valid():
            form.save()
            update_session_auth_hash(request, form.user)
    else:
        ...

Использование представлений¶

Существуют различные методы реализации этих представлений в вашем проекте. Самый простой способ — включить предоставленный URLconf в django.contrib.auth.urls в ваш собственный URLconf, например:

urlpatterns = [
    path('accounts/', include('django.contrib.auth.urls')),
]

Это будет включать следующие шаблоны URL:

accounts/login/ [name='login']
accounts/logout/ [name='logout']
accounts/password_change/ [name='password_change']
accounts/password_change/done/ [name='password_change_done']
accounts/password_reset/ [name='password_reset']
accounts/password_reset/done/ [name='password_reset_done']
accounts/reset/<uidb64>/<token>/ [name='password_reset_confirm']
accounts/reset/done/ [name='password_reset_complete']

Представления предоставляют имя URL для более удобного использования. Подробнее об использовании именованных шаблонов URL см. в the URL documentation.

Если вы хотите получить больший контроль над своими URL-адресами, вы можете сослаться на определенное представление в URLconf:

from django.contrib.auth import views as auth_views

urlpatterns = [
    path('change-password/', auth_views.PasswordChangeView.as_view()),
]

Представления имеют необязательные аргументы, которые можно использовать для изменения поведения представления. Например, если вы хотите изменить имя шаблона, которое использует представление, вы можете указать аргумент template_name. Для этого в URLconf можно указать аргументы в виде ключевых слов, которые будут переданы представлению. Например:

urlpatterns = [
    path(
        'change-password/',
        auth_views.PasswordChangeView.as_view(template_name='change-password.html'),
    ),
]

Все представления являются class-based, что позволяет легко настраивать их с помощью подклассов.

Все виды аутентификации¶

Это список со всеми представлениями, которые предоставляет django.contrib.auth. Подробности реализации смотрите в Использование представлений.

class LoginView¶

Имя URL: login

Подробнее об использовании именованных шаблонов URL см. в разделе the URL documentation.

Методы и атрибуты

template_name¶

Имя шаблона, отображаемого для представления, используемого для входа пользователя в систему. По умолчанию имеет значение registration/login.html.

next_page¶

New in Django 4.0.

URL для перенаправления после входа в систему. По умолчанию LOGIN_REDIRECT_URL.

redirect_field_name¶

Имя поля GET, содержащего URL для перенаправления после входа в систему. По умолчанию используется next. Переопределяет URL get_default_redirect_url(), если передан заданный параметр GET.

authentication_form¶

Вызываемый объект (обычно класс формы), который будет использоваться для аутентификации. По умолчанию AuthenticationForm.

Словарь контекстных данных, которые будут добавлены к контекстным данным по умолчанию, переданным в шаблон.

redirect_authenticated_user¶

Булево значение, определяющее, будут ли аутентифицированные пользователи, зашедшие на страницу входа, перенаправлены так, как будто они только что успешно вошли в систему. По умолчанию имеет значение False.

Предупреждение

Если вы включите опцию redirect_authenticated_user, другие сайты смогут определить, авторизованы ли их посетители на вашем сайте, запрашивая URL перенаправления на файлы изображений на вашем сайте. Чтобы избежать такой утечки информации social media fingerprinting», размещайте все изображения и ваш favicon на отдельном домене.

Включение redirect_authenticated_user также может привести к циклу перенаправления при использовании декоратора permission_required(), если не используется параметр raise_exception.

success_url_allowed_hosts¶

set хостов, в дополнение к request.get_host(), которые безопасны для перенаправления после входа в систему. По умолчанию используется пустой set.

get_default_redirect_url()¶

New in Django 4.0.

Возвращает URL для перенаправления после входа в систему. Реализация по умолчанию разрешает и возвращает next_page, если установлен, или LOGIN_REDIRECT_URL в противном случае.

Вот что делает LoginView:

• При вызове через GET отображается форма входа в систему, которая POSTs на тот же URL. Подробнее об этом чуть позже.
• При вызове через POST с учетными данными, предоставленными пользователем, он пытается войти в систему. В случае успешного входа представление перенаправляется на URL, указанный в next. Если next не указан, он перенаправляется на settings.LOGIN_REDIRECT_URL (по умолчанию на /accounts/profile/). Если вход не был успешным, отображается форма входа.

Вы обязаны предоставить html для шаблона входа в систему, который по умолчанию называется registration/login.html. Этому шаблону передаются четыре контекстные переменные шаблона:

• form: Объект Form, представляющий AuthenticationForm.
• next: URL для перенаправления после успешного входа в систему. Он также может содержать строку запроса.
• site: Текущий Site, в соответствии с настройкой SITE_ID. Если у вас не установлен фреймворк сайта, это будет установлено в экземпляр RequestSite, который берет имя сайта и домен из текущего HttpRequest.
• site_name: Псевдоним для site.name. Если у вас не установлен фреймворк сайта, это значение будет установлено в значение request.META['SERVER_NAME']. Подробнее о сайтах смотрите Структура «сайтов».

Если вы предпочитаете не вызывать шаблон registration/login.html, вы можете передать параметр template_name через дополнительные аргументы методу as_view в вашем URLconf. Например, эта строка URLconf будет использовать myapp/login.html вместо:

path('accounts/login/', auth_views.LoginView.as_view(template_name='myapp/login.html')),

Вы также можете указать имя поля GET, которое содержит URL-адрес для перенаправления на него после входа в систему с помощью redirect_field_name. По умолчанию поле называется next.

Вот пример шаблона registration/login.html, который вы можете использовать в качестве отправной точки. Он предполагает, что у вас есть шаблон base.html, определяющий блок content:

{% extends "base.html" %}

{% block content %}

{% if form.errors %}
<p>Your username and password didn't match. Please try again.</p>
{% endif %}

{% if next %}
    {% if user.is_authenticated %}
    <p>Your account doesn't have access to this page. To proceed,
    please login with an account that has access.</p>
    {% else %}
    <p>Please login to see this page.</p>
    {% endif %}
{% endif %}

<form method="post" action="{% url 'login' %}">
{% csrf_token %}
<table>
<tr>
    <td>{{ form.username.label_tag }}</td>
    <td>{{ form.username }}</td>
</tr>
<tr>
    <td>{{ form.password.label_tag }}</td>
    <td>{{ form.password }}</td>
</tr>
</table>

<input type="submit" value="login">
<input type="hidden" name="next" value="{{ next }}">
</form>

{# Assumes you set up the password_reset view in your URLconf #}
<p><a href="{% url 'password_reset' %}">Lost password?</a></p>

{% endblock %}

Если вы настроили аутентификацию (см. Customizing Authentication), вы можете использовать пользовательскую форму аутентификации, установив атрибут authentication_form. Эта форма должна принимать аргумент с ключевым словом request в своем методе __init__() и предоставлять метод get_user(), который возвращает объект аутентифицированного пользователя (этот метод вызывается только после успешной проверки формы).

class LogoutView¶

Выводит пользователя из системы при запросе POST.

Не рекомендуется, начиная с версии 4.1: Поддержка выхода из системы при запросах GET устарела и будет удалена в Django 5.0.

Имя URL: logout

Атрибуты:

next_page¶

URL для перенаправления после выхода из системы. По умолчанию LOGOUT_REDIRECT_URL.

template_name¶

Полное имя шаблона для отображения после выхода пользователя из системы. По умолчанию имеет значение registration/logged_out.html.

redirect_field_name¶

Имя поля GET, содержащего URL для перенаправления после выхода из системы. По умолчанию используется значение 'next'. Переопределяет URL next_page, если передан заданный параметр GET.

Словарь контекстных данных, которые будут добавлены к контекстным данным по умолчанию, переданным в шаблон.

success_url_allowed_hosts¶

set хостов, в дополнение к request.get_host(), которые безопасны для перенаправления после выхода из системы. По умолчанию используется пустое значение set.

Контекст шаблона:

• title: Строка «Logged out», локализована.
• site: Текущий Site, в соответствии с настройкой SITE_ID. Если у вас не установлен фреймворк сайта, это будет установлено в экземпляр RequestSite, который берет имя сайта и домен из текущего HttpRequest.
• site_name: Псевдоним для site.name. Если у вас не установлен фреймворк сайта, это значение будет установлено в значение request.META['SERVER_NAME']. Подробнее о сайтах смотрите Структура «сайтов».

logout_then_login(request, login_url=None)¶

Выводит пользователя из системы при запросе POST, затем перенаправляет на страницу входа в систему.

Имя URL: URL по умолчанию не предоставляется

Дополнительные аргументы:

• login_url: URL страницы входа в систему для перенаправления. По умолчанию settings.LOGIN_URL, если не указан.

Не рекомендуется, начиная с версии 4.1: Поддержка выхода из системы при запросах GET устарела и будет удалена в Django 5.0.

class PasswordChangeView¶

Имя URL: password_change

Позволяет пользователю изменить свой пароль.

Атрибуты:

template_name¶

Полное имя шаблона, который будет использоваться для отображения формы смены пароля. По умолчанию registration/password_change_form.html, если не указано.

success_url¶

URL для перенаправления после успешной смены пароля. По умолчанию 'password_change_done'.

form_class¶

Пользовательская форма «Смена пароля», которая должна принимать аргумент в виде ключевого слова user. Форма отвечает за фактическое изменение пароля пользователя. По умолчанию используется PasswordChangeForm.

Словарь контекстных данных, которые будут добавлены к контекстным данным по умолчанию, переданным в шаблон.

Контекст шаблона:

• form: Форма смены пароля (см. form_class выше).

class PasswordChangeDoneView¶

Имя URL: password_change_done

Страница, отображаемая после того, как пользователь изменил свой пароль.

Атрибуты:

template_name¶

Полное имя шаблона для использования. По умолчанию registration/password_change_done.html, если не указано.

Словарь контекстных данных, которые будут добавлены к контекстным данным по умолчанию, переданным в шаблон.

class PasswordResetView¶

Имя URL: password_reset

Позволяет пользователю сбросить пароль путем генерации ссылки одноразового использования, которая может быть использована для сброса пароля, и отправки этой ссылки на зарегистрированный адрес электронной почты пользователя.

Это представление будет отправлять сообщение электронной почты, если выполняются следующие условия:

• Указанный адрес электронной почты существует в системе.
• Запрашиваемый пользователь активен (User.is_active равно True).
• У запрашиваемого пользователя есть пароль, который можно использовать. Пользователям, отмеченным непригодным паролем (см. set_unusable_password()), не разрешается запрашивать сброс пароля, чтобы предотвратить злоупотребления при использовании внешнего источника аутентификации, например LDAP.

Если какое-либо из этих условий не выполняется, письмо не будет отправлено, но пользователь также не получит никакого сообщения об ошибке. Это предотвращает утечку информации к потенциальным злоумышленникам. Если вы хотите предоставить сообщение об ошибке в этом случае, вы можете подклассифицировать PasswordResetForm и использовать атрибут form_class.

Примечание

Имейте в виду, что отправка электронного письма требует дополнительного времени, поэтому вы можете быть уязвимы к атаке перечисления адресов электронной почты по времени из-за разницы между длительностью запроса сброса для существующего адреса электронной почты и длительностью запроса сброса для несуществующего адреса электронной почты. Чтобы уменьшить накладные расходы, вы можете использовать сторонний пакет, позволяющий отправлять электронные письма асинхронно, например django-mailer.

Атрибуты:

template_name¶

Полное имя шаблона, который будет использоваться для отображения формы сброса пароля. По умолчанию имеет значение registration/password_reset_form.html, если не указано.

form_class¶

Форма, которая будет использоваться для получения email пользователя для сброса пароля. По умолчанию имеет значение PasswordResetForm.

email_template_name¶

Полное имя шаблона, который будет использоваться для создания письма со ссылкой на сброс пароля. По умолчанию имеет значение registration/password_reset_email.html, если не указано.

subject_template_name¶

Полное имя шаблона, который будет использоваться для темы письма со ссылкой на сброс пароля. По умолчанию имеет значение registration/password_reset_subject.txt, если не указано.

token_generator¶

Экземпляр класса для проверки одноразовой ссылки. По умолчанию это будет default_token_generator, это экземпляр django.contrib.auth.tokens.PasswordResetTokenGenerator.

success_url¶

URL для перенаправления после успешного запроса на сброс пароля. По умолчанию 'password_reset_done'.

from_email¶

Действительный адрес электронной почты. По умолчанию Django использует DEFAULT_FROM_EMAIL.

Словарь контекстных данных, которые будут добавлены к контекстным данным по умолчанию, переданным в шаблон.

html_email_template_name¶

Полное имя шаблона, используемого для генерации многокомпонентного письма text/html со ссылкой для сброса пароля. По умолчанию письмо в формате HTML не отправляется.

Словарь контекстных данных, которые будут доступны в шаблоне письма. Его можно использовать для переопределения значений контекста шаблона по умолчанию, перечисленных ниже, например domain.

Контекст шаблона:

• form: Форма (см. form_class выше) для сброса пароля пользователя.

Контекст шаблона электронной почты:

• email: Псевдоним для user.email
• user: Текущий User, в соответствии с полем формы email. Только активные пользователи могут сбрасывать свои пароли (User.is_active is True).
• site_name: Псевдоним для site.name. Если у вас не установлен фреймворк сайта, это значение будет установлено в значение request.META['SERVER_NAME']. Подробнее о сайтах смотрите Структура «сайтов».
• domain: Псевдоним для site.domain. Если у вас не установлен фреймворк сайта, то будет установлено значение request.get_host().
• protocol: http или https
• uid: Первичный ключ пользователя, закодированный в base 64.
• token: Токен для проверки того, что ссылка сброса действительна.

Образец registration/password_reset_email.html (шаблон тела письма):

Someone asked for password reset for email {{ email }}. Follow the link below:
{{ protocol}}://{{ domain }}{% url 'password_reset_confirm' uidb64=uid token=token %}

Тот же контекст шаблона используется для шаблона темы. Тема должна быть однострочной строкой обычного текста.

class PasswordResetDoneView¶

Имя URL: password_reset_done

Страница, отображаемая после того, как пользователь получил по электронной почте ссылку для сброса пароля. Это представление вызывается по умолчанию, если для PasswordResetView не задан явный URL success_url.

Примечание

Если указанный адрес электронной почты не существует в системе, пользователь неактивен или имеет недействительный пароль, пользователь все равно будет перенаправлен на этот вид, но письмо отправлено не будет.

Атрибуты:

template_name¶

Полное имя шаблона для использования. По умолчанию registration/password_reset_done.html, если не указано.

Словарь контекстных данных, которые будут добавлены к контекстным данным по умолчанию, переданным в шаблон.

class PasswordResetConfirmView¶

Имя URL: password_reset_confirm

Представляет форму для ввода нового пароля.

Ключевые аргументы из URL:

• uidb64: Идентификатор пользователя, закодированный в base 64.
• token: Токен для проверки правильности пароля.

Атрибуты:

template_name¶

Полное имя шаблона для отображения представления подтверждения пароля. Значение по умолчанию — registration/password_reset_confirm.html.

token_generator¶

Экземпляр класса для проверки пароля. По умолчанию это будет default_token_generator, это экземпляр django.contrib.auth.tokens.PasswordResetTokenGenerator.

post_reset_login¶

Булево значение, указывающее, следует ли автоматически аутентифицировать пользователя после успешного сброса пароля. По умолчанию имеет значение False.

post_reset_login_backend¶

Пунктирный путь к бэкенду аутентификации, который будет использоваться при аутентификации пользователя, если post_reset_login является True. Требуется, только если у вас настроено несколько AUTHENTICATION_BACKENDS. По умолчанию используется None.

form_class¶

Форма, которая будет использоваться для установки пароля. По умолчанию имеет значение SetPasswordForm.

success_url¶

URL для перенаправления после сброса пароля. По умолчанию 'password_reset_complete'.

Словарь контекстных данных, которые будут добавлены к контекстным данным по умолчанию, переданным в шаблон.

reset_url_token¶

Параметр токена, отображаемый как компонент URL-адресов сброса пароля. По умолчанию имеет значение 'set-password'.

Контекст шаблона:

• form: Форма (см. form_class выше) для установки пароля нового пользователя.
• validlink: Булево, истинно, если ссылка (комбинация uidb64 и token) действительна или еще не использована.

class PasswordResetCompleteView¶

Имя URL: password_reset_complete

Представляет представление, которое информирует пользователя о том, что пароль был успешно изменен.

Атрибуты:

template_name¶

Полное имя шаблона для отображения представления. По умолчанию имеет значение registration/password_reset_complete.html.

Словарь контекстных данных, которые будут добавлены к контекстным данным по умолчанию, переданным в шаблон.

Техничность

Технически, эти переменные становятся доступными в контексте шаблона, только если вы используете RequestContext и включен контекстный процессор 'django.contrib.auth.context_processors.auth'. Он находится в сгенерированном по умолчанию файле настроек. Подробнее см. в RequestContext docs.

Пользователи¶

При отображении шаблона RequestContext в переменной шаблона User хранится текущий зарегистрированный пользователь, либо экземпляр AnonymousUser, либо экземпляр {{ user }}:

{% if user.is_authenticated %}
    <p>Welcome, {{ user.username }}. Thanks for logging in.</p>
{% else %}
    <p>Welcome, new user. Please log in.</p>
{% endif %}

Эта контекстная переменная шаблона недоступна, если не используется RequestContext.

Права¶

Разрешения вошедшего в систему пользователя хранятся в переменной шаблона {{ perms }}. Это экземпляр django.contrib.auth.context_processors.PermWrapper, который является дружественным шаблону прокси разрешения.

Оценка одноатрибутного поиска {{ perms }} как булева является прокси для User.has_module_perms(). Например, чтобы проверить, есть ли у вошедшего пользователя какие-либо разрешения в приложении foo:

Оценка двухуровневого атрибута поиска как булева является прокси для User.has_perm(). Например, чтобы проверить, есть ли у вошедшего пользователя разрешение foo.add_vote:

{% if perms.foo.add_vote %}

Вот более полный пример проверки разрешений в шаблоне:

{% if perms.foo %}
    <p>You have permission to do something in the foo app.</p>
    {% if perms.foo.add_vote %}
        <p>You can vote!</p>
    {% endif %}
    {% if perms.foo.add_driving %}
        <p>You can drive!</p>
    {% endif %}
{% else %}
    <p>You don't have permission to do anything in the foo app.</p>
{% endif %}

Можно также искать разрешения по операторам {% if in %}. Например:

{% if 'foo' in perms %}
    {% if 'foo.add_vote' in perms %}
        <p>In lookup works, too.</p>
    {% endif %}
{% endif %}