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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

• добавление: user.has_perm('foo.add_bar')
• изменение: user.has_perm('foo.change_bar')
• удаление: user.has_perm('foo.delete_bar')

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

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_bar')

    permission = Permission.objects.get(codename='change_bar')
    user.user_permissions.add(permission)

    # Checking the cached permission set
    user.has_perm('myapp.change_bar')  # 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_bar')  # True

    ...

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

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

В более ранних версиях, когда вы вручную входите в систему пользователя, вы обязательно должны успешно аутентифицировать пользователя с помощью authenticate() перед вызовом login(). Теперь вы можете установить backend с помощью нового аргумента backend.

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

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

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

url(r'^accounts/login/$', auth_views.login),

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

Миксин LoginRequired

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

class LoginRequiredMixin

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

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

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

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

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

В более старых версиях параметр permission работал только со строками, списками и кортежами вместо строк и любых итерируемых объектов.

Mixin PermissionRequiredMixin

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

class PermissionRequiredMixin

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

Этот миксин, как и декоратор 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

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

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

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

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

Существуют разные способы реализации этих представлений в вашем проекте. Самый простой способ — включить предоставленный URLconf в django.contrib.auth.urls в вашем собственном URLconf, например:

urlpatterns = [
    url('^', include('django.contrib.auth.urls')),
]

Это включит следующие шаблоны URL:

^login/$ [name='login']
^logout/$ [name='logout']
^password_change/$ [name='password_change']
^password_change/done/$ [name='password_change_done']
^password_reset/$ [name='password_reset']
^password_reset/done/$ [name='password_reset_done']
^reset/(?P<uidb64>[0-9A-Za-z_\-]+)/(?P<token>[0-9A-Za-z]{1,13}-[0-9A-Za-z]{1,20})/$ [name='password_reset_confirm']
^reset/done/$ [name='password_reset_complete']

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

Если вы хотите больше контроля над вашими URL, вы можете ссылаться на конкретное представление в вашем URLconf:

from django.contrib.auth import views as auth_views

urlpatterns = [
    url('^change-password/$', auth_views.password_change),
]

Представления имеют необязательные аргументы, которые вы можете использовать для изменения поведения представления. Например, если вы хотите изменить имя шаблона, используемого представлением, вы можете предоставить аргумент template_name. Способ сделать это — предоставить ключевые аргументы в URLconf; они будут переданы представлению. Например:

urlpatterns = [
    url(
        '^change-password/$',
        auth_views.password_change,
        {'template_name': 'change-password.html'}
    ),
]

Все представления возвращают экземпляр TemplateResponse, что позволяет легко настроить данные ответа перед рендерингом. Способ сделать это — обернуть представление в ваше собственное представление:

from django.contrib.auth import views

def change_password(request):
    template_response = views.password_change(request)
    # Do something with `template_response`
    return template_response

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

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

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

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

Имя URL: login

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

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

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

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

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

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

Устарело начиная с версии 1.9: Параметр current_app устарел и будет удалён в Django 2.0. Звонящие должны установить request.current_app вместо него.

Введено в Django 1.10:

Параметр redirect_authenticated_user был добавлен.

Вот что делает django.contrib.auth.views.login:

• Если вызвано через 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 через дополнительные аргументы представлению в вашем URLconf. Например, эта строка URLconf будет использовать myapp/login.html вместо этого:

url(r'^accounts/login/$', auth_views.login, {'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', current_app=None, extra_context=None)

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

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

Устарело начиная с версии 1.9: Параметр current_app устарел и будет удален в Django 2.0. Звонящие должны установить request.current_app вместо этого.

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

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

logout_then_login(request, login_url=None, current_app=None, extra_context=None)

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

Имя URL: Не предоставлено по умолчанию

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

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

Устарело начиная с версии 1.9: Параметр current_app устарел и будет удален в Django 2.0. Звонящие должны установить request.current_app вместо этого.

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

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

Имя URL: password_change

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

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

Устарело начиная с версии 1.9: Параметр current_app устарел и будет удален в Django 2.0. Звонящие должны установить request.current_app вместо этого.

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

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

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

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

Имя URL: password_change_done

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

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

Устарело начиная с версии 1.9: Параметр current_app устарел и будет удален в Django 2.0. Звонящие должны установить request.current_app вместо этого.

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, current_app=None, extra_context=None, html_email_template_name=None, extra_email_context=None)

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

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

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

Имя URL: password_reset

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

• 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, это экземпляр django.contrib.auth.tokens.PasswordResetTokenGenerator.
• post_reset_redirect: URL для перенаправления после успешного запроса сброса пароля.
• from_email: Действительный адрес электронной почты. По умолчанию Django использует DEFAULT_FROM_EMAIL.
• current_app: Подсказка, указывающая, в каком приложении содержится текущий вид. Дополнительная информация о стратегии разрешения имен URL приведена в разделе стратегии разрешения URL с именованными пространствами.
• extra_context: Словарь данных контекста, которые будут добавлены к стандартным данным контекста, передаваемым шаблону.
• html_email_template_name: Полное имя шаблона для генерации письма в формате text/html со ссылкой на сброс пароля. По умолчанию HTML-письмо не отправляется.
• extra_email_context: Словарь данных контекста, которые будут доступны в шаблоне письма.

Устаревшее с версии 1.9: Параметр current_app устарел и будет удален в Django 2.0. Вызывающие стороны должны установить request.current_app вместо него.

Новое в Django 1.9:

Параметр extra_email_context был добавлен.

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

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

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

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

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

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

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

Имя URL: password_reset_done

Примечание

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

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

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

Устаревшее с версии 1.9: Параметр current_app устарел и будет удален в Django 2.0. Вызывающие стороны должны установить request.current_app вместо него.

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, current_app=None, extra_context=None)

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

Имя URL: password_reset_confirm

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

• uidb64: Идентификатор пользователя, закодированный в формате base 64. По умолчанию используется None.
• token: Токен, проверяющий, что пароль действителен. По умолчанию используется None.
• template_name: Полное имя шаблона для отображения представления подтверждения пароля. Значение по умолчанию — registration/password_reset_confirm.html.
• token_generator: Экземпляр класса для проверки пароля. По умолчанию используется default_token_generator, это экземпляр django.contrib.auth.tokens.PasswordResetTokenGenerator.
• set_password_form: Форма, которая будет использоваться для установки пароля. По умолчанию используется SetPasswordForm
• post_reset_redirect: URL для перенаправления после сброса пароля. По умолчанию используется None.
• current_app: Подсказка, указывающая, в каком приложении содержится текущий вид. Дополнительная информация о стратегии разрешения имен URL приведена в разделе стратегии разрешения URL с именованными пространствами.
• extra_context: Словарь данных контекста, которые будут добавлены к стандартным данным контекста, передаваемым шаблону.

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

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

Устаревшее с версии 1.9: Параметр current_app устарел и будет удален в Django 2.0. Вызывающие стороны должны установить request.current_app вместо него.

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

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

Имя URL: password_reset_complete

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

• template_name: Полное имя шаблона для отображения представления. По умолчанию используется registration/password_reset_complete.html.
• current_app: Подсказка, указывающая, в каком приложении содержится текущий вид. Дополнительная информация о стратегии разрешения имен URL приведена в разделе стратегии разрешения URL с именованными пространствами.
• extra_context: Словарь данных контекста, которые будут добавлены к стандартным данным контекста, передаваемым шаблону.

Устаревшее с версии 1.9: Параметр current_app устарел и будет удален в Django 2.0. Вызывающие стороны должны установить request.current_app вместо него.

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

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_email(subject_template_name, email_template_name, context, from_email, to_email, html_email_template_name=None)

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

Параметры:	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 теми же переменными, которые password_reset() передает в контекст своего письма.

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. Этот пример отобразит True если у вошедшего в систему пользователя есть какие-либо разрешения в приложении foo:

{{ perms.foo }}

Поиск по двум уровням атрибутов — это прокси к User.has_perm. Этот пример отобразит True если у вошедшего в систему пользователя есть разрешение foo.can_vote:

{{ perms.foo.can_vote }}

Таким образом, вы можете проверять разрешения в утверждениях шаблона {% if %}:

{% 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 администратора, вам необходимо предоставить ей разрешение на добавление пользователей и изменение пользователей (т.е. разрешения «Добавить пользователя» и «Изменить пользователя»). Если учетная запись имеет разрешение на добавление пользователей, но не на изменение, эта учетная запись не сможет добавлять пользователей. Почему? Потому что, если у вас есть разрешение на добавление пользователей, у вас есть возможность создания суперпользователей, которые, в свою очередь, могут изменять других пользователей. Поэтому Django требует разрешений на добавление и изменение в качестве небольшой меры безопасности.

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

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

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