Использование системы аутентификации 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 админ-панель, вы также можете создать пользователей интерактивно.

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

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

$ python 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 админ-панель, вы также можете изменить пароли пользователей на страницах администрирования системы аутентификации системы аутентификации.

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

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

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

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

Используйте 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() аутентификационных бэкендов.

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

Был добавлен необязательный аргумент request.

Примечание

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

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

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

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

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

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

Разрешения могут быть заданы не только для типа объекта, но и для конкретного экземпляра объекта. Используя методы 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')

Модель 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.

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

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

    ...

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

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

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

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

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

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

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

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

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

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

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

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]

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

from django.contrib.auth import logout

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

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

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

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

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

Простой, прямой способ ограничения доступа к страницам — это проверка request.user.is_authenticated и переадресация на страницу входа:

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

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

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

from django.shortcuts import render

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

Декоратор login_required

login_required(redirect_field_name='next', login_url=None) [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, без необходимости обновления настройки.

Миксин LoginRequired

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

class LoginRequiredMixin

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

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

from django.contrib.auth.mixins import LoginRequiredMixin

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

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

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

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

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

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

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

from django.contrib.auth.decorators import permission_required

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

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

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

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

from django.contrib.auth.decorators import permission_required

@permission_required('polls.can_vote', 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.can_vote', raise_exception=True)
def my_view(request):
    ...

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

Mixin PermissionRequiredMixin

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

class PermissionRequiredMixin

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

from django.contrib.auth.mixins import PermissionRequiredMixin

class MyView(PermissionRequiredMixin, View):
    permission_required = 'polls.can_vote'
    # Or multiple of permissions:
    permission_required = ('polls.can_open', 'polls.can_edit')

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

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

get_permission_required()

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

has_permission()

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

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

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

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

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

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

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

Добавлена ротация ключа сессии.

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

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. Подробности реализации см. в разделе "Использование представлений".

login(request, template_name=`registration/login.html`, redirect_field_name='next', authentication_form=AuthenticationForm, extra_context=None, redirect_authenticated_user=False)

Устарело начиная с версии 1.11: Функциональное представление login должно быть заменено на представление на основе класса LoginView.

Необязательные аргументы этого представления аналогичны атрибутам представления на основе класса LoginView.

class LoginView

Добавлена в Django 1.11.

Имя URL: login

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

Атрибуты:

• template_name: Имя шаблона для отображения представления, используемого для входа пользователя. По умолчанию registration/login.html.
• redirect_field_name: Имя поля GET, содержащего URL для перенаправления после входа. По умолчанию next.
• authentication_form: Вызываемый объект (обычно просто класс формы) для использования в процессе аутентификации. По умолчанию AuthenticationForm.
• extra_context: Словарь данных контекста, который будет добавлен к стандартным данным контекста, передаваемым в шаблон.

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

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

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

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

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

Вот что делает 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 setup the password_reset view in your URLconf #}
<p><a href="{% url 'password_reset' %}">Lost password?</a></p>

{% endblock %}

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

logout(request, next_page=None, template_name='registration/logged_out.html', redirect_field_name='next', extra_context=None)

Устарело начиная с версии 1.11: Функциональное представление logout должно быть заменено на представление на основе класса LogoutView.

Необязательные аргументы этого представления аналогичны атрибутам представления на основе класса LogoutView.

class LogoutView

Новое в Django 1.11.

Выход пользователя.

Имя URL: logout

Атрибуты:

• next_page: URL для перенаправления после выхода. По умолчанию settings.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, extra_context=None)

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

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

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

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

Устарело начиная с версии 1.11: Неиспользуемый параметр extra_context устарел и будет удален в Django 2.1.

password_change(request, template_name='registration/password_change_form.html', post_change_redirect=None, password_change_form=PasswordChangeForm, extra_context=None)

Устарело начиная с версии 1.11: Функциональное представление password_change должно быть заменено на представление с классом PasswordChangeView.

Дополнительные аргументы этого представления аналогичны атрибутам представления с классом PasswordChangeView, за исключением аргументов post_change_redirect и password_change_form, которые соответствуют атрибутам success_url и form_class представления с классом.

class PasswordChangeView

Новое в Django 1.11.

Имя URL: password_change

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

Атрибуты:

• template_name: Полное имя шаблона для отображения формы изменения пароля. По умолчанию registration/password_change_form.html если не указано.
• success_url: URL для перенаправления после успешной смены пароля.
• form_class: Кастомная форма «смены пароля», которая должна принимать user аргумент. Форма отвечает за фактическое изменение пароля пользователя. По умолчанию PasswordChangeForm.
• extra_context: Словарь данных контекста, который будет добавлен к стандартным данным контекста, передаваемым в шаблон.

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

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

password_change_done(request, template_name='registration/password_change_done.html', extra_context=None)

Устарело начиная с версии 1.11: Функциональное представление password_change_done должно быть заменено на представление с классом PasswordChangeDoneView.

Дополнительные аргументы этого представления аналогичны атрибутам представления с классом PasswordChangeDoneView.

class PasswordChangeDoneView

Новое в Django 1.11.

Имя URL: password_change_done

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

Атрибуты:

• template_name: Полное имя шаблона для использования. По умолчанию registration/password_change_done.html если не указано.
• extra_context: Словарь данных контекста, который будет добавлен к стандартным данным контекста, передаваемым в шаблон.

password_reset(request, template_name='registration/password_reset_form.html', email_template_name='registration/password_reset_email.html', subject_template_name='registration/password_reset_subject.txt', password_reset_form=PasswordResetForm, token_generator=default_token_generator, post_reset_redirect=None, from_email=None, extra_context=None, html_email_template_name=None, extra_email_context=None)

Устарело начиная с версии 1.11: Функциональное представление password_reset должно быть заменено на представление с классом PasswordResetView.

Дополнительные аргументы этого представления аналогичны атрибутам представления с классом PasswordResetView, за исключением аргументов post_reset_redirect и password_reset_form, которые соответствуют атрибутам success_url и form_class представления с классом.

class PasswordResetView

Новое в Django 1.11.

Имя URL: password_reset

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

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

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

Атрибуты:

• 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 для перенаправления после успешного запроса сброса пароля.
• from_email: Действительный адрес электронной почты. По умолчанию Django использует DEFAULT_FROM_EMAIL.
• extra_context: Словарь данных контекста, который будет добавлен к стандартным данным контекста, передаваемым шаблону.
• html_email_template_name: Полное имя шаблона для создания письма multipart с ссылкой на сброс пароля. По умолчанию HTML письмо не отправляется.
• extra_email_context: Словарь данных контекста, которые будут доступны в шаблоне письма.

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

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

Контекст шаблона письма:

• email: Псевдоним для user.email
• user: Текущий User, в соответствии с полем формы email. Только активные пользователи могут сбросить свои пароли (User.is_active is True).
• site_name: Псевдоним для site.name. Если у вас не установлен фреймворк сайта, это будет значение request.META['SERVER_NAME']. Подробнее о сайтах см. Фреймворк “sites”.
• 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 %}

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

password_reset_done(request, template_name='registration/password_reset_done.html', extra_context=None)

Устарело начиная с версии 1.11: Функциональный вид password_reset_done должен быть заменен на вид с классами PasswordResetDoneView.

Необязательные аргументы этого вида аналогичны атрибутам вида с классами PasswordResetDoneView.

class PasswordResetDoneView

Новое в Django 1.11.

Имя URL: password_reset_done

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

Примечание

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

Атрибуты:

• template_name: Полное имя шаблона для использования. По умолчанию registration/password_reset_done.html если не указано.
• extra_context: Словарь данных контекста, который будет добавлен к стандартным данным контекста, передаваемым шаблону.

password_reset_confirm(request, uidb64=None, token=None, template_name='registration/password_reset_confirm.html', token_generator=default_token_generator, set_password_form=SetPasswordForm, post_reset_redirect=None, extra_context=None)

Устарело начиная с версии 1.11: Функциональный вид password_reset_confirm должен быть заменен на вид с классами PasswordResetConfirmView.

Необязательные аргументы этого вида аналогичны атрибутам вида с классами PasswordResetConfirmView за исключением аргументов post_reset_redirect и set_password_form, которые сопоставляются с атрибутами success_url и form_class вида с классами.

class PasswordResetConfirmView

Новое в Django 1.11.

Имя 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: Словарь данных контекста, который будет добавлен к стандартным данным контекста, передаваемым шаблону.

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

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

password_reset_complete(request, template_name='registration/password_reset_complete.html', extra_context=None)

Устарело начиная с версии 1.11: Функциональный вид password_reset_complete должен быть заменен на вид с классами PasswordResetCompleteView.

Необязательные аргументы этого вида аналогичны атрибутам вида с классами PasswordResetCompleteView.

class PasswordResetCompleteView

Новое в Django 1.11.

Имя 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 forms.ValidationError(
                _("This account is inactive."),
                code='inactive',
            )
        if user.username.startswith('b'):
            raise forms.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 UserCreationForm

A ModelForm для создания нового пользователя.

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

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

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

{% if perms.foo.can_vote %}

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

{% if perms.foo %}
    <p>You have permission to do something in the foo app.</p>
    {% if perms.foo.can_vote %}
        <p>You can vote!</p>
    {% endif %}
    {% if perms.foo.can_drive %}
        <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.can_vote' in perms %}
        <p>In lookup works, too.</p>
    {% endif %}
{% endif %}

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

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

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

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

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

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

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

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