Использование системы аутентификации Django

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

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

`User` объекты

User объекты являются основой системы аутентификации. Они обычно представляют людей, взаимодействующих с вашим сайтом, и используются для таких задач, как ограничение доступа, регистрация пользовательских профилей, привязка контента к создателям и т. д. В рамках фреймворка аутентификации Django существует только один тип пользователя, т. е. 'superusers' или администраторские 'staff' пользователи — это просто пользовательские объекты со специальными атрибутами, а не отдельные типы пользовательских объектов.

Основные атрибуты стандартного пользователя:

См. full API documentation для полного справочника, последующая документация ориентирована на выполнение задач.

Создание пользователей

Наиболее прямой способ создания пользователей — использование встроенной функции create_user():

>>> 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()

Если у вас установлен Django admin, вы также можете создавать пользователей интерактивно.

Создание суперпользователей

Создавайте суперпользователей, используя команду createsuperuser:

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

...\> py manage.py createsuperuser --username=joe --email=joe@example.com

Вам будет предложено ввести пароль. После его ввода пользователь будет создан немедленно. Если вы опустите параметры --username или --email, система запросит эти значения.

Изменение паролей

Django не хранит необработанные (открытые текстовые) пароли в модели пользователя, а только хэш (см. документацию о том, как управляются пароли для получения подробной информации). Поэтому не пытайтесь напрямую изменять атрибут пароля пользователя. Именно поэтому для создания пользователя используется вспомогательная функция.

Для изменения пароля пользователя у вас есть несколько вариантов:

manage.py changepassword *username* предлагает метод изменения пароля пользователя из командной строки. Она попросит вас дважды ввести новый пароль. Если они совпадают, новый пароль будет изменён немедленно. Если вы не укажете пользователя, команда попытается изменить пароль пользователя с именем, совпадающим с текущим именем пользователя системы.

Вы также можете программно изменить пароль, используя set_password():

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

Если у вас установлен Django admin, вы также можете изменить пароли пользователей на страницах администрирования системы аутентификации системы аутентификации.

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

Изменение пароля пользователя выведет всех его сессии. Подробности см. в разделе Недействительность сессии при изменении пароля.

Аутентификация пользователей

authenticate(request=None, **credentials) [source]

aauthenticate(request=None, **credentials)

Асинхронная версия: aauthenticate()

Используйте authenticate() для проверки набора учетных данных. Она принимает учетные данные в виде ключевых аргументов, username и password для стандартного случая, сравнивает их с каждым аутентификационным бэкендом и возвращает объект User, если учетные данные подходят для бэкенда. Если учетные данные не подходят ни для одного бэкенда или бэкенд вызывает PermissionDenied, он возвращает None. Например:

from django.contrib.auth import authenticate

user = authenticate(username="john", password="secret")
if user is not None:
    # A backend authenticated the credentials
    ...
else:
    # No backend authenticated the credentials
    ...

request — это необязательный HttpRequest, который передаётся в метод authenticate() аутентификационных бэкэндов.

Примечание

Это низкоуровневый способ аутентификации набора учетных данных; например, он используется в RemoteUserMiddleware. Если вы не создаёте собственную систему аутентификации, вам, вероятно, не придётся этого использовать. Если вам нужно войти в систему пользователю, используйте LoginView.

Разрешения и авторизация

Django имеет встроенную систему разрешений. Она позволяет назначать разрешения конкретным пользователям и группам пользователей.

Она используется сайтом администрирования Django, но вы можете использовать её и в собственном коде.

Сайт администрирования Django использует разрешения следующим образом:

Доступ к просмотру объектов ограничен пользователями с разрешением «просмотр» или «изменение» для данного типа объекта.
Доступ к форме «добавления» и добавлению объекта ограничен пользователями с разрешением «добавить» для данного типа объекта.
Доступ к списку изменений, просмотру формы «изменение» и изменению объекта ограничен пользователями с разрешением «изменить» для данного типа объекта.
Доступ к удалению объекта ограничен пользователями с разрешением «удалить» для данного типа объекта.

Разрешения можно задавать не только по типу объекта, но и по конкретному экземпляру объекта. Используя методы has_view_permission(), has_add_permission(), has_change_permission() и has_delete_permission(), предоставляемые классом ModelAdmin, можно настраивать разрешения для различных экземпляров объектов одного типа.

Объекты User имеют два поля типа «многие ко многим»: groups и user_permissions. Объекты User могут получать доступ к связанным объектам так же, как и любые другие модели Django:

myuser.groups.set([group_list])
myuser.groups.add(group, group, ...)
myuser.groups.remove(group, group, ...)
myuser.groups.clear()
myuser.user_permissions.set([permission_list])
myuser.user_permissions.add(permission, permission, ...)
myuser.user_permissions.remove(permission, permission, ...)
myuser.user_permissions.clear()

Стандартные разрешения

Когда django.contrib.auth указано в вашем параметре INSTALLED_APPS, это гарантирует, что для каждой модели Django, определенной в одной из ваших установленных приложений, будут созданы четыре стандартных разрешения: добавить, изменить, удалить и просмотреть.

Эти разрешения будут созданы при запуске manage.py migrate; в первый раз, когда вы запустите migrate после добавления django.contrib.auth в INSTALLED_APPS, стандартные разрешения будут созданы для всех ранее установленных моделей, а также для любых новых моделей, устанавливаемых в этот момент. После этого она будет создавать стандартные разрешения для новых моделей каждый раз, когда вы запускаете manage.py migrate (функция, которая создает разрешения, связана со сигналом post_migrate).

Предполагая, что у вас есть приложение с app_label foo и моделью с именем Bar, для проверки основных разрешений следует использовать:

добавить: user.has_perm('foo.add_bar')
изменить: user.has_perm('foo.change_bar')
удалить: user.has_perm('foo.delete_bar')
просмотреть: user.has_perm('foo.view_bar')

Модель Permission редко используется напрямую.

Группы

Модели django.contrib.auth.models.Group представляют собой общий способ категоризации пользователей, позволяющий применять разрешения или другие метки к этим пользователям. Пользователь может принадлежать любому количеству групп.

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

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

Программирование создания разрешений

Хотя настраиваемые разрешения могут быть определены в классе Meta модели, вы также можете создавать разрешения напрямую. Например, вы можете создать разрешение can_publish для модели BlogPost в myapp:

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,
)

Затем разрешение можно назначить пользователю User через его атрибут user_permissions или группе Group через его атрибут permissions.

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

Если вы хотите создать разрешения для модели-прокси, передайте for_concrete_model=False в ContentTypeManager.get_for_model(), чтобы получить соответствующий ContentType:

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

Кэширование разрешений

ModelBackend кэширует разрешения в объекте пользователя после первого запроса к ним для проверки разрешений. Это обычно нормально для цикла «запрос-ответ», так как разрешения обычно не проверяются сразу после добавления (например, в админке). Если вы добавляете разрешения и проверяете их сразу после этого, например, в тесте или представлении, проще всего снова получить пользователя из базы данных. Например:

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

Авторизация в веб-запросах

Django использует сессии и промежуточное ПО для подключения системы аутентификации к request objects.

Они предоставляют атрибут request.user и асинхронный метод request.auser в каждом запросе, которые представляют текущего пользователя. Если текущий пользователь не вошел в систему, этот атрибут будет установлен в экземпляр AnonymousUser, в противном случае – в экземпляр User.

Вы можете отличить их с помощью is_authenticated, например так:

if request.user.is_authenticated:
    # Do something for authenticated users.
    ...
else:
    # Do something for anonymous users.
    ...

Или в асинхронном представлении:

user = await request.auser()
if user.is_authenticated:
    # Do something for authenticated users.
    ...
else:
    # Do something for anonymous users.
    ...

Как войти в систему

Если у вас есть аутентифицированный пользователь, которого вы хотите прикрепить к текущей сессии, это делается с помощью функции login().

login(request, user, backend=None) [source]

alogin(request, user, backend=None)

Асинхронный вариант: alogin()

Для входа пользователя в систему из представления используйте функцию login(). Она принимает объект HttpRequest и объект User. login() сохраняет идентификатор пользователя в сессии, используя фреймворк сессий Django.

Обратите внимание, что все данные, установленные во время анонимной сессии, сохраняются в сессии после входа пользователя.

В этом примере показано, как вы можете использовать как authenticate(), так и login():

from django.contrib.auth import authenticate, login


def my_view(request):
    username = request.POST["username"]
    password = request.POST["password"]
    user = authenticate(request, username=username, password=password)
    if user is not None:
        login(request, user)
        # Redirect to a success page.
        ...
    else:
        # Return an 'invalid login' error message.
        ...

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

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

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

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

Как выйти из системы

logout(request) [source]

alogout(request)

Асинхронный вариант: alogout()

Для выхода пользователя, вошедшего в систему через django.contrib.auth.login(), используйте django.contrib.auth.logout() в представлении. Она принимает объект HttpRequest и не имеет возвращаемого значения. Пример:

from django.contrib.auth import logout


def logout_view(request):
    logout(request)
    # Redirect to a success page.

Обратите внимание, что logout() не генерирует исключений, если пользователь не был авторизован.

Когда вы вызываете logout(), данные сессии текущего запроса полностью очищаются. Все существующие данные удаляются. Это предотвращает использование одного и того же веб-браузера другим человеком для входа и получения доступа к данным сессии предыдущего пользователя. Если вы хотите добавить что-либо в сессию, которое будет доступно пользователю сразу после выхода, сделайте это после вызова django.contrib.auth.logout().

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

Прямой способ

Прямой способ ограничить доступ к страницам заключается в проверке 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(f"{settings.LOGIN_URL}?next={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) [source]

В качестве альтернативы, можно использовать удобный декоратор 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/.
Если пользователь авторизован, выполняет представление (view) в обычном режиме. Код представления может предполагать, что пользователь авторизован.

По умолчанию путь, на который пользователь должен быть перенаправлен после успешной авторизации, хранится в параметре строки запроса под названием "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 принимает имена функций представлений и именованные URL-шаблоны. Это позволяет вам свободно переопределять представление входа в вашем файле URLconf, не обновляя настройку.

Примечание

Декоратор login_required НЕ проверяет флаг is_active пользователя, но по умолчанию AUTHENTICATION_BACKENDS отказывается от неактивных пользователей.

См. также

Если вы пишете пользовательские представления для административной части Django (или вам нужна такая же проверка авторизации, как в встроенных представлениях), вы можете найти декоратор django.contrib.admin.views.decorators.staff_member_required() полезной альтернативой login_required().

Изменено в Django 5.1:

Добавлена поддержка обертывания асинхронных функций представления.

Mixin `LoginRequiredMixin`

При использовании представлений на основе классов, вы можете добиться такого же поведения, как с login_required, используя LoginRequiredMixin. Этот миксин должен стоять в самом левом положении в списке наследования.

class LoginRequiredMixin [source]

Если представление использует этот миксин, все запросы от неавторизованных пользователей будут перенаправлены на страницу входа или отобразят ошибку 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"

Примечание

Так же, как и декоратор login_required, этот миксин НЕ проверяет флаг is_active пользователя, но по умолчанию AUTHENTICATION_BACKENDS отклоняет неактивных пользователей.

Декоратор `login_not_required`

Новое в Django 5.1.

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

login_not_required() [source]: Разрешает неавторизованные запросы к этому представлению, когда установлен LoginRequiredMiddleware.

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

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

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

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') [source]

В качестве сокращения вы можете использовать удобный 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): ...

Изменено в Django 5.1:

Добавлена поддержка обертывания асинхронных функций представлений и использования асинхронных вызываемых объектов для проверки.

class UserPassesTestMixin [source]

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

test_func() [source]

Вы должны переопределить метод 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() [source]: Вы также можете переопределить метод 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) [source]

Обычно требуется проверка наличия у пользователя определенного разрешения. По этой причине 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, вызывая представление 403 (HTTP Forbidden) вместо перенаправления на страницу входа.

Если вы хотите использовать 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’s redirect_authenticated_user=True и авторизованный пользователь не имеет всех необходимых разрешений.

Изменено в Django 5.1:

Добавлена поддержка обертывания асинхронных функций представлений.

Миксин `PermissionRequiredMixin`

Для применения проверок разрешений к представлениям на основе классов можно использовать PermissionRequiredMixin:

class PermissionRequiredMixin [source]

Этот миксин, подобно декоратору 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() [source]: Возвращает итерируемый список имен разрешений, используемых миксином. По умолчанию возвращает атрибут permission_required, преобразованный в кортеж при необходимости.

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

Перенаправление неавторизованных запросов в представлениях на основе классов

Для упрощения обработки ограничений доступа в представлениях на основе классов, можно использовать AccessMixin для настройки поведения представления при отказе в доступе. Авторизованным пользователям доступ отказывается с ответом HTTP 403 Forbidden. Анонимные пользователи перенаправляются на страницу входа или получают ответ HTTP 403 Forbidden, в зависимости от атрибута raise_exception.

class AccessMixin [source]

login_url: Значение по умолчанию для get_login_url(). По умолчанию равно None, в этом случае get_login_url() использует значение по умолчанию settings.LOGIN_URL.

permission_denied_message: Значение по умолчанию для get_permission_denied_message(). По умолчанию пустая строка.

redirect_field_name: Значение по умолчанию для get_redirect_field_name(). По умолчанию "next".

raise_exception: Если этот атрибут установлен в True, исключение PermissionDenied генерируется, когда условия не выполнены. Когда значение False (по умолчанию), анонимные пользователи перенаправляются на страницу входа.

get_login_url() [source]: Возвращает URL, на который будут перенаправлены пользователи, не прошедшие проверку. Возвращает login_url, если он задан, или settings.LOGIN_URL в противном случае.

get_permission_denied_message() [source]: Когда raise_exception равен True, этот метод может использоваться для управления сообщением об ошибке, передаваемым обработчику ошибок для отображения пользователю. По умолчанию возвращает атрибут permission_denied_message.

get_redirect_field_name() [source]: Возвращает имя параметра запроса, который будет содержать URL, на который пользователь должен быть перенаправлен после успешного входа. Если вы установите это значение в None, параметр запроса не будет добавлен. По умолчанию возвращает атрибут redirect_field_name.

handle_no_permission() [source]: В зависимости от значения raise_exception, метод либо генерирует исключение PermissionDenied, либо перенаправляет пользователя на login_url, необязательно включая redirect_field_name, если он установлен.

Недействительность сеанса при смене пароля

Если ваш 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) [source]

aupdate_session_auth_hash(request, user)

Асинхронная версия: aupdate_session_auth_hash()

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

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

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:
        ...

Примечание

Поскольку get_session_auth_hash() основан на SECRET_KEY, значения ключа секрета должны быть обновлены, чтобы избежать аннулирования существующих сеансов при обновлении вашего сайта для использования нового секрета. Подробнее см. SECRET_KEY_FALLBACKS.

Представления аутентификации

Django предоставляет несколько представлений, которые вы можете использовать для обработки входа, выхода и управления паролями. Они используют стандартные формы аутентификации, но вы также можете передавать свои собственные формы.

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

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

Существует несколько способов реализации этих представлений в вашем проекте. Самый простой способ — включить предоставленный 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 см. в документации по URL.

Если вы хотите больше контроля над 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"),
    ),
]

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

Все представления аутентификации

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

class LoginView [source]

Имя URL: login

Подробности о работе с именованными шаблонами URL см. в документации по URL.

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

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

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

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

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

extra_context: Словарь данных контекста, который будет добавлен к стандартным данным контекста, передаваемым в шаблон.

redirect_authenticated_user

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

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

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

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

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

get_default_redirect_url() [source]: Возвращает URL для перенаправления после входа. Стандартная реализация находит и возвращает next_page, если он задан, или LOGIN_REDIRECT_URL в противном случае.

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

Если вызван через GET, он отображает форму входа, которая отправляет POST-запрос на тот же 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 %}

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

class LogoutView [source]

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

Имя URL: logout

Атрибуты:

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

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

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

extra_context: Словарь данных контекста, который будет добавлен к стандартным данным контекста, передаваемым в шаблон.

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

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

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

logout_then_login(request, login_url=None) [source]

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

Имя URL: Не указано по умолчанию

Необязательные аргументы:

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

class PasswordChangeView [source]

Имя URL: password_change

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

Атрибуты:

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

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

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

extra_context: Словарь данных контекста, который будет добавлен к стандартным данным контекста, передаваемым в шаблон.

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

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

class PasswordChangeDoneView [source]

Имя URL: password_change_done

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

Атрибуты:

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

extra_context: Словарь данных контекста, который будет добавлен к стандартным данным контекста, передаваемым в шаблон.

class PasswordResetView [source]

Имя 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: Форма, которая будет использоваться для получения адреса электронной почты пользователя для сброса пароля. По умолчанию используется 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.

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

html_email_template_name: Полное имя шаблона для создания multipart электронного письма text/html со ссылкой для сброса пароля. По умолчанию HTML-электронное письмо не отправляется.

extra_email_context: Словарь данных контекста, который будет доступен в шаблоне электронного письма. Его можно использовать для переопределения значений контекста шаблона по умолчанию, например, 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 [source]

Имя URL: password_reset_done

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

Примечание

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

Атрибуты:

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

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

class PasswordResetConfirmView [source]

Имя 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'.

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

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

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

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

class PasswordResetCompleteView [source]

Имя URL: password_reset_complete

Отображает представление, информирующее пользователя об успешном изменении пароля.

Атрибуты:

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

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

Вспомогательные функции

redirect_to_login(next, login_url=None, redirect_field_name='next') [source]

Перенаправляет на страницу входа, а затем обратно на другую страницу после успешного входа.

Обязательные аргументы:

next: URL для перенаправления после успешного входа.

Необязательные аргументы:

login_url: URL страницы входа для перенаправления. По умолчанию — settings.LOGIN_URL, если не указан.
redirect_field_name: Имя поля GET, содержащего URL для перенаправления после входа. Переопределяет next, если передан аргумент GET.

Встроенные формы

Если вы не хотите использовать встроенные представления, но хотите удобства, не прибегая к написанию форм для этой функциональности, система аутентификации предоставляет несколько встроенных форм, расположенных в django.contrib.auth.forms:

Примечание

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

class AdminPasswordChangeForm [source]

Форма, используемая в админском интерфейсе для смены пароля пользователя, включая возможность установки unusable password, что блокирует пользователя от входа с помощью аутентификации по паролю.

Принимает user в качестве первого позиционного аргумента.

Изменено в Django 5.1:

Добавлена возможность отключения (или повторного включения) аутентификации по паролю.

class AdminUserCreationForm [source]

Введено в Django 5.1.1.

Форма, используемая в админском интерфейсе для создания нового пользователя. Наследуется от UserCreationForm.

Включает дополнительное поле usable_password, включенное по умолчанию. Если usable_password включено, оно проверяет, что password1 и password2 не пустые и совпадают, проверяет пароль с помощью validate_password() и устанавливает пароль пользователя с помощью set_password(). Если usable_password отключено, проверка пароля не выполняется, и аутентификация по паролю отключается для пользователя, вызвав set_unusable_password().

class AuthenticationForm [source]

Форма для входа пользователя.

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

confirm_login_allowed(user) [source]

По умолчанию AuthenticationForm отклоняет пользователей, у которых флаг is_active установлен в False. Вы можете изменить это поведение с помощью пользовательской политики, определяющей, какие пользователи могут войти. Сделайте это с помощью настраиваемой формы, которая наследуется от AuthenticationForm и переопределяет метод confirm_login_allowed(). Этот метод должен вызывать ValidationError, если указанный пользователь не может войти.

Например, чтобы разрешить всем пользователям вход независимо от статуса «активный»:

from django.contrib.auth.forms import AuthenticationForm


class AuthenticationFormWithInactiveUsersOkay(AuthenticationForm):
    def confirm_login_allowed(self, user):
        pass

(В этом случае вам также нужно использовать механизм аутентификации, который разрешает вход неактивным пользователям, например, AllowAllUsersModelBackend.)

Или для разрешения входа только некоторым активным пользователям:

class PickyAuthenticationForm(AuthenticationForm):
    def confirm_login_allowed(self, user):
        if not user.is_active:
            raise ValidationError(
                _("This account is inactive."),
                code="inactive",
            )
        if user.username.startswith("b"):
            raise ValidationError(
                _("Sorry, accounts starting with 'b' aren't welcome here."),
                code="no_b_users",
            )

class BaseUserCreationForm [source]

ModelForm для создания нового пользователя. Это рекомендуемый базовый класс, если вам нужно настроить форму создания пользователя.

Он имеет три поля: username (из модели пользователя), password1 и password2. Он проверяет, что password1 и password2 совпадают, проверяет пароль с помощью validate_password() и устанавливает пароль пользователя с помощью set_password().

class PasswordChangeForm [source]: Форма, позволяющая пользователю изменить свой пароль.

class PasswordResetForm [source]

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

send_mail(subject_template_name, email_template_name, context, from_email, to_email, html_email_template_name=None) [source]

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

Параметры:

subject_template_name – шаблон для темы.
email_template_name – шаблон для тела электронного письма.
context – контекст, передаваемый в subject_template, email_template и html_email_template (если он не None).
from_email – адрес электронной почты отправителя.
to_email – адрес электронной почты получателя.
html_email_template_name – шаблон для HTML-тела; по умолчанию None, в этом случае отправляется текстовое письмо.

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

class SetPasswordForm [source]: Форма, которая позволяет пользователю изменить свой пароль, не вводя старый пароль.

class UserChangeForm [source]: Форма, используемая в админском интерфейсе для изменения информации и разрешений пользователя.

class UserCreationForm [source]: Наследуется от BaseUserCreationForm. Для предотвращения путаницы с похожими именами пользователей форма не допускает имён пользователей, отличающихся только регистром.

Данные аутентификации в шаблонах

Текущий вошедший в систему пользователь и его права доступа доступны в контексте шаблона, когда вы используете RequestContext.

Технические детали

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

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

При отрисовке шаблона 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:

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

Управление пользователями в админке

Когда у вас установлены как django.contrib.admin, так и django.contrib.auth, админка предоставляет удобный способ просмотра и управления пользователями, группами и правами доступа. Пользователи могут создаваться и удаляться как любые модели Django. Группы могут создаваться, а права доступа могут назначаться пользователям или группам. Также сохраняется и отображается журнал изменений, внесенных пользователями в модели через админку.

Создание пользователей

Вы должны увидеть ссылку на «Пользователи» в разделе «Auth» на главной странице админки. Страница «Добавить пользователя» в админке отличается от стандартных страниц админки тем, что требует выбора имени пользователя и пароля перед редактированием остальных полей пользователя. Кроме того, на этой странице можно выбрать имя пользователя и отключить аутентификацию по паролю для пользователя.

Обратите внимание: если вы хотите, чтобы учетная запись пользователя могла создавать пользователей через сайт админки Django, необходимо предоставить им право на добавление пользователей и изменение пользователей (то есть права «Добавить пользователя» и «Изменить пользователя»). Если учетная запись имеет право добавлять пользователей, но не изменять их, эта учетная запись не сможет добавлять пользователей. Почему? Потому что если у вас есть право добавлять пользователей, у вас есть возможность создавать суперпользователей, которые, в свою очередь, могут изменять других пользователей. Django требует прав на добавление и изменение как меры безопасности.

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

Изменение паролей

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

© Django Software Foundation and individual contributors
Licensed under the BSD License.
https://docs.djangoproject.com/en/5.2/topics/auth/default/

Использование системы аутентификации Django

User объекты

Создание пользователей

Создание суперпользователей

Изменение паролей

Аутентификация пользователей

Разрешения и авторизация

Стандартные разрешения

Группы

Программирование создания разрешений

Кэширование разрешений

Модели-прокси

Авторизация в веб-запросах

Как войти в систему

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

Как выйти из системы

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

Прямой способ

Декоратор login_required

Mixin LoginRequiredMixin

Декоратор login_not_required

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

Декоратор permission_required

Миксин PermissionRequiredMixin

Перенаправление неавторизованных запросов в представлениях на основе классов

Недействительность сеанса при смене пароля

Представления аутентификации

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

Все представления аутентификации

Вспомогательные функции

Встроенные формы

Данные аутентификации в шаблонах

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

Права доступа

Управление пользователями в админке

Создание пользователей

Изменение паролей

`User` объекты

Декоратор `login_required`

Mixin `LoginRequiredMixin`

Декоратор `login_not_required`

Декоратор `permission_required`

Миксин `PermissionRequiredMixin`