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

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

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

User объекты

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

Основные атрибуты пользователя по умолчанию:

• username
• password
• email
• first_name
• last_name

См. 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 5.0:

aauthenticate() функция была добавлена.

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

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

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

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

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

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

User объекты имеют два поля many-to-many: 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.

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

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

Backend 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 использует сессии и middleware для подключения системы аутентификации к 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.
        ...

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

Был добавлен метод alogin()

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

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

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

В случаях 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().

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

Функция alogout() была добавлена.

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

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

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

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

Миксин 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_not_required

Если 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 Запрещено) вместо перенаправления на страницу входа.

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

Миксин 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 Запрещено. Анонимным пользователям выполняется переадресация на страницу входа или отображается ответ HTTP 403 Запрещено, в зависимости от атрибута 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:
        ...

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

aupdate_session_auth_hash() функция была добавлена.

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

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-адреса перенаправления для файлов изображений на вашем сайте. Чтобы избежать утечки информации об «отпечатке социальных сетей», размещайте все изображения и значок избранного на отдельном домене.

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

success_url_allowed_hosts

set хостов, помимо 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. Если модуль `sites` не установлен, будет установлено значение RequestSite, которое определяет имя и домен сайта из текущего HttpRequest.
• site_name: Псевдоним для site.name. Если модуль `sites` не установлен, это будет значение request.META['SERVER_NAME']. Подробнее о модуле `sites` см. Модуль «sites».

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 не задал явное значение URL-адреса success_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]

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

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

• 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 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 PasswordChangeForm [source]

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

class PasswordResetForm [source]

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

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

Использует переданные аргументы для отправки EmailMultiAlternatives. Может быть переопределена для настройки способа отправки письма пользователю.

Параметры:

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 BaseUserCreationForm [source]

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

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

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

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

class UserCreationForm [source]

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

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

Текущий вошедший в систему пользователь и его разрешения доступны в контексте шаблона при использовании 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 требует разрешения на добавление и изменение как дополнительную меру безопасности.

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

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

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