Использование системы аутентификации Django ¶
Этот документ представляет использование системы аутентификации Django в ее конфигурации по умолчанию. Эта конфигурация была разработана для удовлетворения наиболее распространенных потребностей проектов, она способна обрабатывать широкий спектр задач и имеет тщательную реализацию паролей и разрешений. Для проектов, в которых требуется проверка подлинности, отличная от конфигурации по умолчанию, Django позволяет расширять и настраивать проверку подлинности в деталях.
Аутентификация Django обеспечивает как аутентификацию, так и авторизацию, вместе именуемые системой аутентификации, поскольку эти функции довольно тесно связаны.
Пользовательские объекты ¶
User
В основе системы аутентификации лежат объекты . Обычно они представляют людей, которые взаимодействуют с вашим сайтом, и используются для активации таких функций, как ограничение доступа, регистрация профилей пользователей, связывание контента с его создателем и т. Д. В системе аутентификации Django существует только один пользовательский класс; поэтому это означает, что «суперпользователи» ( 'superusers'
) или члены групп администрирования сайта ( 'staff'
) являются только обычными пользовательскими объектами с определенными определенными атрибутами, а не другим классом пользовательских объектов.
Основные атрибуты пользователя по умолчанию:
Проконсультируйтесь с ним для получения исчерпывающей ссылки; приведенная ниже документация больше ориентирована на задачи.documentation complète de l'API
Создание пользователей ¶
Самый простой способ создать пользователей - использовать служебную функцию create_user()
:
>>> from django.contrib.auth.models import User
>>> user = User.objects.create_user('john', '[email protected]', 'johnpassword')
# At this point, user is a User object that has already been saved
# to the database. You can continue to change its attributes
# if you want to change other fields.
>>> user.last_name = 'Lennon'
>>> user.save()
Если вы установили интерфейс администратора Django, вы также можете создавать пользователей в интерактивном режиме .
Создание суперпользователей ¶
Суперпользователей можно создать с помощью команды createsuperuser
:
$ python manage.py createsuperuser --username=joe [email protected]
Вам нужно будет ввести пароль. После этого пользователь будет немедленно создан. Если вы опустите параметры --username
или --email
, вам также нужно будет указать эти значения.
Смена паролей ¶
Django не хранит необработанные (чистые) пароли в модели пользователя, только хеш-хэш (подробности см. В документации о том, как обрабатываются пароли ). Вот почему необходимо избегать прямого манипулирования атрибутом password
пользователя и чтобы для создания пользователя использовалась служебная функция.
Чтобы изменить пароль пользователя, у вас есть несколько вариантов:
manage.py changepassword *nom d'utilisateur*
предоставляет метод изменения пароля пользователя из командной строки. Вам будет предложено изменить пароль для указанного пользователя, введя его дважды. Если две записи совпадают, новый пароль будет установлен немедленно. Если вы не укажете имя пользователя, команда попытается изменить пароль пользователя, имя которого совпадает с именем текущего пользователя системы.
Также можно изменить пароль программно, используя set_password()
:
>>> from django.contrib.auth.models import User
>>> u = User.objects.get(username='john')
>>> u.set_password('new password')
>>> u.save()
Если установлен интерфейс администратора Django, вы также можете изменить пароли пользователей на страницах администратора системы аутентификации .
Django также предоставляет представления и формы, которые позволяют пользователям изменять свои собственные пароли.
Смена пароля пользователя отключает все его сеансы. См. Раздел Аннулирование сеанса при смене пароля для более подробной информации.
Аутентификация пользователя ¶
-
authenticate
( запрос = Нет , ** учетные данные ) ¶ Используется
authenticate()
для проверки набора данных аутентификации. Этот метод принимает данные аутентификации в форме именованных параметров,username
аpassword
для конфигурации по умолчанию проверяет эти данные с каждым механизмом аутентификации и возвращает объект,User
если аутентификация действительна для одного из механизмов. Если никакая машина не принимает аутентификацию или если машина генерируетPermissionDenied
, метод возвращаетсяNone
. Например :from django.contrib.auth import authenticate user = authenticate(username='john', password='secret') if user is not None: # A backend authenticated the credentials else: # No backend authenticated the credentials
request
-HttpRequest
необязательный объект, который передается методуauthenticate()
механизмов аутентификации.Заметка
Это один из способов аутентификации набора данных аутентификации низкого уровня; например, это то, что использует
RemoteUserMiddleware
. Вероятно, вы не будете использовать этот метод, если не напишете свою собственную систему аутентификации. Если вы ищете способ входа пользователя в систему, используйте вместо этого классLoginView
.
Разрешения и разрешения ¶
Django содержит встроенную систему разрешений. Он позволяет назначать разрешения конкретным пользователям или группам пользователей.
Эта система используется сайтом администрирования Django, но вы можете использовать ее в своем собственном коде.
Сайт администратора Django использует следующие разрешения:
- Доступ к просмотру объекта ограничен пользователями с разрешением на «просмотр» или «изменение» для этого типа объекта.
- Доступ к форме добавления и добавление объекта разрешено только пользователям с разрешением «добавить» для этого типа объекта.
- Доступ к списку объектов для модификации, к форме модификации и модификации объекта ограничен пользователями с разрешением «изменение» для этого типа объекта.
- Доступ для удаления объекта ограничен пользователями с разрешением на «удаление» для этого типа объекта.
Разрешения могут быть назначены не только по типу объекта, но и по конкретному экземпляру объекта. Используя методы has_view_permission()
, has_add_permission()
, has_change_permission()
и has_delete_permission()
обеспечивается классом ModelAdmin
, можно настроить разрешения для различных экземпляров одного и того же типа.
У объектов User
есть два поля типа "многие ко многим": groups
и user_permissions
. Объекты User
могут обращаться к своим связанным объектам так же, как и к любой другой модели Django :
myuser.groups.set([group_list])
myuser.groups.add(group, group, ...)
myuser.groups.remove(group, group, ...)
myuser.groups.clear()
myuser.user_permissions.set([permission_list])
myuser.user_permissions.add(permission, permission, ...)
myuser.user_permissions.remove(permission, permission, ...)
myuser.user_permissions.clear()
Разрешения по умолчанию ¶
Когда приложение django.contrib.auth
находится в настройке INSTALLED_APPS
, оно гарантирует, что четыре разрешения по умолчанию («добавить», «изменить», «удалить» и «просмотреть») будут созданы для каждой модели Django, определенной во всех установленных приложениях.
Эти разрешения будут созданы при запуске ; на первый запуск после добавления к , разрешения по умолчанию будут созданы для всех ранее установленных моделей, а также для любой новой модели , установленной в то время. После этого каждое новое выполнение создает разрешения по умолчанию для новых моделей (функция, которая создает разрешения, подключается к сигналу ).manage.py migrate
migrate
django.contrib.auth
INSTALLED_APPS
manage.py migrate
post_migrate
Предполагая, что у приложения есть атрибут и имя шаблона , вот как проверить основные разрешения:app_label
foo
Bar
- дополнение:
user.has_perm('foo.add_bar')
- модификация:
user.has_perm('foo.change_bar')
- удаление:
user.has_perm('foo.delete_bar')
- показывать:
user.has_perm('foo.view_bar')
К модели Permission
редко обращаются напрямую.
Группы ¶
Шаблоны django.contrib.auth.models.Group
- это общий способ сегментировать пользователей, чтобы вы могли назначать им разрешения или ссылаться на них по определенному имени. Пользователь может входить в любое количество групп.
Пользователь группы автоматически получает разрешения, назначенные этой группе. Например, если у группы есть разрешение , любой пользователь, который является членом группы, будет иметь это разрешение.Éditeurs du site
can_edit_home_page
Помимо разрешений, группы - это хороший способ сгруппировать пользователей под определенным именем, чтобы назначить им определенные функции. Например, вы можете создать группу, а затем написать код, который дает им доступ к разделу сайта, предназначенному только для членов, или отправлять им электронные письма, предназначенные только для членов.Utilisateurs spéciaux
Программное создание разрешений ¶
Хотя пользовательские разрешения могут быть определены в классе 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
кэширует разрешения объекта пользователя при первом просмотре этих разрешений. Как правило, это хорошо подходит для цикла запрос-ответ, поскольку в принципе разрешения не запрашиваются сразу после добавления (например, в интерфейсе администрирования). Если вы добавляете разрешения и видите их сразу после, например, в тесте или представлении, самым простым решением является повторное извлечение объекта пользователя из базы данных. Например :
from django.contrib.auth.models import Permission, User
from django.contrib.contenttypes.models import ContentType
from django.shortcuts import get_object_or_404
from myapp.models import BlogPost
def user_gains_perms(request, user_id):
user = get_object_or_404(User, pk=user_id)
# any permission check will cache the current set of permissions
user.has_perm('myapp.change_blogpost')
content_type = ContentType.objects.get_for_model(BlogPost)
permission = Permission.objects.get(
codename='change_blogpost',
content_type=content_type,
)
user.user_permissions.add(permission)
# Checking the cached permission set
user.has_perm('myapp.change_blogpost') # False
# Request new instance of User
# Be aware that user.refresh_from_db() won't clear the cache.
user = get_object_or_404(User, pk=user_id)
# Permission cache is repopulated from the database
user.has_perm('myapp.change_blogpost') # True
...
Прокси-модели ¶
Прокси-модели работают точно так же, как и конкретные модели. Разрешения создаются с использованием типа контента, специфичного для модели прокси. Прокси-модели не наследуют разрешения от конкретной модели, которую они расширяют.
class Person(models.Model):
class Meta:
permissions = [('can_eat_pizzas', 'Can eat pizzas')]
class Student(Person):
class Meta:
proxy = True
permissions = [('can_deliver_pizzas', 'Can deliver pizzas')]
>>> # Fetch the content type for the proxy model.
>>> content_type = ContentType.objects.get_for_model(Student, for_concrete_model=False)
>>> student_permissions = Permission.objects.filter(content_type=content_type)
>>> [p.codename for p in student_permissions]
['add_student', 'change_student', 'delete_student', 'view_student',
'can_deliver_pizzas']
>>> for permission in student_permissions:
... user.user_permissions.add(permission)
>>> user.has_perm('app.add_person')
False
>>> user.has_perm('app.can_eat_pizzas')
False
>>> user.has_perms(('app.add_student', 'app.can_deliver_pizzas'))
True
Аутентификация в веб-запросах ¶
Django использует сеансы и систему промежуточного программного обеспечения для подключения к ним системы аутентификации .objets requête
Атрибут, request.user
представляющий текущего пользователя, определяется для каждого объекта запроса. Если этот пользователь не вошел в систему, этот атрибут будет экземпляром AnonymousUser
, иначе он будет экземпляром User
.
Вы можете отличить их друг от друга по методу is_authenticated
, например:
if request.user.is_authenticated:
# Do something for authenticated users.
...
else:
# Do something for anonymous users.
...
Логин пользователя ¶
Если у вас есть аутентифицированный пользователь, которого вы хотите сопоставить с текущим сеансом, используйте эту функцию login()
.
-
login
( запрос , пользователь , бэкэнд = Нет ) ¶ Чтобы подключить пользователя из представления, используйте
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. ...
Выбор механизма аутентификации ¶
Когда пользователь подключается, его идентификатор и механизм, используемый для его аутентификации, сохраняются в сеансе пользователя. Это позволяет тому же механизму аутентификации извлекать сведения о пользователе по последующему запросу. Механизм аутентификации, который будет сохранен в сеансе, выбирается следующим образом:
- Если
backend
указан необязательный параметр , используется именно он. - Если атрибут
user.backend
существует, то используется именно он. Это объединяетauthenticate()
иlogin()
:authenticate()
устанавливает атрибутuser.backend
для возвращаемого объекта пользователя. - Если имеется только один двигатель
AUTHENTICATION_BACKENDS
, используется именно он. - В противном случае создается исключение.
В первых двух случаях значение параметра backend
или атрибута user.backend
должно соответствовать строке пути, разделенной точками (как в синтаксисе AUTHENTICATION_BACKENDS
), а не фактическому классу механизма.
Выход пользователя из системы ¶
-
logout
( запрос ) ¶ Чтобы отключить пользователя, подключенного через
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 ) ¶ В качестве ярлыка вы можете использовать
login_required()
удобный декоратор :from django.contrib.auth.decorators import login_required @login_required def my_view(request): ...
login_required()
Является ли это:- Если пользователь не вошел в систему, он
settings.LOGIN_URL
выполняет перенаправление , передавая абсолютный путь в строке запроса. Пример:/accounts/login/?next=/polls/3/
. - Если пользователь вошел в систему, он запустит просмотр в обычном режиме. Код просмотра может законно считать, что пользователь вошел в систему.
По умолчанию путь, на который должен быть перенаправлен пользователь после успешного входа в систему, сохраняется в параметре именованной строки запроса
"next"
. Если вы предпочитаете, чтобы этот параметр назывался по-другому,login_required()
примите необязательный параметрredirect_field_name
:from django.contrib.auth.decorators import login_required @login_required(redirect_field_name='my_redirect_field') def my_view(request): ...
Обратите внимание: если вы укажете значение для
redirect_field_name
, вам, скорее всего, также потребуется настроить шаблон подключения, поскольку переменная контекста шаблона, в которой хранится путь перенаправления, использует значениеredirect_field_name
в качестве ключа вместо"next"
(значение по дефолт).login_required()
также принимает необязательный параметрlogin_url
. Пример:from django.contrib.auth.decorators import login_required @login_required(login_url='/accounts/login/') def my_view(request): ...
Обратите внимание, что если вы оставите параметр пустым
login_url
, вам необходимо убедиться, что настройкаsettings.LOGIN_URL
и вид подключения правильно связаны. Например, используя настройки по умолчанию, добавьте в конфигурацию URL следующие строки:from django.contrib.auth import views as auth_views path('accounts/login/', auth_views.LoginView.as_view()),
Этот параметр
settings.LOGIN_URL
также принимает имена функций просмотра и именованные шаблоны URL . Это позволяет свободно перемещать представление соединения в конфигурации URL-адреса без необходимости обновления настройки.- Если пользователь не вошел в систему, он
Заметка
Декоратор login_required
НЕ проверяет флаг is_active
пользователя, но движок по AUTHENTICATION_BACKENDS
умолчанию отклоняет неактивных пользователей.
Смотрите также
Если вы пишете собственные представления для сайта администратора Django (или вам нужны те же элементы управления разрешениями, что и встроенные представления), django.contrib.admin.views.decorators.staff_member_required()
вы можете найти декоратор даже более полезным, чем login_required()
.
Класс миксинов LoginRequired
¶
При использовании представлений на основе классов вы можете добиться того же поведения, что и login_required
при использовании LoginRequiredMixin
. Этот класс миксина должен находиться в крайнем левом положении в цепочке наследования.
-
класс
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
пользователя, но движок по AUTHENTICATION_BACKENDS
умолчанию отклоняет неактивных пользователей.
Ограничение доступа для авторизованных пользователей, прошедших тест ¶
Чтобы ограничить доступ на основе определенного разрешения или теста, процесс почти идентичен описанному в предыдущем разделе.
Вы можете выполнить тест 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): ...
-
класс
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
( Завивка , 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()
, имена разрешений имеют форму (например, для разрешения модели приложения )."<étiquette application>.<code permission>"
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): ...
Это также позволяет избежать петлю переадресации , если
redirect_authenticated_user=True
вLoginView
и вошедшем пользователе не имеет все необходимые разрешения.
Класс миксинов PermissionRequiredMixin
¶
Чтобы применить проверки разрешений к представлениям на основе классов , вы можете использовать класс PermissionRequiredMixin
:
-
класс
PermissionRequiredMixin
¶ Этот класс миксина, как и декоратор
permission_required
, контролирует, имеет ли пользователь, обращающийся к представлению, все указанные разрешения. Разрешение (или итерация разрешений) должно быть указано в параметреpermission_required
:from django.contrib.auth.mixins import PermissionRequiredMixin class MyView(PermissionRequiredMixin, View): permission_required = 'polls.add_choice' # Or multiple of permissions: permission_required = ('polls.view_choice', 'polls.change_choice')
Вы можете определить любой из параметров,
AccessMixin
чтобы настроить обработку неаутентифицированных пользователей.Вы также можете переопределить эти методы:
-
get_permission_required
() ¶ Вернуть итерацию имен разрешений, используемых классом миксина. По умолчанию это содержимое атрибута
permission_required
, при необходимости преобразованное в кортеж.
-
has_permission
() ¶ Возвращает логическое значение, указывающее, есть ли у текущего пользователя разрешение на запуск декорированного представления. По умолчанию это возвращает результат вызова
has_perms()
со списком разрешений, возвращаемымget_permission_required()
.
-
Перенаправление неавторизованных запросов в представлениях на основе классов ¶
Чтобы упростить управление ограничениями доступа в представлениях на основе классов , класс AccessMixin
можно использовать для настройки поведения представления при отказе в доступе. Прошедшие проверку пользователи получают ответ HTTP 403 Forbidden. Анонимные пользователи перенаправляются на страницу входа или получают ответ HTTP 403, в зависимости от атрибута raise_exception
.
-
класс
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
( запрос , пользователь ) ¶ Эта функция принимает в качестве входных данных текущий запрос, а также обновленный объект пользователя, из которого будет вычислено новое значение хеш-функции сеанса; он обновляет хеш-значение сеанса. Он также заботится об изменении ключа сеанса, чтобы украденный файл cookie сеанса стал недействительным:
Пример использования:
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: ...
Заметка
По get_session_auth_hash()
сути SECRET_KEY
, обновление секретного ключа на вашем сайте делает недействительными все существующие сеансы.
Просмотры аутентификации ¶
Django предоставляет несколько представлений для управления входом в систему, выходом из системы и обработкой пароля. Они используют встроенные формы аутентификации , но вы также можете передавать им свои собственные формы.
Django не предоставляет шаблон по умолчанию для представлений аутентификации. Вам необходимо создать свои собственные шаблоны для представлений, которые вы хотите использовать. Контекст шаблона документируется в каждом представлении, см. Все представления проверки подлинности .
Использование представлений ¶
Существуют разные методы реализации этих представлений в вашем проекте. Самый простой способ - включить URLconf django.contrib.auth.urls
в ваш собственный URLconf, например
urlpatterns = [
path('accounts/', include('django.contrib.auth.urls')),
]
Это будет включать следующие шаблоны URL
accounts/login/ [name='login']
accounts/logout/ [name='logout']
accounts/password_change/ [name='password_change']
accounts/password_change/done/ [name='password_change_done']
accounts/password_reset/ [name='password_reset']
accounts/password_reset/done/ [name='password_reset_done']
accounts/reset/<uidb64>/<token>/ [name='password_reset_confirm']
accounts/reset/done/ [name='password_reset_complete']
У представлений есть URL-имя для облегчения поиска. Подробную информацию об использовании именованных шаблонов URL см. В документации по URL.
Если вы хотите больше контролировать свои URL-адреса, вы можете указать конкретное представление в своем URLconf.
from django.contrib.auth import views as auth_views
urlpatterns = [
path('change-password/', auth_views.PasswordChangeView.as_view()),
]
Представления имеют необязательные параметры, которые можно использовать для изменения поведения представления. Например, если вы хотите изменить имя модели, используемой представлением, вы можете указать параметр template_name
. Один из способов сделать это - предоставить параметры ключевого слова в URLconf, они будут переданы в представление. например
urlpatterns = [
path(
'change-password/',
auth_views.PasswordChangeView.as_view(template_name='change-password.html'),
),
]
Все мнения class- основе , что делает его легко настроить их по наследству.
Все представления аутентификации ¶
Это список всех представлений, предоставленных django.contrib.auth
. Подробные сведения о реализации см. В разделе Использование представлений .
-
класс
LoginView
¶ Имя 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
, другие веб-сайты смогут определять, аутентифицированы ли их посетители на вашем сайте, выполняя запросы перенаправления к файлам изображений на вашем сайте. Чтобы избежать раскрытия информации « отпечатками пальцев социальных сетей » , обслуживайте все изображения и значки в отдельном домене.Включение
redirect_authenticated_user
также может привести к возникновению цикла перенаправления, когда декораторpermission_required()
используется без указания параметраraise_exception
.success_url_allowed_hosts
: набор дополнительныхset
хостов,request.get_host()
которые безопасны в качестве цели перенаправления после подключения. Поset
умолчанию набор пуст.
Вот что он делает
LoginView
:- При вызове
GET
он отображает форму входа, цель которойPOST
отправляется на тот же URL. Подробнее об этом чуть позже. - Когда вызывается
POST
с учетными данными пользователя, он пытается войти в систему этого пользователя. Если операция прошла успешно, представление перенаправляется на URL-адрес, указанный вnext
. Еслиnext
отсутствует, перенаправляет наsettings.LOGIN_REDIRECT_URL
(по/accounts/profile/
умолчанию). В случае сбоя подключения в представлении снова отображается форма подключения.
Вы обязаны предоставить HTML-код для шаблона подключения с именем
registration/login.html
по умолчанию. Этот шаблон получает четыре контекстных переменных шаблона:form
: объект,Form
представляющий формуAuthenticationForm
.next
: URL-адрес для перенаправления после успешного подключения. Он также может содержать строку запроса.site
:Site
текущий, в зависимости от настройкиSITE_ID
. Если приложениеsite
не установлено, оно будет экземпляром,RequestSite
который определяет имя сайта и его домен из текущего объектаHttpRequest
.site_name
: псевдонимsite.name
. Если приложениеsite
не установлено, эта переменная будет содержать значениеrequest.META['SERVER_NAME']
. Дополнительные сведения о сайтах см. В разделе «Инфраструктура сайтов» .
Если вы предпочитаете не использовать шаблон
registration/login.html
, вы можете заполнить параметр сtemplate_name
помощью дополнительных параметров методаas_view
в своей конфигурации 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 setup the password_reset view in your URLconf #} <p><a href="{% url 'password_reset' %}">Lost password?</a></p> {% endblock %}
Если у вас настроена проверка подлинности (см. Настройка проверки подлинности ), можно использовать настраиваемую форму проверки подлинности, установив атрибут
authentication_form
. Метод__init__()
этой формы должен принимать именованный параметрrequest
; форма также должна реализовывать метод,get_user()
который возвращает объект аутентифицированного пользователя (этот метод не вызывается до тех пор, пока не будет выполнена успешная проверка формы).
-
класс
LogoutView
¶ Выходит из системы.
Имя 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()
которые безопасны в качестве цели перенаправления после отключения. По умолчанию набор пуст.
Контекст шаблона:
title
: строка "Вышел из системы", переведена.site
:Site
текущий, в зависимости от настройкиSITE_ID
. Если приложениеsite
не установлено, оно будет экземпляром,RequestSite
который определяет имя сайта и его домен из текущего объектаHttpRequest
.site_name
: псевдонимsite.name
. Если приложениеsite
не установлено, эта переменная будет содержать значениеrequest.META['SERVER_NAME']
. Дополнительные сведения о сайтах см. В разделе «Инфраструктура сайтов» .
-
logout_then_login
( запрос , login_url = None ) ¶ Выполняет выход пользователя из системы, а затем перенаправляет его на страницу входа.
Имя URL: без URL по умолчанию
Необязательные параметры:
login_url
: URL-адрес страницы входа, на которую выполняется перенаправление. Если этот параметр не заполнен, используется значение по умолчаниюsettings.LOGIN_URL
.
-
класс
PasswordChangeView
¶ Имя URL:
password_change
Позволяет пользователю изменить свой пароль.
Атрибуты:
template_name
: полное имя шаблона, который будет использоваться для отображения формы изменения пароля. Его значение по умолчанию -registration/password_change_form.html
если параметр оставлен пустым.success_url
: URL-адрес для перенаправления после успешной смены пароля.'password_change_done'
По умолчанию содержит .form_class
: настраиваемая форма изменения пароля, которая должна принимать именованный параметрuser
. Форма отвечает за фактическое изменение пароля пользователя. По умолчанию этоPasswordChangeForm
.extra_context
: словарь данных контекста, который будет объединен с данными контекста по умолчанию, переданными в шаблон.
Контекст шаблона:
form
: форма смены пароля (см.form_class
выше).
-
класс
PasswordChangeDoneView
¶ Имя URL:
password_change_done
Страница, отображаемая после смены пароля пользователем.
Атрибуты:
template_name
: полное имя используемого шаблона. Его значение по умолчанию -registration/password_change_done.html
если параметр оставлен пустым.extra_context
: словарь данных контекста, который будет объединен с данными контекста по умолчанию, переданными в шаблон.
-
класс
PasswordResetView
¶ Имя URL:
password_reset
Позволяет пользователю сбросить свой пароль, создав одноразовую ссылку для сброса пароля. Эта ссылка отправляется на адрес электронной почты, зарегистрированный для этого пользователя.
Если указанный адрес электронной почты не существует в системе, это представление не отправляет электронное письмо, но пользователь также не получает сообщения об ошибке, чтобы предотвратить раскрытие информации потенциальным злоумышленникам. , Если вы хотите предоставить сообщение об ошибке в этой ситуации, вы можете создать класс, который наследуется от
PasswordResetForm
атрибута и использовать егоform_class
.Заметка
Имейте в виду, что отправка электронного письма занимает немного времени, что может сделать вас уязвимым для атаки временного перечисления электронной почты из-за разницы между продолжительностью запроса сброса, когда адрес электронной почты существует или когда он не существует. Чтобы избежать этого временного промежутка, вы можете использовать сторонний модуль, который позволяет асинхронную отправку электронных писем, например django-mailer .
Пользователям с непригодным для использования паролем (см.
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-адрес для перенаправления после успешного запроса сброса пароля.'password_reet_done'
По умолчанию содержит .from_email
: действующий адрес электронной почты. По умолчанию Django используетDEFAULT_FROM_EMAIL
.extra_context
: словарь данных контекста, который будет объединен с данными контекста по умолчанию, переданными в шаблон.html_email_template_name
: Полное имя шаблона, который будет использоваться для создания составного сообщения электронной почты text / html со ссылкой для сброса пароля. По умолчанию электронное письмо в формате HTML не отправляется.extra_email_context
: словарь контекстных данных, который будет доступен в шаблоне электронного письма. Его можно использовать для переопределения значений контекста шаблона по умолчанию, перечисленных ниже, например.domain
,
Контекст шаблона:
form
: форма сброса пароля пользователя (см.form_class
выше).
Контекст шаблона электронного письма:
email
: псевдонимuser.email
user
:User
текущий пользователь в соответствии с полем формыemail
. Только активные пользователи могут сбросить свой пароль ( ).User.is_active is True
site_name
: псевдонимsite.name
. Если приложениеsite
не установлено, эта переменная будет содержать значениеrequest.META['SERVER_NAME']
. Дополнительные сведения о сайтах см. В разделе «Инфраструктура сайтов» .domain
: псевдонимsite.domain
. Если приложениеsite
не установлено, эта переменная будет содержать значениеrequest.get_host()
.protocol
: http или httpsuid
: первичный ключ пользователя, закодированный в base64.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 %}
Шаблон субъекта получает тот же контекст шаблона. Тема должна быть одной строкой обычного текста.
-
класс
PasswordResetDoneView
¶ Имя URL:
password_reset_done
Страница отображается после того, как пользователь получает ссылку для сброса пароля. Это представление вызывается по умолчанию, если представление
PasswordResetView
не имеетsuccess_url
явно определенного URL .Заметка
Если указанный адрес электронной почты не существует в системе, если пользователь неактивен или если его пароль не используется, это представление все равно будет отображаться, но сообщение не будет отправлено.
Атрибуты:
template_name
: полное имя используемого шаблона. Его значение по умолчанию -registration/password_reset_done.html
если параметр оставлен пустым.extra_context
: словарь данных контекста, который будет объединен с данными контекста по умолчанию, переданными в шаблон.
-
класс
PasswordResetConfirmView
¶ Имя URL:
password_reset_confirm
Отображает форму для ввода нового пароля.
Именованные параметры из URL:
uidb64
: идентификатор пользователя, закодированный в базе 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
: путь Python к механизму аутентификации, который будет использоваться во время аутентификации, еслиpost_reset_login
стоитTrue
. Требуется, только если настроено более одного двигателяAUTHENTICATION_BACKENDS
. По умолчанию этоNone
.form_class
: форма, используемая для определения пароля. По умолчанию этоSetPasswordForm
.success_url
: URL-адрес для перенаправления после сброса пароля.'password_reset_complete'
По умолчанию содержит .extra_context
: словарь данных контекста, который будет объединен с данными контекста по умолчанию, переданными в шаблон.reset_url_token
: Параметр токена, отображаемый как компонент URL для сброса пароля.'set-password'
По умолчанию содержит .Изменено в Django 3.0:Атрибут класса
reset_url_token
был добавлен.
Контекст шаблона:
form
: форма определения пароля нового пользователя (см.form_class
выше).validlink
: логическое значение,True
если ссылка (комбинацияuidb64
и изtoken
) действительна или еще не используется.
-
класс
PasswordResetCompleteView
¶ Имя URL:
password_reset_complete
Отображает представление, информирующее пользователя об успешной смене пароля.
Атрибуты:
template_name
: полное имя шаблона для отображения представления. Его значение по умолчанию -registration/password_reset_complete.html
.extra_context
: словарь данных контекста, который будет объединен с данными контекста по умолчанию, переданными в шаблон.
Служебные функции ¶
-
redirect_to_login
( далее , login_url = None , redirect_field_name = 'next' ) ¶ Перенаправляет на страницу входа, а затем на другой URL-адрес, если вход был успешным.
Обязательные параметры:
next_page
: URL-адрес для перенаправления после успешного подключения.
Необязательные параметры:
login_url
: URL-адрес страницы входа, на которую выполняется перенаправление. Если этот параметр не заполнен, используется значение по умолчаниюsettings.LOGIN_URL
.redirect_field_name
: имя поля,GET
содержащего URL-адрес для перенаправления после выхода из системы. Это перегружается,next
еслиGET
вводится указанный параметр .
Встроенные формы ¶
Если вы не хотите использовать встроенные представления, но хотите воспользоваться преимуществом отсутствия необходимости переписывать формы для этой функции, система аутентификации предоставляет несколько встроенных форм, которые можно найти в django.contrib.auth.forms
:
Заметка
Интегрированные формы проверки подлинности зависят от ряда характеристик модели пользователя, с которой они взаимодействуют. Если вы используете настраиваемый шаблон пользователя , может потребоваться определить собственные формы для системы аутентификации. Дополнительную информацию см. В документации по использованию встроенных форм аутентификации с настраиваемыми пользовательскими шаблонами .
-
класс
AdminPasswordChangeForm
¶ Форма, используемая в интерфейсе администрирования для изменения пароля пользователя.
Принимается
user
как первый позиционный параметр.
-
класс
AuthenticationForm
¶ Форма для подключения пользователя.
Принимается
request
как первый позиционный параметр, который затем сохраняется в экземпляре формы, доступном для подклассов.-
confirm_login_allowed
( пользователь ) ¶ По умолчанию
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', )
-
-
класс
PasswordChangeForm
¶ Форма, позволяющая пользователю изменить свой пароль.
-
класс
PasswordResetForm
¶ Форма для создания и отправки по электронной почте одноразовой ссылки для сброса пароля пользователя.
-
send_mail
( имя_имя_темплита , имя_элемента_почты , контекст , адрес_от_почты , адрес_элемента , html_email_template_name = Нет ) ¶ Используйте параметры для отправки сообщения
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
передаются в его контекст отправки электронной почты.
-
-
класс
SetPasswordForm
¶ Форма, позволяющая пользователю изменить свой пароль без ввода старого пароля.
-
класс
UserChangeForm
¶ Форма, используемая в интерфейсе администрирования для изменения данных и разрешений пользователя.
-
класс
UserCreationForm
¶ Один
ModelForm
для создания нового пользователя.Он имеет три поля:
username
(из пользовательской модели)password1
иpassword2
. Он проверяет этоpassword1
иpassword2
соответствует, проверяет пароль с помощьюvalidate_password()
и устанавливает пароль пользователя с помощьюset_password()
.
Данные для аутентификации в шаблонах ¶
Текущий авторизованный пользователь и его разрешения доступны в контексте шаблона при использовании 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 %}
Поиск двухуровневых атрибутов как логического - это прокси-метод для . Например, чтобы проверить, есть ли у вошедшего в систему пользователя разрешение :{{ perms }}
User.has_perm()
foo.add_vote
{% if perms.foo.add_vote %}
Вот более полный пример управления разрешениями в шаблоне
{% if perms.foo %}
<p>You have permission to do something in the foo app.</p>
{% if perms.foo.add_vote %}
<p>You can vote!</p>
{% endif %}
{% if perms.foo.add_driving %}
<p>You can drive!</p>
{% endif %}
{% else %}
<p>You don't have permission to do anything in the foo app.</p>
{% endif %}
Также можно ознакомиться с разрешениями по инструкции . Например :{% if in %}
{% if 'foo' in perms %}
{% if 'foo.add_vote' in perms %}
<p>In lookup works, too.</p>
{% endif %}
{% endif %}
Управление пользователями на сайте администрирования ¶
Когда django.contrib.admin
и django.contrib.auth
оба установлены, сайт администрирования предлагает удобный интерфейс для просмотра и управления пользователями, группами и разрешениями. Пользователи могут создаваться и удаляться, как и любая другая модель Django. Можно создавать группы и назначать разрешения пользователям и группам. Изменения модели, внесенные пользователями в процессе администрирования, также регистрируются и отображаются.
Создание пользователей ¶
Вы должны увидеть ссылку на «Пользователи» в разделе «Auth» на главной странице сайта администрирования. Страница администрирования «Добавить пользователя» отличается от других страниц администрирования тем, что требует, чтобы вы сначала вводили имя пользователя и пароль, прежде чем вы сможете редактировать другие поля в пользователь.
Также обратите внимание, что если вы хотите, чтобы пользователь мог создавать других пользователей на сайте администратора Django, вам необходимо предоставить им разрешение на добавление пользователей и редактирование пользователей (т.е. разрешения «Может добавлять пользователя» и «Может изменять пользователя»). Если учетная запись пользователя имеет разрешение на добавление пользователей, но не на их изменение, эта учетная запись не сможет создавать пользователей. Зачем ? Потому что, если у вас есть разрешение на добавление пользователей, вы можете создавать суперпользователей, которые, в свою очередь, могут редактировать других пользователей. Таким образом, Django требует разрешений «добавлять» и «изменять» в качестве небольшой меры безопасности.
Обратите внимание на то, как вы позволяете пользователям управлять разрешениями. Если вы дадите не суперпользователю возможность редактировать пользователей, это в конечном итоге сведется к тому же, что и предоставление им статуса суперпользователя, поскольку они смогут повышать права пользователей, включая свои собственные!
Смена паролей ¶
Пароли пользователей не отображаются на сайте администрирования (и не хранятся в базе данных), но детали хранения паролей видны. Эта информация содержит ссылку на форму изменения пароля, которая позволяет администраторам изменять пароли пользователей.