Использование системы аутентификации 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)

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 объекты имеют два поля типа «многие ко многим»: 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
)

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

Класс 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)

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

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

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

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

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

Как выйти из системы пользователю

logout(request)

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)

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

from django.contrib.auth import views as auth_views

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

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

Миксин LoginRequiredMixin

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

class LoginRequiredMixin

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

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

from django.contrib.auth.mixins import LoginRequiredMixin


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

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

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

Вы можете выполнить свою проверку на 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')

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

from django.contrib.auth.decorators import user_passes_test


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


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

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

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

login_url

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

redirect_field_name

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

Например:

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

class UserPassesTestMixin

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

test_func()

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

from django.contrib.auth.mixins import UserPassesTestMixin


class MyView(UserPassesTestMixin, View):
    def test_func(self):
        return self.request.user.email.endswith("@example.com")

get_test_func()

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

Укладка UserPassesTestMixin

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

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


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


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

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

Декоратор permission_required

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

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

from django.contrib.auth.decorators import permission_required


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

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

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

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

from django.contrib.auth.decorators import permission_required


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

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

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

Миксин PermissionRequiredMixin

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

class PermissionRequiredMixin

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

from django.contrib.auth.mixins import PermissionRequiredMixin


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

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

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

get_permission_required()

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

has_permission()

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

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

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

class AccessMixin

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

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

get_permission_denied_message()

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

get_redirect_field_name()

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

handle_no_permission()

В зависимости от значения 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)

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

Имя URL-адреса: login

См. документацию по URL-адресам для получения подробной информации об использовании именованных шаблонов URL-адресов.

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

template_name

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

next_page

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

redirect_field_name

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

authentication_form

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

extra_context

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

redirect_authenticated_user

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

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

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

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

success_url_allowed_hosts

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

get_default_redirect_url()

Возвращает 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

Выводит пользователя из системы по 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)

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

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

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

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

class PasswordChangeView

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

Имя URL: password_change_done

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

Атрибуты:

template_name

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

extra_context

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

class PasswordResetView

Имя URL: password_reset

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

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

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

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

Примечание

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

Атрибуты:

template_name

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

form_class

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

Полное имя шаблона для генерации многочастного электронного письма 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

Имя URL: password_reset_done

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

Примечание

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

Атрибуты:

template_name

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

extra_context

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

class PasswordResetConfirmView

Имя URL: password_reset_confirm

Отображает форму для ввода нового пароля.

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

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

Атрибуты:

template_name

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

token_generator

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

post_reset_login

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

post_reset_login_backend

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

form_class

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

success_url

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

extra_context

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

reset_url_token

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

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

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

class PasswordResetCompleteView

Имя URL: password_reset_complete

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

Атрибуты:

template_name

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

extra_context

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

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

redirect_to_login(next, login_url=None, redirect_field_name='next')

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

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

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

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

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

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

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

class AdminPasswordChangeForm

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

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

class AuthenticationForm

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

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

confirm_login_allowed(user)

По умолчанию 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

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

class PasswordResetForm

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

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

Использует аргументы для отправки 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

Форма, позволяющая пользователю изменить пароль без ввода старого пароля.

class UserChangeForm

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

class BaseUserCreationForm

Новое в Django 4.2.

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

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

class UserCreationForm

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

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

В более ранних версиях, UserCreationForm не сохранял поля форм many-to-many для пользовательской модели.

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

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

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

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

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

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