Использование системы аутентификации Django ¶
В этом документе объясняется использование системы аутентификации Django в ее конфигурации по умолчанию. Эта конфигурация была разработана для удовлетворения наиболее распространенных потребностей проекта, для обработки достаточно широкого круга задач и для тщательной реализации паролей и разрешений. Для проектов, в которых требуется проверка подлинности, отличная от стандартной, Django поддерживает обширное расширение и настройку проверки подлинности.
Аутентификация Django обеспечивает как аутентификацию, так и авторизацию вместе и обычно называется системой аутентификации, поскольку эти функции в некоторой степени связаны.
User
объекты ¶
User
объекты являются ядром системы аутентификации. Обычно они представляют людей, взаимодействующих с вашим сайтом, и используются для включения таких вещей, как ограничение доступа, регистрация профилей пользователей, связывание контента с создателями и т. Д. В структуре аутентификации Django существует только один класс пользователей, т. 'superusers'
Е. 'staff'
Пользователи- администраторы являются просто объектами пользователей с набор специальных атрибутов, а не различных классов пользовательских объектов.
Основные атрибуты пользователя по умолчанию:
Для получения полной справки см. Следующую документацию, более ориентированную на задачи.full API documentation
Создание пользователей ¶
Самый простой способ создать пользователей - использовать включенную
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 не хранит необработанные (в виде открытого текста) пароли в модели пользователя, а только хэш (подробности см. В документации по управлению паролями ). По этой причине не пытайтесь напрямую манипулировать атрибутом пароля пользователя. Вот почему при создании пользователя используется вспомогательная функция.
Чтобы изменить пароль пользователя, у вас есть несколько вариантов:
manage.py changepassword *username*
предлагает способ изменения пароля пользователя из командной строки. Он предлагает вам изменить пароль данного пользователя, который вы должны ввести дважды. Если они оба совпадают, новый пароль будет немедленно изменен. Если вы не укажете пользователя, команда попытается изменить пароль, имя пользователя которого совпадает с текущим пользователем системы.
Вы также можете изменить пароль программно, используя
set_password()
:
>>> from django.contrib.auth.models import User
>>> u = User.objects.get(username='john')
>>> u.set_password('new password')
>>> u.save()
Если у вас установлен администратор Django, вы также можете изменить пароли пользователей на страницах администратора системы аутентификации .
Django также предоставляет представления и формы, которые можно использовать, чтобы позволить пользователям изменять свои собственные пароли.
Изменение пароля пользователя приведет к выходу из всех его сеансов. См. Подробности в разделе « Аннулирование сеанса при смене пароля» .
Аутентификация пользователей ¶
-
authenticate
( запрос = Нет , ** учетные данные ) ¶ Используйте
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
модели - это общий способ категоризации пользователей, чтобы вы могли применять к ним разрешения или какой-либо другой ярлык. Пользователь может принадлежать к любому количеству групп.
Пользователь в группе автоматически получает разрешения, предоставленные этой группе. Например, если у группы есть разрешение
, любой пользователь в этой группе будет иметь это разрешение.Site editors
can_edit_home_page
Помимо разрешений, группы - это удобный способ категоризации пользователей, чтобы дать им определенную метку или расширенную функциональность. Например, вы можете создать группу и написать код, который мог бы, скажем, предоставить им доступ к части вашего сайта, предназначенной только для членов, или отправлять им сообщения электронной почты только для членов.'Special users'
Программное создание разрешений ¶
Хотя пользовательские разрешения могут быть определены в Meta
классе модели , вы также можете создавать разрешения напрямую. Например, вы можете создать can_publish
разрешение для BlogPost
модели в myapp
:
from myapp.models import BlogPost
from django.contrib.auth.models import Permission
from django.contrib.contenttypes.models import ContentType
content_type = ContentType.objects.get_for_model(BlogPost)
permission = Permission.objects.create(
codename='can_publish',
name='Can Publish Posts',
content_type=content_type,
)
Затем разрешение может быть назначено объекту
User
через его user_permissions
атрибут или Group
через его
permissions
атрибут.
Прокси-моделям нужен собственный тип контента
Если вы хотите создать разрешения для прокси-модели , перейдите for_concrete_model=False
к,
ContentTypeManager.get_for_model()
чтобы получить соответствующие
ContentType
:
content_type = ContentType.objects.get_for_model(BlogPostProxy, for_concrete_model=False)
Кеширование разрешений ¶
В ModelBackend
кэширует разрешения на пользовательском объекте после первого времени они должны быть выбраны для проверки прав доступа. Обычно это нормально для цикла запрос-ответ, поскольку разрешения обычно не проверяются сразу после их добавления (например, в админке). Если вы добавляете разрешения и проверяете их сразу после этого, например, в тесте или представлении, самым простым решением является повторное получение пользователя из базы данных. Например:
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 использует сеансы и промежуточное ПО для подключения системы аутентификации .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
( запрос , пользователь , бэкэнд = Нет ) ¶ Для входа пользователя в систему из представления используйте
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
атрибут для возвращаемого им пользовательского объекта. - Используйте
backend
inAUTHENTICATION_BACKENDS
, если он только один. - В противном случае вызовите исключение.
В случаях 1 и 2 значение 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
и ваше представление входа в систему правильно связаны. Например, используя значения по умолчанию, добавьте следующие строки в свой URLconf:from django.contrib.auth import views as auth_views path('accounts/login/', auth_views.LoginView.as_view()),
settings.LOGIN_URL
Также принимает имена функций просмотра и именованные шаблоны URL . Это позволяет вам свободно переназначать представление входа в систему в вашем URLconf без необходимости обновлять настройки.- Если пользователь не вошел в систему, выполните перенаправление на
Примечание
login_required
Декоратор не проверяет is_active
флаг на пользователя, но по умолчанию AUTHENTICATION_BACKENDS
отклонять неактивных пользователей.
Смотрите также
Если вы пишете собственные представления для администратора Django (или нуждаетесь в той же проверке авторизации, что и встроенные представления), вы можете найти
django.contrib.admin.views.decorators.staff_member_required()
декоратор полезной альтернативой login_required()
.
LoginRequired
Mixin ¶
При использовании представлений на основе классов можно добиться того же поведения, что и при 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()
методом, имена разрешений принимают форму (т. Е. Для разрешения модели в приложении)."<app label>.<permission codename>"
polls.add_choice
polls
Декоратор также может принимать итерацию разрешений, и в этом случае пользователь должен иметь все разрешения для доступа к представлению.
Обратите внимание, что
permission_required()
также принимает необязательныйlogin_url
параметр:from django.contrib.auth.decorators import permission_required @permission_required('polls.add_choice', login_url='/loginpage/') def my_view(request): ...
Как и в
login_required()
декораторе, поlogin_url
умолчаниюsettings.LOGIN_URL
.Если
raise_exception
задан параметр, декоратор подниметсяPermissionDenied
, предлагая представление 403 (HTTP Forbidden) вместо перенаправления на страницу входа.Если вы хотите использовать,
raise_exception
но также даете своим пользователям возможность сначала войти в систему, вы можете добавитьlogin_required()
декоратор:from django.contrib.auth.decorators import login_required, permission_required @login_required @permission_required('polls.add_choice', raise_exception=True) def my_view(request): ...
Это также позволяет избежать петлю переадресации , если
LoginView
«Sredirect_authenticated_user=True
и вошедшие в системе пользователя не имеет все необходимые разрешения.
PermissionRequiredMixin
Mixin ¶
Чтобы применить проверки разрешений к представлениям на основе классов , вы можете использовать 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 Forbidden, в зависимости от
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'),
),
]
Все представления основаны на классах , что позволяет легко настраивать их путем создания подклассов.
Все представления аутентификации ¶
Это список всех 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
, другие веб-сайты смогут определять, аутентифицированы ли их посетители на вашем сайте, запрашивая URL-адреса перенаправления на файлы изображений на вашем веб-сайте. Чтобы избежать утечки информации из социальных сетей , разместите все изображения и значок в отдельном домене.Включение
redirect_authenticated_user
также может привести к возникновению цикла перенаправления при использованииpermission_required()
декоратора, если не используетсяraise_exception
параметр.success_url_allowed_hosts
: Aset
хостов, в дополнение кrequest.get_host()
которым можно безопасно перенаправить после входа в систему. По умолчанию пустойset
.
Вот что
LoginView
делает:- При вызове через
GET
, он отображает форму входа в систему, которая отправляет POST на тот же URL-адрес. Подробнее об этом чуть позже. - При вызове
POST
с использованием учетных данных, представленных пользователем, он пытается войти в систему. Если вход в систему прошел успешно, представление перенаправляется на URL-адрес, указанный вnext
. Еслиnext
не указан, выполняется перенаправление наsettings.LOGIN_REDIRECT_URL
(по умолчанию/accounts/profile/
). Если логин не удался, он повторно отображает форму входа.
Вы обязаны предоставить html для шаблона входа, который вызывается
registration/login.html
по умолчанию. В этот шаблон передаются четыре контекстные переменные шаблона:form
:Form
Объект, представляющийAuthenticationForm
.next
: URL-адрес для перенаправления после успешного входа в систему. Это также может содержать строку запроса.site
: Текущее значение вSite
соответствии сSITE_ID
настройкой. Если у вас не установлен фреймворк сайта, будет установлен экземплярRequestSite
, который получает имя сайта и домен из текущегоHttpRequest
.site_name
: Псевдоним дляsite.name
. Если у вас не установлена платформа сайта, будет установлено значениеrequest.META['SERVER_NAME']
. Дополнительные сведения о сайтах см. В разделе « Структура сайтов» .
Если вы предпочитаете не вызывать шаблон
registration/login.html
, вы можете передатьtemplate_name
параметр с помощью дополнительных аргументовas_view
методу в вашем URLconf. Например, эта строка URLconf будет использоватьmyapp/login.html
вместо этого:path('accounts/login/', auth_views.LoginView.as_view(template_name='myapp/login.html')),
Вы также можете указать имя
GET
поля, которое содержит URL-адрес для перенаправления после входа в системуredirect_field_name
. По умолчанию это поле называетсяnext
.Вот образец
registration/login.html
шаблона, который вы можете использовать в качестве отправной точки. Предполагается, что у вас естьbase.html
шаблон, определяющийcontent
блок:{% extends "base.html" %} {% block content %} {% if form.errors %} <p>Your username and password didn't match. Please try again.</p> {% endif %} {% if next %} {% if user.is_authenticated %} <p>Your account doesn't have access to this page. To proceed, please login with an account that has access.</p> {% else %} <p>Please login to see this page.</p> {% endif %} {% endif %} <form method="post" action="{% url 'login' %}"> {% csrf_token %} <table> <tr> <td>{{ form.username.label_tag }}</td> <td>{{ form.username }}</td> </tr> <tr> <td>{{ form.password.label_tag }}</td> <td>{{ form.password }}</td> </tr> </table> <input type="submit" value="login"> <input type="hidden" name="next" value="{{ next }}"> </form> {# Assumes you setup the password_reset view in your URLconf #} <p><a href="{% url 'password_reset' %}">Lost password?</a></p> {% endblock %}
Если у вас настроена проверка подлинности (см. Настройка проверки подлинности ), вы можете использовать настраиваемую форму проверки подлинности, установив
authentication_form
атрибут. Эта форма должна приниматьrequest
аргумент ключевого слова в своем__init__()
методе и предоставлятьget_user()
метод, который возвращает объект аутентифицированного пользователя (этот метод вызывается только после успешной проверки формы).
-
класс
LogoutView
¶ Выполняет выход пользователя из системы.
Имя URL:
logout
Атрибуты:
next_page
: URL-адрес для перенаправления после выхода из системы. По умолчаниюsettings.LOGOUT_REDIRECT_URL
.template_name
: Полное имя шаблона, отображаемого после выхода пользователя из системы. По умолчаниюregistration/logged_out.html
.redirect_field_name
: ИмяGET
поля, содержащего URL-адрес для перенаправления после выхода из системы. По умолчаниюnext
. Переопределяетnext_page
URL-адрес, если передан данныйGET
параметр.extra_context
: Словарь данных контекста, который будет добавлен к данным контекста по умолчанию, передаваемым в шаблон.success_url_allowed_hosts
: Aset
хостов, в дополнение кrequest.get_host()
которым можно безопасно перенаправить после выхода из системы. По умолчанию пустойset
.
Контекст шаблона:
title
: Строка «Вышел из системы», локализована.site
: Текущее значение вSite
соответствии сSITE_ID
настройкой. Если у вас не установлен фреймворк сайта, будет установлен экземплярRequestSite
, который получает имя сайта и домен из текущегоHttpRequest
.site_name
: Псевдоним дляsite.name
. Если у вас не установлена платформа сайта, будет установлено значение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_reset_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
. Если у вас не установлена платформа сайта, будет установлено значениеrequest.META['SERVER_NAME']
. Дополнительные сведения о сайтах см. В разделе « Структура сайтов» .domain
: Псевдоним дляsite.domain
. Если у вас не установлена платформа сайта, будет установлено значениеrequest.get_host()
.protocol
: http или httpsuid
: Первичный ключ пользователя, закодированный в базе 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 %}
Тот же контекст шаблона используется для шаблона темы. Тема должна быть однострочной простой текстовой строкой.
-
класс
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
: Идентификатор пользователя в кодировке 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
: Словарь данных контекста, который будет добавлен к данным контекста по умолчанию, передаваемым в шаблон.reset_url_token
: Параметр токена отображается как компонент URL-адресов для сброса пароля. По умолчанию'set-password'
.
Контекст шаблона:
form
: Форма (см.form_class
Выше) для установки пароля нового пользователя.validlink
: Boolean, Истина, если ссылка (комбинация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
: 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 - шаблон тела письма.
- контекст - контекст , передаваемый в
subject_template
,email_template
иhtml_email_template
(если это неNone
). - from_email - адрес электронной почты отправителя.
- to_email - адрес электронной почты запрашивающего.
- html_email_template_name - шаблон для тела HTML; по умолчанию
None
, в этом случае отправляется электронное письмо в виде простого текста.
По умолчанию
save()
заполняет теcontext
же переменные, которыеPasswordResetView
передаются в его контекст электронной почты.
-
-
класс
SetPasswordForm
¶ Форма, позволяющая пользователю изменить свой пароль, не вводя старый пароль.
-
класс
UserChangeForm
¶ Форма, используемая в интерфейсе администратора для изменения информации и разрешений пользователя.
-
класс
UserCreationForm
¶ A
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 %}
Оценка поиска двухуровневого атрибута как логического является прокси для
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 требует добавления и изменения разрешений в качестве небольшой меры безопасности.
Обдумайте, как вы позволяете пользователям управлять разрешениями. Если вы дадите пользователю, не являющемуся суперпользователем, возможность редактировать пользователей, это будет в конечном итоге то же самое, что дать им статус суперпользователя, потому что они смогут повышать права пользователей, включая самих себя!
Смена паролей ¶
Пароли пользователей не отображаются в админке (и не хранятся в базе данных), но отображаются сведения о хранилище паролей . В отображении этой информации есть ссылка на форму изменения пароля, которая позволяет администраторам изменять пароли пользователей.