Использование системы аутентификации 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 migratemigratedjango.contrib.authINSTALLED_APPSmanage.py migratepost_migrate

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

  • Добавлять: 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 editorscan_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.
        ...

Выбор серверной части аутентификации

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

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

В случаях 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().

LoginRequiredMixin

При использовании представлений на основе классов можно добиться того же поведения, что и при 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_choicepolls

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

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

from django.contrib.auth.decorators import permission_required

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

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

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

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

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

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

Это также позволяет избежать петлю переадресации , если LoginView«S redirect_authenticated_user=Trueи вошедшие в системе пользователя не имеет все необходимые разрешения.

PermissionRequiredMixinMixin

Чтобы применить проверки разрешений к представлениям на основе классов , вы можете использовать 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: A setхостов, в дополнение к request.get_host()которым можно безопасно перенаправить после входа в систему. По умолчанию пустой set.

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

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

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

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

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

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_pageURL-адрес, если передан данный GETпараметр.
  • extra_context: Словарь данных контекста, который будет добавлен к данным контекста по умолчанию, передаваемым в шаблон.
  • success_url_allowed_hosts: A setхостов, в дополнение к 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 или https
  • uid: Первичный ключ пользователя, закодированный в базе 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 требует добавления и изменения разрешений в качестве небольшой меры безопасности.

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

Смена паролей

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

Copyright ©2021 All rights reserved