Django login form error

<form action="/your-name/" method="post">
    <label for="your_name">Your name: </label>
    <input id="your_name" type="text" name="your_name" value="{{ current_name }}">
    <input type="submit" value="OK">
</form>

The Form class¶

We already know what we want our HTML form to look like. Our starting point for
it in Django is this:

from django import forms

class NameForm(forms.Form):
    your_name = forms.CharField(label='Your name', max_length=100)

This defines a Form class with a single field (your_name). We’ve
applied a human-friendly label to the field, which will appear in the
<label> when it’s rendered (although in this case, the label
we specified is actually the same one that would be generated automatically if
we had omitted it).

The field’s maximum allowable length is defined by
max_length. This does two things. It puts a
maxlength="100" on the HTML <input> (so the browser should prevent the
user from entering more than that number of characters in the first place). It
also means that when Django receives the form back from the browser, it will
validate the length of the data.

A Form instance has an is_valid() method, which runs
validation routines for all its fields. When this method is called, if all
fields contain valid data, it will:

• return True
• place the form’s data in its cleaned_data attribute.

The whole form, when rendered for the first time, will look like:

<label for="your_name">Your name: </label>
<input id="your_name" type="text" name="your_name" maxlength="100" required>

Note that it does not include the <form> tags, or a submit button.
We’ll have to provide those ourselves in the template.

The view¶

Form data sent back to a Django website is processed by a view, generally the
same view which published the form. This allows us to reuse some of the same
logic.

To handle the form we need to instantiate it in the view for the URL where we
want it to be published:

from django.http import HttpResponseRedirect
from django.shortcuts import render

from .forms import NameForm

def get_name(request):
    # if this is a POST request we need to process the form data
    if request.method == 'POST':
        # create a form instance and populate it with data from the request:
        form = NameForm(request.POST)
        # check whether it's valid:
        if form.is_valid():
            # process the data in form.cleaned_data as required
            # ...
            # redirect to a new URL:
            return HttpResponseRedirect('/thanks/')

    # if a GET (or any other method) we'll create a blank form
    else:
        form = NameForm()

    return render(request, 'name.html', {'form': form})

If we arrive at this view with a GET request, it will create an empty form
instance and place it in the template context to be rendered. This is what we
can expect to happen the first time we visit the URL.

If the form is submitted using a POST request, the view will once again
create a form instance and populate it with data from the request: form =
NameForm(request.POST) This is called “binding data to the form” (it is now
a bound form).

We call the form’s is_valid() method; if it’s not True, we go back to
the template with the form. This time the form is no longer empty (unbound)
so the HTML form will be populated with the data previously submitted, where it
can be edited and corrected as required.

If is_valid() is True, we’ll now be able to find all the validated form
data in its cleaned_data attribute. We can use this data to update the
database or do other processing before sending an HTTP redirect to the browser
telling it where to go next.

The template¶

We don’t need to do much in our name.html template:

<form action="/your-name/" method="post">
    {% csrf_token %}
    {{ form }}
    <input type="submit" value="Submit">
</form>

All the form’s fields and their attributes will be unpacked into HTML markup
from that {{ form }} by Django’s template language.

We now have a working web form, described by a Django Form, processed
by a view, and rendered as an HTML <form>.

That’s all you need to get started, but the forms framework puts a lot more at
your fingertips. Once you understand the basics of the process described above,
you should be prepared to understand other features of the forms system and
ready to learn a bit more about the underlying machinery.

forms.py¶

from django import forms

class ContactForm(forms.Form):
    subject = forms.CharField(max_length=100)
    message = forms.CharField(widget=forms.Textarea)
    sender = forms.EmailField()
    cc_myself = forms.BooleanField(required=False)

Field data¶

Whatever the data submitted with a form, once it has been successfully
validated by calling is_valid() (and is_valid() has returned True),
the validated form data will be in the form.cleaned_data dictionary. This
data will have been nicely converted into Python types for you.

In the contact form example above, cc_myself will be a boolean value.
Likewise, fields such as IntegerField and FloatField convert
values to a Python int and float respectively.

Here’s how the form data could be processed in the view that handles this form:

from django.core.mail import send_mail

if form.is_valid():
    subject = form.cleaned_data['subject']
    message = form.cleaned_data['message']
    sender = form.cleaned_data['sender']
    cc_myself = form.cleaned_data['cc_myself']

    recipients = ['info@example.com']
    if cc_myself:
        recipients.append(sender)

    send_mail(subject, message, sender, recipients)
    return HttpResponseRedirect('/thanks/')

Some field types need some extra handling. For example, files that are uploaded
using a form need to be handled differently (they can be retrieved from
request.FILES, rather than request.POST). For details of how to handle
file uploads with your form, see Binding uploaded files to a form.

# In your template:
{{ form }}

# In form_snippet.html:
{% for field in form %}
    <div class="fieldWrapper">
        {{ field.errors }}
        {{ field.label_tag }} {{ field }}
    </div>
{% endfor %}

settings.py¶

from django.forms.renderers import TemplatesSetting

class CustomFormRenderer(TemplatesSetting):
    form_template_name = "form_snippet.html"

FORM_RENDERER = "project.settings.CustomFormRenderer"

class MyForm(forms.Form):
    template_name = "form_snippet.html"
    ...

def index(request):
    form = MyForm()
    rendered_form = form.render("form_snippet.html")
    context = {'form': rendered_form}
    return render(request, 'index.html', context)

Changed in Django 4.0:

Template rendering of forms was added.

Changed in Django 4.1:

The ability to set the default form_template_name on the form renderer
was added.

<p><label for="id_subject">Subject:</label>
    <input id="id_subject" type="text" name="subject" maxlength="100" required></p>
<p><label for="id_message">Message:</label>
    <textarea name="message" id="id_message" required></textarea></p>
<p><label for="id_sender">Sender:</label>
    <input type="email" name="sender" id="id_sender" required></p>
<p><label for="id_cc_myself">Cc myself:</label>
    <input type="checkbox" name="cc_myself" id="id_cc_myself"></p>

{{ form.non_field_errors }}
<div class="fieldWrapper">
    {{ form.subject.errors }}
    <label for="{{ form.subject.id_for_label }}">Email subject:</label>
    {{ form.subject }}
</div>
<div class="fieldWrapper">
    {{ form.message.errors }}
    <label for="{{ form.message.id_for_label }}">Your message:</label>
    {{ form.message }}
</div>
<div class="fieldWrapper">
    {{ form.sender.errors }}
    <label for="{{ form.sender.id_for_label }}">Your email address:</label>
    {{ form.sender }}
</div>
<div class="fieldWrapper">
    {{ form.cc_myself.errors }}
    <label for="{{ form.cc_myself.id_for_label }}">CC yourself?</label>
    {{ form.cc_myself }}
</div>

<div class="fieldWrapper">
    {{ form.subject.errors }}
    {{ form.subject.label_tag }}
    {{ form.subject }}
</div>

Rendering form error messages¶

The price of this flexibility is a bit more work. Until now we haven’t had to
worry about how to display form errors, because that’s taken care of for us. In
this example we have had to make sure we take care of any errors for each field
and any errors for the form as a whole. Note {{ form.non_field_errors }} at
the top of the form and the template lookup for errors on each field.

Using {{ form.name_of_field.errors }} displays a list of form errors,
rendered as an unordered list. This might look like:

<ul class="errorlist">
    <li>Sender is required.</li>
</ul>

The list has a CSS class of errorlist to allow you to style its appearance.
If you wish to further customize the display of errors you can do so by looping
over them:

{% if form.subject.errors %}
    <ol>
    {% for error in form.subject.errors %}
        <li><strong>{{ error|escape }}</strong></li>
    {% endfor %}
    </ol>
{% endif %}

Non-field errors (and/or hidden field errors that are rendered at the top of
the form when using helpers like form.as_p()) will be rendered with an
additional class of nonfield to help distinguish them from field-specific
errors. For example, {{ form.non_field_errors }} would look like:

<ul class="errorlist nonfield">
    <li>Generic validation error</li>
</ul>

See The Forms API for more on errors, styling, and working with form
attributes in templates.

{% for field in form %}
    <div class="fieldWrapper">
        {{ field.errors }}
        {{ field.label_tag }} {{ field }}
        {% if field.help_text %}
        <p class="help">{{ field.help_text|safe }}</p>
        {% endif %}
    </div>
{% endfor %}

{% if field.is_hidden %}
   {# Do something special #}
{% endif %}

{% if field.use_fieldset %}
  <fieldset>
  {% if field.label %}{{ field.legend_tag }}{% endif %}
{% else %}
  {% if field.label %}{{ field.label_tag }}{% endif %}
{% endif %}
{{ field }}
{% if field.use_fieldset %}</fieldset>{% endif %}

See also

For a complete list of attributes and methods, see
BoundField.

>>> 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 %}