3.1
3.2
6.1
Версия документации: 5.0

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

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

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

Объект пользователя¶

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

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

Подробности смотрите в полном описании API, текущий раздел больше ориентирован на использование аутентификации.

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

Самый прямой способ создания пользователей — использовать включенную вспомогательную функцию 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, вы можете создать пользователя через UI.

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

Создайте суперпользователей с помощью команды createsuperuser:

/ 

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

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

Команда попросит ввести пароль. Пользователь будет создан сразу же по завершению команды. Если не указывать :djadminopt:`--username` или :djadminopt:`--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 также предоставляет представления и формы, которые можно использовать при создании страниц для смены пароля пользователем.

При смене пароля будут завершены все сессии пользователя, если вы используете SessionAuthenticationMiddleware. Смотрите Сброс сессии при изменении пароля.

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

authenticate(request=None, **credentials)¶

aauthenticate(request=None, **credentials)¶

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

Для аутентификации пользователя по имени и паролю используйте authenticate(). Параметры авторизации передаются как именованные аргументы, по умолчанию это username и password, если пароль и имя пользователя верны, будет возвращен объект User. Если пароль не правильный, authenticate() возвращает 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() серверов аутентификации.

Примечание

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

Changed in Django 5.0:

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

Права доступа и авторизация¶

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

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

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

При удалении объекта проверяется наличие права «delete» для объектов этого типа.
При доступе к странице добавления объекта проверяется наличие права «add» для объектов этого типа.
При доступе к страницам просмотра списка объектов и изменения объекта проверяется наличие права «change» для объектов этого типа.
При удалении объекта проверяется наличие права «delete» для объектов этого типа.

Права доступа можно добавлять не только типу объекта, но и конкретному объекту. Переопределив методы 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, оно добавит права доступа по умолчанию – «add», «change» и «delete» – для каждой модели из установленных приложений.

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

Предположим у вас есть приложение с app_label foo и модель Bar. Чтобы проверить права доступа, используйте:

add: user.has_perm('foo.add_bar')
change: user.has_perm('foo.change_bar')
delete: user.has_perm('foo.delete_bar')
add: user.has_perm('foo.add_bar')

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

Группы¶

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

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

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

Программное создание прав доступа¶

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

from myapp.models import BlogPost
from django.contrib.auth.models import Permission
from django.contrib.contenttypes.models import ContentType

content_type = ContentType.objects.get_for_model(BlogPost)
permission = Permission.objects.create(
    codename="can_publish",
    name="Can Publish Posts",
    content_type=content_type,
)

Теперь его можно добавить объекту User через атрибут user_permissions или к объекту Group через атрибут permissions.

Прокси-моделям нужен собственный тип контента.

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

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

Кеширование прав доступа¶

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

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

    ...

Proxy-модели¶

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

class Person(models.Model):
    class Meta:
        permissions = [("can_eat_pizzas", "Can eat pizzas")]


class Student(Person):
    class Meta:
        proxy = True
        permissions = [("can_deliver_pizzas", "Can deliver pizzas")]

>>> # Fetch the content type for the proxy model.
>>> content_type = ContentType.objects.get_for_model(Student, for_concrete_model=False)
>>> student_permissions = Permission.objects.filter(content_type=content_type)
>>> [p.codename for p in student_permissions]
['add_student', 'change_student', 'delete_student', 'view_student',
'can_deliver_pizzas']
>>> for permission in student_permissions:
...     user.user_permissions.add(permission)
...
>>> user.has_perm("app.add_person")
False
>>> user.has_perm("app.can_eat_pizzas")
False
>>> user.has_perms(("app.add_student", "app.can_deliver_pizzas"))
True

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

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

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

Различить их можно с помощью метода is_authenticated():

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

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

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

Changed in Django 5.0:

Добавлен метод HttpRequest.auser().

Как авторизовать пользователя¶

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

login(request, user, backend=None)¶

alogin(request, user, backend=None)¶

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

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

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

Данные пример показывает как вы можете использовать обе функции authenticate() и login():

from django.contrib.auth import authenticate, login


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

Changed in Django 5.0:

Добавлена функция alogin().

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

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

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

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

Как отменить авторизацию пользователя¶

logout(request)¶

alogout(request)¶

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

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

from django.contrib.auth import logout


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

Следует отметить, что функция logout() не выбрасывает никаких ошибок, если пользователь не был ранее авторизован.

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

Changed in Django 5.0:

Добавлена функция alogout().

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

Прямой путь¶

Самым простым способом ограничить доступ к страницам является использование метода request.user.is_authenticated() и, при необходимости, перенаправление на страницу авторизации:

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


def my_view(request):
    if not request.user.is_authenticated:
        return redirect(f"{settings.LOGIN_URL}?next={request.path}")
    # ...

… или отображение сообщения об ошибке:

from django.shortcuts import render


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

Декоратор login_required¶

login_required(redirect_field_name='next', login_url=None)¶

Для краткости кода вы можете использовать декоратор login_required():

from django.contrib.auth.decorators import login_required


@login_required
def my_view(request): ...

Функция login_required() делает следующее:

Если пользователь не авторизован, то перенаправляет его на URL, указанный в параметре конфигурации settings.LOGIN_URL, передавая текущий абсолютный путь в запросе. Например: /accounts/login/?next=/polls/3/.
Если пользователь авторизован, то выполняет код представления. В коде представления не требуется выполнять проверку авторизован ли пользователь или нет.

По умолчанию, в параметре "next" строки запроса хранится путь, по которому должен быть перенаправлен пользователь в результате успешной аутентификации. Если вам потребуется использовать другое имя для этого параметра, то воспользуйтесь необязательным аргументом redirect_field_name декоратора login_required():

from django.contrib.auth.decorators import login_required


@login_required(redirect_field_name="my_redirect_field")
def my_view(request): ...

Следует отметить, что если вы воспользуетесь аргументом redirect_field_name, то вам скорее всего потребуется внести изменения в ваш шаблон авторизации, так как переменная контекста шаблона, которая содержит путь перенаправления, будет использовать значение аргумента redirect_field_name в качестве своего ключа, а не стандартное значение "next".

Декоратор login_required() также принимает необязательный аргумент login_url. Например:

from django.contrib.auth.decorators import login_required


@login_required(login_url="/accounts/login/")
def my_view(request): ...

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

from django.contrib.auth import views as auth_views

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

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

Примечание

Декоратор login_required() не проверяет свойство is_active объекта пользователя.

См.также

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

Changed in Django 5.1:

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

Миксин `LoginRequiredMixin`¶

При использовании CBV представлений, вы можете получить поведение аналогичное 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"

Примечание

Подобно декоратору login_required(), эта примесь не проверяет свойство is_active объекта пользователя.

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

New in Django 5.1.

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

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

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

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

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

from django.shortcuts import redirect


def my_view(request):
    if not request.user.email.endswith("@example.com"):
        return redirect("/login/?next=%s" % request.path)
    # ...

user_passes_test(test_func, login_url=None, redirect_field_name='next')¶

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

Changed in Django 5.1:

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

class UserPassesTestMixin¶

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

test_func()¶

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

from django.contrib.auth.mixins import UserPassesTestMixin


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

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

Цепочка из UserPassesTestMixin

Из-за особенностей реализации UserPassesTestMixin, вы не можете выстроить цепочку наследования. Следующий пример не работает:

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


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


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

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

Декоратор permission_required¶

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

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

from django.contrib.auth.decorators import permission_required


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

Как и в случае с методом has_perm(), имена разрешений принимают форму "<метка приложения>.<кодовое имя разрешения>" (т. е. polls.add_choice для разрешения на модель в приложении polls).

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

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

from django.contrib.auth.decorators import permission_required


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

Аналогично декоратору login_required() , по умолчанию значение для аргумента login_url соответствует значению параметра конфигурации settings.LOGIN_URL.

Если определён аргумент raise_exception, то декоратор будет выбрасывать исключение PermissionDenied с описанием 403 (HTTP Forbidden) представление вместо перенаправления на страницу авторизации.

Если вам надо использовать raise_exception, но также предоставить пользователям шанс сначала аутентифицироваться, вы можете использовать декоратор login_required():

from django.contrib.auth.decorators import login_required, permission_required


@login_required
@permission_required("polls.add_choice", raise_exception=True)
def my_view(request): ...

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

Changed in Django 5.1:

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

Примесь `PermissionRequiredMixin`¶

Для того, чтобы выполнить проверки для CBV представлений, вы можете использовать PermissionRequiredMixin:

class PermissionRequiredMixin¶

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

from django.contrib.auth.mixins import PermissionRequiredMixin


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

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

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

get_permission_required()¶: Возвращает перечисления имён прав, используемых примесью. По умолчанию, это содержимое атрибута permission_required, при необходимости преобразованное в кортеж.

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

Перенаправление неаутентифицированных запросов в CBV представлениях¶

Дл упрощения обработки правил доступа в CBV представлениях, примесь 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 от поля с паролем. Если активирован SessionAuthenticationMiddleware, Django проверяет, что хеш, отправленный с каждым запросом, совпадает с хешом, вычисленным на стороне сервера. Это позволяет пользователю отключиться от всех его сессий с помощью изменения их пароля.

Стандартные представления для изменения пароля, поставляемые с Django, функция django.contrib.auth.views.password_change() и представление user_change_password в пакете django.contrib.auth, обновляют в сессии хэш пароля так, чтобы соответствующий пользователь не терял авторизацию. Если вы реализуете собственное представление для изменения пароля и желаете сохранить такое поведение, используйте эту функцию:

update_session_auth_hash(request, user)¶

aupdate_session_auth_hash(request, user)¶

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

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

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

from django.contrib.auth import update_session_auth_hash


def password_change(request):
    if request.method == "POST":
        form = PasswordChangeForm(user=request.user, data=request.POST)
        if form.is_valid():
            form.save()
            update_session_auth_hash(request, form.user)
    else:
        ...

Changed in Django 5.0:

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

Примечание

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

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

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

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

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

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

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

from django.contrib.auth import views as auth_views

urlpatterns = [
    path("change-password/", auth_views.PasswordChangeView.as_view()),
]

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

urlpatterns = [
    path(
        "change-password/",
        auth_views.PasswordChangeView.as_view(template_name="change-password.html"),
    ),
]

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

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

Ниже приведён список со всеми представлениями пакета django.contrib.auth. Для получения информации о деталях реализации обратитесь к Использование представлений.

class LoginView¶

Имя URL: login

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

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

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

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

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

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

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

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

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

Если вы включите redirect_authenticated_user, другие веб-сайты смогут определять, аутентифицированы ли их посетители на вашем сайте, запрашивая URL-адреса перенаправления на файлы изображений на вашем веб-сайте. Чтобы избежать утечки информации о «отпечатках пальцев в социальных сетях <https://robinlinus.github.io/socialmedia-leak/>`_», разместите все изображения и свой значок на отдельном домене.

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

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

get_default_redirect_url()¶: Возвращает URL-адрес для перенаправления после входа в систему. Реализация по умолчанию разрешает и возвращает next_page, если установлено, или LOGIN_REDIRECT_URL в противном случае.

Вот, что делает представление django.contrib.auth.views.login:

При вызове через GET, оно отображает форму для аутентификации, которая отправляет введённые данные через POST на тот же URL. Подробности далее.
При вызове через POST с аутентификационными данными пользователя, оно пытается авторизовать пользователя. При успешной авторизации, представление перенаправляет на URL, указанный в next. Если параметр next не был предоставлен, происходит перенаправление на URL, содержащийся в параметре конфигурации 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 через дополнительные аргументы URL с вашей схеме. Например, эта строка URL будет использовать шаблон myapp/login.html:

path("accounts/login/", auth_views.LoginView.as_view(template_name="myapp/login.html")),

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

Здесь показан пример содержимого шаблона registration/login.html, который вы можете использовать в качестве отправной точки. Он предполагает, что у вас есть шаблон base.html, который определяет блок content:

{% extends "base.html" %}

{% block content %}

{% if form.errors %}
<p>Your username and password didn't match. Please try again.</p>
{% endif %}

{% if next %}
    {% if user.is_authenticated %}
    <p>Your account doesn't have access to this page. To proceed,
    please login with an account that has access.</p>
    {% else %}
    <p>Please login to see this page.</p>
    {% endif %}
{% endif %}

<form method="post" action="{% url 'login' %}">
{% csrf_token %}
<table>
<tr>
    <td>{{ form.username.label_tag }}</td>
    <td>{{ form.username }}</td>
</tr>
<tr>
    <td>{{ form.password.label_tag }}</td>
    <td>{{ form.password }}</td>
</tr>
</table>

<input type="submit" value="login">
<input type="hidden" name="next" value="{{ next }}">
</form>

{# Assumes you set up the password_reset view in your URLconf #}
<p><a href="{% url 'password_reset' %}">Lost password?</a></p>

{% endblock %}

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

class LogoutView¶

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

Имя URL: logout

Атрибуты:

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

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

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

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

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

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

title: Локализованная строка «Logged out».
site: Текущий Site, соответствующий параметру конфигурации SITE_ID. Если вы не активировали соответствующее приложение, переменной будет присвоен экземпляр RequestSite, который получает имя сайта и домен из текущего HttpRequest.
site_name: Псевдоним для site.name. Если вы не активировали соответствующее приложение, переменной будет присвоено значение request.META['SERVER_NAME']. Для подробностей о работе с сайтами обратитесь к Фреймворк для сайтов.

logout_then_login(request, login_url=None)¶

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

Имя URL: Значения по умолчанию нет

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

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

class PasswordChangeView¶

Имя URL: password_change

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

Атрибуты:

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

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

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

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

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

form: Форма для изменения пароля (обратитесь к password_change_form выше).

class PasswordChangeDoneView¶

Имя URL: password_change_done

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

Атрибуты:

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

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

class PasswordResetView¶

Имя URL: password_reset

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

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

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

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

Примечание

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

Атрибуты:

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

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

email_template_name¶: Полное имя шаблона, который будет использоваться для создания электронного письма со ссылкой для сброса пароля. По умолчанию используется registration/password_reset_email.html, если он не указан.

subject_template_name¶: Полное имя шаблона, который будет использоваться в качестве темы электронного письма со ссылкой для сброса пароля. По умолчанию используется registration/password_reset_subject.txt, если он не указан.

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

success_url¶: URL-адрес для перенаправления после успешного запроса на сброс пароля. По умолчанию 'password_reset_done'.

from_email¶: Действительный адрес электронной почты. По умолчанию Django использует DEFAULT_FROM_EMAIL.

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

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

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

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

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

Контекст шаблона электронной почты:

email: Псевдоним для user.email
user: Текущий User, соответствующий полю email формы. Толька активные пользователи имеют возможность сбрасывать свои пароли passwords (User.is_active is True).
site_name: Псевдоним для site.name. Если вы не активировали соответствующее приложение, переменной будет присвоено значение request.META['SERVER_NAME']. Для подробностей о работе с сайтами обратитесь к Фреймворк для сайтов.
domain: Псевдоним для site.domain. Если вы не используете приложение для работы с сайтами, то значением будет request.get_host().
protocol: http или https
uid: Первичный ключ пользователя, закодированный в base 64.
token: Токен для проверки корректности ссылки для сброса пароля.

Пример registration/password_reset_email.html (шаблон тела письма):

Someone asked for password reset for email {{ email }}. Follow the link below:
{{ protocol}}://{{ domain }}{% url 'password_reset_confirm' uidb64=uid token=token %}

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

class PasswordResetDoneView¶

Имя URL: password_reset_done

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

Примечание

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

Атрибуты:

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

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

class PasswordResetConfirmView¶

Имя URL: password_reset_confirm

Представляет форму для ввода нового пароля.

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

uid: Первичный ключ пользователя, закодированный в base 64.
token: Токен для проверки корректности ссылки для сброса пароля.

Атрибуты:

template_name¶: Полное имя шаблона для отображения представления подтверждения пароля. Значение по умолчанию: file: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. По умолчанию установлено значение «Нет».

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

success_url¶: URL-адрес для перенаправления после сброса пароля. По умолчанию 'password_reset_complete'.

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

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

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

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

class PasswordResetCompleteView¶

Имя URL: password_reset_complete

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

Атрибуты:

template_name¶: Полное имя шаблона для отображения представления. По умолчанию: file: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 в качестве первого неименованного параметра.

Changed in Django 5.1:

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

class AdminUserCreationForm¶

New in Django 5.1.1.

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

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

class AuthenticationForm¶

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

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

confirm_login_allowed(user)¶

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

Например, позволяем всем пользователям проходить аутентификацию, невзирая на их статус активности:

from django.contrib.auth.forms import AuthenticationForm


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

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

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

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

class BaseUserCreationForm¶

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

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

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 теми же переменными, что и функция password_reset(), передавая их в контекст электронного сообщения.

class SetPasswordForm¶: Форма, которая позволяет пользователю изменять свой пароль без ввода старого пароля.

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

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

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

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

Техническая особенность

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

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

При рендеринге RequestContext, авторизованный пользователь, неважно будет это экземпляр User или AnonymousUser, сохраняется в шаблонной переменной {{ user }}:

{% if user.is_authenticated %}
    <p>Welcome, {{ user.username }}. Thanks for logging in.</p>
{% else %}
    <p>Welcome, new user. Please log in.</p>
{% endif %}

Эта шаблонная переменная не доступна, если не используется RequestContext.

Права¶

Права авторизованного пользователя хранятся в шаблонной переменной {{ perms }}. Она связана с экземпляром django.contrib.auth.context_processors.PermWrapper, который реализует доступ к правам.

Оценка поиска по одному атрибуту {{ perms }} как логического значения является прокси для User.has_module_perms(). Например, чтобы проверить, есть ли у вошедшего в систему пользователя какие-либо разрешения в приложении foo:

{% if perms.foo %}

Оценка поиска двухуровневого атрибута как логического значения является прокси для User.has_perm(). Например, чтобы проверить, имеет ли вошедший в систему пользователь разрешение foo.add_vote:

{% if perms.foo.add_vote %}

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

{% if perms.foo %}
    <p>You have permission to do something in the foo app.</p>
    {% if perms.foo.add_vote %}
        <p>You can vote!</p>
    {% endif %}
    {% if perms.foo.add_driving %}
        <p>You can drive!</p>
    {% endif %}
{% else %}
    <p>You don't have permission to do anything in the foo app.</p>
{% endif %}

Также позможен поиск прав с помощью выражения {% if in %}. Например:

{% if 'foo' in perms %}
    {% if 'foo.add_vote' in perms %}
        <p>In lookup works, too.</p>
    {% endif %}
{% endif %}

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

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

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

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

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

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

Смена пароля¶

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

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

Управление паролями в Django

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

Объект пользователя¶

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

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

Смена пароля¶

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

Права доступа и авторизация¶

Права доступа по умолчанию¶

Группы¶

Программное создание прав доступа¶

Кеширование прав доступа¶

Proxy-модели¶

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

Как авторизовать пользователя¶

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

Как отменить авторизацию пользователя¶

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

Прямой путь¶

Миксин `LoginRequiredMixin`¶

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

Декоратор permission_required¶

Примесь `PermissionRequiredMixin`¶

Перенаправление неаутентифицированных запросов в CBV представлениях¶

Сброс сессии при изменении пароля¶

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

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

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

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

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

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

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

Права¶

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

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

Смена пароля¶

Дополнительная информация

Содержание

Просмотр

Вы находитесь здесь:

Получить помощь

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

Объект пользователя¶

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

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

Смена пароля¶

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

Права доступа и авторизация¶

Права доступа по умолчанию¶

Группы¶

Программное создание прав доступа¶

Кеширование прав доступа¶

Proxy-модели¶

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

Как авторизовать пользователя¶

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

Как отменить авторизацию пользователя¶

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

Прямой путь¶

Декоратор login_required¶

Миксин LoginRequiredMixin¶

Декоратор login_not_required¶

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

Декоратор permission_required¶

Примесь PermissionRequiredMixin¶

Перенаправление неаутентифицированных запросов в CBV представлениях¶

Сброс сессии при изменении пароля¶

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

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

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

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

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

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

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

Права¶

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

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

Смена пароля¶

Дополнительная информация

Содержание

Просмотр

Вы находитесь здесь:

Получить помощь

Миксин `LoginRequiredMixin`¶

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

Примесь `PermissionRequiredMixin`¶