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

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

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

User объекты

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

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

• username
• password
• email
• first_name
• last_name

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

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

Наиболее прямой способ создания пользователей — использование встроенной функции create_user():

>>> from django.contrib.auth.models import User
>>> user = User.objects.create_user('john', 'lennon@thebeatles.com', 'johnpassword')

# At this point, user is a User object that has already been saved
# to the database. You can continue to change its attributes
# if you want to change other fields.
>>> user.last_name = 'Lennon'
>>> user.save()

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

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

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

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

Вам будет предложено ввести пароль. После его ввода пользователь будет создан немедленно. Если вы опустите опции --username или --email, вам будет предложено ввести эти значения.

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

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

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

manage.py changepassword *username* предлагает способ изменения пароля пользователя из командной строки. Вам будет предложено изменить пароль указанного пользователя, который необходимо ввести дважды. Если они совпадают, новый пароль будет изменен немедленно. Если вы не укажете пользователя, команда попытается изменить пароль пользователя, имя которого совпадает с текущим системным пользователем.

Вы также можете изменить пароль программно, используя set_password():

>>> from django.contrib.auth.models import User
>>> u = User.objects.get(username='john')
>>> u.set_password('new password')
>>> u.save()

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

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

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

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

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

Используйте authenticate() для проверки набора учетных данных. Она принимает учетные данные в качестве ключевых аргументов, username и password в стандартном случае, сравнивает их с каждым методом аутентификации и возвращает объект User, если учетные данные действительны для метода. Если учетные данные не действительны ни для одного метода или метод поднимает PermissionDenied, возвращает None. Например:

from django.contrib.auth import authenticate
user = authenticate(username='john', password='secret')
if user is not None:
    # A backend authenticated the credentials
else:
    # No backend authenticated the credentials

request — необязательный HttpRequest, который передается в метод authenticate() методов аутентификации.

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Группы

django.contrib.auth.models.Group модели представляют собой универсальный способ категоризации пользователей, позволяющий применять разрешения или другие метки к этим пользователям. Пользователь может принадлежать к любому количеству групп.

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

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

Программное создание разрешений

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

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

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

Затем разрешение можно назначить пользователю User через его атрибут user_permissions или группе Group через ее атрибут permissions.

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

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

from django.contrib.auth.models import Permission, User
from django.contrib.contenttypes.models import ContentType
from django.shortcuts import get_object_or_404

from myapp.models import BlogPost

def user_gains_perms(request, user_id):
    user = get_object_or_404(User, pk=user_id)
    # any permission check will cache the current set of permissions
    user.has_perm('myapp.change_blogpost')

    content_type = ContentType.objects.get_for_model(BlogPost)
    permission = Permission.objects.get(
        codename='change_blogpost',
        content_type=content_type,
    )
    user.user_permissions.add(permission)

    # Checking the cached permission set
    user.has_perm('myapp.change_blogpost')  # False

    # Request new instance of User
    # Be aware that user.refresh_from_db() won't clear the cache.
    user = get_object_or_404(User, pk=user_id)

    # Permission cache is repopulated from the database
    user.has_perm('myapp.change_blogpost')  # True

    ...

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

Django использует сессии и 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(request, username=username, password=password)
    if user is not None:
        login(request, user)
        # Redirect to a success page.
        ...
    else:
        # Return an 'invalid login' error message.
        ...

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

В более старых версиях, когда вы вручную входите в систему пользователю, вы обязательно должны успешно аутентифицировать пользователя с помощью authenticate() перед вызовом login(). Теперь вы можете установить бэкенд, используя новый аргумент 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.LoginView.as_view()),

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

Миксин LoginRequired

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

class LoginRequiredMixin

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

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

from django.contrib.auth.mixins import LoginRequiredMixin

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

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

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

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

from django.shortcuts import redirect

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

user_passes_test(test_func, login_url=None, redirect_field_name='next') [source]

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

from django.contrib.auth.decorators import user_passes_test

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

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

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

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

login_url

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

redirect_field_name

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

Например:

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

class UserPassesTestMixin

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

test_func()

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

from django.contrib.auth.mixins import UserPassesTestMixin

class MyView(UserPassesTestMixin, View):

    def test_func(self):
        return self.request.user.email.endswith('@example.com')

get_test_func()

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

Использование нескольких миксинов UserPassesTestMixin

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

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

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

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

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

Декоратор permission_required

permission_required(perm, login_url=None, raise_exception=False) [source]

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

from django.contrib.auth.decorators import permission_required

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

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

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

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

from django.contrib.auth.decorators import permission_required

@permission_required('polls.can_vote', login_url='/loginpage/')
def my_view(request):
    ...

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

Если параметр raise_exception задан, декоратор вызовет исключение PermissionDenied, вызывая представление 403 (HTTP Запрещено) вместо перенаправления на страницу входа.

Если вы хотите использовать 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):
    ...

Mixin PermissionRequiredMixin

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

class PermissionRequiredMixin

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

from django.contrib.auth.mixins import PermissionRequiredMixin

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

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

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

get_permission_required()

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

has_permission()

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

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

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

class AccessMixin

login_url

Значение по умолчанию для get_login_url(). По умолчанию None, в этом случае get_login_url() использует значение по умолчанию settings.LOGIN_URL.

permission_denied_message

Значение по умолчанию для get_permission_denied_message(). По умолчанию пустая строка.

redirect_field_name

Значение по умолчанию для get_redirect_field_name(). По умолчанию "next".

raise_exception

Если этот атрибут равен True, будет вызвано исключение PermissionDenied вместо перенаправления. По умолчанию False.

get_login_url()

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

get_permission_denied_message()

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

get_redirect_field_name()

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

handle_no_permission()

В зависимости от значения raise_exception, метод либо вызывает исключение PermissionDenied, либо перенаправляет пользователя на login_url, необязательно включая redirect_field_name , если оно установлено.

Отключение сессии при смене пароля

Если ваш AUTH_USER_MODEL наследуется от AbstractBaseUser или реализует собственный метод get_session_auth_hash(), аутентифицированные сессии будут включать хэш, возвращаемый этой функцией. В случае AbstractBaseUser это HMAC поля пароля. Django проверяет, соответствует ли хэш в сессии для каждого запроса хэшу, вычисленному во время запроса. Это позволяет пользователю выйти из всех своих сессий, изменив пароль.

В Django по умолчанию для изменения пароля используются представления PasswordChangeView и представление user_change_password в админском интерфейсе django.contrib.auth. Они обновляют сессию новым хешем пароля, чтобы пользователь, меняющий свой пароль, не выходил из системы. Если у вас есть пользовательское представление для смены пароля и вы хотите подобного поведения, используйте функцию update_session_auth_hash().

update_session_auth_hash(request, user) [source]

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

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

from django.contrib.auth import update_session_auth_hash

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

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

Добавлена замена ключа сессии.

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

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

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

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

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

urlpatterns = [
    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.PasswordChangeView.as_view()),
]

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

urlpatterns = [
    url(
        '^change-password/$',
        auth_views.PasswordChangeView.as_view(template_name='change-password.html'),
    ),
]

Все представления являются классово-ориентированными, что позволяет легко их настраивать путём наследования.

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

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

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

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

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

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

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

Новое в Django 1.10:

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

class LoginView

Новое в Django 1.11.

Имя URL: login

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

Атрибуты:

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

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

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

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

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

Вот что делает LoginView:

• Если вызывается через GET, отображается форма входа, которая отправляет POST-запрос на тот же URL. Подробнее об этом чуть позже.
• Если вызывается через POST с предоставленными пользователем учетными данными, пытается войти в систему. Если вход успешен, представление перенаправляет на URL, указанный в next. Если next не указан, он перенаправляет на settings.LOGIN_REDIRECT_URL (который по умолчанию /accounts/profile/). Если вход не успешен, отображается форма входа.

Вы должны предоставить html для шаблона входа, по умолчанию registration/login.html. Этому шаблону передаются четыре переменные контекста шаблона:

• form: Объект Form, представляющий AuthenticationForm.
• next: URL для перенаправления после успешного входа. Он также может содержать строку запроса.
• site: Текущий Site в соответствии с настройкой SITE_ID. Если модуль сайтов не установлен, он будет установлен в экземпляр RequestSite, который извлекает имя сайта и домен из текущего HttpRequest.
• site_name: Псевдоним для site.name. Если модуль сайтов не установлен, он будет установлен в значение request.META['SERVER_NAME']. Подробнее о сайтах см. в рамке «сайты».

Если вы предпочитаете не вызывать шаблон registration/login.html, вы можете передать параметр template_name в качестве дополнительных аргументов методу as_view в вашем URLconf. Например, эта строка URLconf будет использовать myapp/login.html:

url(r'^accounts/login/$', auth_views.LoginView.as_view(template_name='myapp/login.html')),

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

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

{% extends "base.html" %}

{% block content %}

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

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

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

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

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

{% endblock %}

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

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

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

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

• current_app: Указание приложения, содержащего текущее представление. Подробнее см. в стратегии разрешения именованных URL.

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

class LogoutView

Новое в Django 1.11.

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

Имя URL: logout

Атрибуты:

• next_page: URL для перенаправления после выхода. По умолчанию settings.LOGOUT_REDIRECT_URL.
• template_name: Полное имя шаблона для отображения после выхода из системы. По умолчанию registration/logged_out.html.
• redirect_field_name: Имя поля GET содержащего URL для перенаправления после выхода. По умолчанию next. Переопределяет URL next_page если передан параметр GET.
• extra_context: Словарь данных контекста, который будет добавлен к стандартным данным контекста, передаваемым шаблону.
• success_url_allowed_hosts: set хостов, в дополнение к request.get_host(), которые безопасны для перенаправления после выхода. По умолчанию пустой set.

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

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

logout_then_login(request, login_url=None, 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 вместо него.

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

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

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

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

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

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

class PasswordChangeView

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

Имя URL: password_change

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

Атрибуты:

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

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

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

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

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

Дополнительные аргументы этого вида похожи на атрибуты вида на основе класса PasswordChangeDoneView. Кроме того, он имеет:

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

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

class PasswordChangeDoneView

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

Имя URL: password_change_done

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

Атрибуты:

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

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

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

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

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

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

class PasswordResetView

Новое в Django 1.11.

Имя URL: password_reset

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

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

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

Атрибуты:

• template_name: Полное имя шаблона, используемого для отображения формы сброса пароля. По умолчанию registration/password_reset_form.html если не указано.
• form_class: Форма, которая будет использоваться для получения адреса электронной почты пользователя, для которого необходимо сбросить пароль. По умолчанию PasswordResetForm.
• email_template_name: Полное имя шаблона, используемого для генерации письма со ссылкой на сброс пароля. По умолчанию registration/password_reset_email.html если не указано.
• subject_template_name: Полное имя шаблона, используемого для темы письма со ссылкой на сброс пароля. По умолчанию registration/password_reset_subject.txt если не указано.
• token_generator: Экземпляр класса для проверки одноразовой ссылки. По умолчанию default_token_generator, это экземпляр django.contrib.auth.tokens.PasswordResetTokenGenerator.
• success_url: URL для перенаправления после успешной просьбы сброса пароля.
• from_email: Действительный адрес электронной почты. По умолчанию Django использует DEFAULT_FROM_EMAIL.
• extra_context: Словарь данных контекста, которые будут добавлены к стандартным данным контекста, передаваемым в шаблон.
• html_email_template_name: Полное имя шаблона, используемого для генерации text/html multipart письма со ссылкой на сброс пароля. По умолчанию письмо HTML не отправляется.
• extra_email_context: Словарь данных контекста, которые будут доступны в шаблоне письма.

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

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

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

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

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

Необязательные аргументы этой страницы похожи на атрибуты страницы на основе класса PasswordResetDoneView. Кроме того, она имеет:

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

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

class PasswordResetDoneView

Новое в Django 1.11.

Имя URL: password_reset_done

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

Примечание

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

Атрибуты:

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

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

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

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

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

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

class PasswordResetConfirmView

Новое в Django 1.11.

Имя URL: password_reset_confirm

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

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

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

Атрибуты:

• template_name: Полное имя шаблона для отображения страницы подтверждения пароля. Значение по умолчанию registration/password_reset_confirm.html.
• token_generator: Экземпляр класса для проверки пароля. По умолчанию default_token_generator, это экземпляр django.contrib.auth.tokens.PasswordResetTokenGenerator.
• post_reset_login: Логическое значение, указывающее, должен ли пользователь быть автоматически аутентифицирован после успешного сброса пароля. По умолчанию False.
• post_reset_login_backend: Путь к модулю аутентификации для использования при аутентификации пользователя, если post_reset_login равно True. Требуется только в случае наличия нескольких AUTHENTICATION_BACKENDS. По умолчанию None.
• form_class: Форма, которая будет использоваться для установки пароля. По умолчанию SetPasswordForm.
• success_url: URL для перенаправления после завершения сброса пароля. По умолчанию 'password_reset_complete'.
• extra_context: Словарь данных контекста, которые будут добавлены к стандартным данным контекста, передаваемым в шаблон.

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

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

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

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

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

• current_app: Подсказка, указывающая, в каком приложении содержится текущее представление. Дополнительную информацию см. в стратегии разрешения именованных URL-адресов.

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

class PasswordResetCompleteView

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

Имя URL: password_reset_complete

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

Атрибуты:

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

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

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

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

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

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

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

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

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

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

class AdminPasswordChangeForm

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

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

class AuthenticationForm

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

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

confirm_login_allowed(user)

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

Например, чтобы разрешить вход всем пользователям независимо от статуса «активный»:

from django.contrib.auth.forms import AuthenticationForm

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

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

Или чтобы разрешить вход только некоторым активным пользователям:

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

class PasswordChangeForm

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

class PasswordResetForm

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

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

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

Параметры:	subject_template_name – шаблон для темы. email_template_name – шаблон для тела письма. context – контекст, переданный subject_template, email_template, и html_email_template (если он не None). from_email – электронный адрес отправителя. to_email – электронный адрес запрашивающего. html_email_template_name – шаблон для HTML-тела; по умолчанию None, в этом случае отправляется текстовое письмо.

По умолчанию, save() заполняет context теми же переменными, что и PasswordResetView передает в свой контекст электронной почты.

class SetPasswordForm

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

class UserChangeForm

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

class UserCreationForm

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

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

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

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