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

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

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

Пользовательские объекты

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

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

Проконсультируйтесь с ним для получения исчерпывающей ссылки; приведенная ниже документация больше ориентирована на задачи.documentation complète de l'API

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

Самый простой способ создать пользователей - использовать служебную функцию create_user() :

>>> from django.contrib.auth.models import User
>>> user = User.objects.create_user('john', '[email protected]', 'johnpassword')

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

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

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

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

$ python manage.py createsuperuser --username=joe [email protected]

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

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

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

Чтобы изменить пароль пользователя, у вас есть несколько вариантов:

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

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

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

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

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

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

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

authenticate( запрос = Нет , ** учетные данные )

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

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

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

Заметка

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

Разрешения и разрешения

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

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

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

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

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

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

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

Разрешения по умолчанию

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

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

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

  • дополнение: user.has_perm('foo.add_bar')
  • модификация: user.has_perm('foo.change_bar')
  • удаление: user.has_perm('foo.delete_bar')
  • показывать: user.has_perm('foo.view_bar')

К модели Permission редко обращаются напрямую.

Группы

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

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

Помимо разрешений, группы - это хороший способ сгруппировать пользователей под определенным именем, чтобы назначить им определенные функции. Например, вы можете создать группу, а затем написать код, который дает им доступ к разделу сайта, предназначенному только для членов, или отправлять им электронные письма, предназначенные только для членов.Utilisateurs spéciaux

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

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

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

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

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

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

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

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

Разрешения на кеширование

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

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

from myapp.models import BlogPost

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

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

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

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

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

    ...

Прокси-модели

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

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

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

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

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

Django использует сеансы и систему промежуточного программного обеспечения для подключения к ним системы аутентификации .objets requête

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

Вы можете отличить их друг от друга по методу is_authenticated , например:

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

Логин пользователя

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

login( запрос , пользователь , бэкэнд = Нет )

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

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

В этом примере показано, как использовать authenticate() и login() :

from django.contrib.auth import authenticate, login

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

Выбор механизма аутентификации

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

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

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

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

logout( запрос )

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

from django.contrib.auth import logout

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

Обратите внимание, что logout() не сообщает об ошибке, если пользователь не вошел в систему.

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

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

Сырой способ

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

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

def my_view(request):
    if not request.user.is_authenticated:
        return redirect('%s?next=%s' % (settings.LOGIN_URL, request.path))
    # ...

… Или отобразить сообщение об ошибке:

from django.shortcuts import render

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

Декоратор login_required

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

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

from django.contrib.auth.decorators import login_required

@login_required
def my_view(request):
    ...

login_required() Является ли это:

  • Если пользователь не вошел в систему, он settings.LOGIN_URL выполняет перенаправление , передавая абсолютный путь в строке запроса. Пример: /accounts/login/?next=/polls/3/ .
  • Если пользователь вошел в систему, он запустит просмотр в обычном режиме. Код просмотра может законно считать, что пользователь вошел в систему.

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

from django.contrib.auth.decorators import login_required

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

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

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

from django.contrib.auth.decorators import login_required

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

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

from django.contrib.auth import views as auth_views

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

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

Заметка

Декоратор login_required НЕ проверяет флаг is_active пользователя, но движок по AUTHENTICATION_BACKENDS умолчанию отклоняет неактивных пользователей.

Смотрите также

Если вы пишете собственные представления для сайта администратора Django (или вам нужны те же элементы управления разрешениями, что и встроенные представления), django.contrib.admin.views.decorators.staff_member_required() вы можете найти декоратор даже более полезным, чем login_required() .

Класс миксинов LoginRequired

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

класс LoginRequiredMixin

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

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

from django.contrib.auth.mixins import LoginRequiredMixin

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

Заметка

Как и декоратор login_required , этот класс миксина НЕ проверяет флаг is_active пользователя, но движок по AUTHENTICATION_BACKENDS умолчанию отклоняет неактивных пользователей.

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

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

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

from django.shortcuts import redirect

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

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

from django.contrib.auth.decorators import user_passes_test

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

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

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

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

login_url
Позволяет указать URL-адрес, на который будут перенаправлены пользователи, не прошедшие тест. Это может быть страница входа, значение по умолчанию settings.LOGIN_URL .
redirect_field_name
Что касается login_required() . Если вы установите для этого параметра значение None , он не будет присутствовать в URL-адресе, что может быть полезно, если вы перенаправляете пользователей, не прошедших тест, на страницу, которая не используется для входа в систему и где нет понятие «следующая страница».

Например :

@user_passes_test(email_check, login_url='/login/')
def my_view(request):
    ...
класс UserPassesTestMixin

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

test_func()

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

from django.contrib.auth.mixins import UserPassesTestMixin

class MyView(UserPassesTestMixin, View):

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

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

Накопление UserPassesTestMixin

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

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

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

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

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

Декоратор permission_required

permission_required( Завивка , login_url = None , raise_exception не = False )

Относительно часто требуется проверять наличие у пользователя определенных прав. Для этого в Django есть ярлык: декоратор permission_required() :

from django.contrib.auth.decorators import permission_required

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

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

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

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

from django.contrib.auth.decorators import permission_required

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

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

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

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

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

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

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

Класс миксинов PermissionRequiredMixin

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

класс PermissionRequiredMixin

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

from django.contrib.auth.mixins import PermissionRequiredMixin

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

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

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

get_permission_required()

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

has_permission()

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

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

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

класс AccessMixin
login_url

Возвращаемое значение по умолчанию get_login_url() . None По умолчанию содержит, и в этом случае get_login_url() возвращается к содержимому settings.LOGIN_URL .

permission_denied_message

Возвращаемое значение по умолчанию get_permission_denied_message() . По умолчанию содержит пустую строку.

redirect_field_name

Возвращаемое значение по умолчанию get_redirect_field_name() . "next" По умолчанию содержит .

raise_exception

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

get_login_url()

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

get_permission_denied_message()

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

get_redirect_field_name()

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

handle_no_permission()

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

Аннулирование сессии при смене пароля

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

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

update_session_auth_hash( запрос , пользователь )

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

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

from django.contrib.auth import update_session_auth_hash

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

Заметка

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

Просмотры аутентификации

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

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

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

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

urlpatterns = [
    path('accounts/', include('django.contrib.auth.urls')),
]

Это будет включать следующие шаблоны URL

accounts/login/ [name='login']
accounts/logout/ [name='logout']
accounts/password_change/ [name='password_change']
accounts/password_change/done/ [name='password_change_done']
accounts/password_reset/ [name='password_reset']
accounts/password_reset/done/ [name='password_reset_done']
accounts/reset/<uidb64>/<token>/ [name='password_reset_confirm']
accounts/reset/done/ [name='password_reset_complete']

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

Если вы хотите больше контролировать свои URL-адреса, вы можете указать конкретное представление в своем URLconf.

from django.contrib.auth import views as auth_views

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

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

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

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

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

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

класс LoginView

Имя URL: login

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

Атрибуты:

  • template_name : имя шаблона для отображения результата просмотра соединения пользователя. Его значение по умолчанию - registration/login.html .

  • redirect_field_name : имя поля, GET содержащего URL-адрес для перенаправления после подключения. Его значение по умолчанию - next .

  • authentication_form : исполняемый файл (обычно класс формы), используемый для аутентификации. Его значение по умолчанию - AuthenticationForm .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{% extends "base.html" %}

{% block content %}

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

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

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

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

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

{% endblock %}

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

класс LogoutView

Выходит из системы.

Имя URL: logout

Атрибуты:

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

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

  • title : строка "Вышел из системы", переведена.
  • site : Site текущий, в зависимости от настройки SITE_ID . Если приложение site не установлено, оно будет экземпляром, RequestSite который определяет имя сайта и его домен из текущего объекта HttpRequest .
  • site_name : псевдоним site.name . Если приложение site не установлено, эта переменная будет содержать значение request.META['SERVER_NAME'] . Дополнительные сведения о сайтах см. В разделе «Инфраструктура сайтов» .
logout_then_login( запрос , login_url = None )

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

Имя URL: без URL по умолчанию

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

  • login_url : URL-адрес страницы входа, на которую выполняется перенаправление. Если этот параметр не заполнен, используется значение по умолчанию settings.LOGIN_URL .
класс PasswordChangeView

Имя URL: password_change

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

Атрибуты:

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

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

  • form : форма смены пароля (см. form_class выше).
класс PasswordChangeDoneView

Имя URL: password_change_done

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

Атрибуты:

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

Имя URL: password_reset

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

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

Заметка

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

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

Атрибуты:

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

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

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

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

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

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

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

Шаблон субъекта получает тот же контекст шаблона. Тема должна быть одной строкой обычного текста.

класс PasswordResetDoneView

Имя URL: password_reset_done

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

Заметка

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

Атрибуты:

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

Имя URL: password_reset_confirm

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

Именованные параметры из URL:

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

Атрибуты:

  • template_name : полное имя шаблона скина, который будет использоваться для отображения окна подтверждения пароля. Его значение по умолчанию - registration/password_reset_confirm.html .

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

  • post_reset_login : Логическое значение, указывающее, должен ли пользователь проходить автоматическую аутентификацию после успешного сброса пароля. Есть False по умолчанию.

  • post_reset_login_backend : путь Python к механизму аутентификации, который будет использоваться во время аутентификации, если post_reset_login стоит True . Требуется, только если настроено более одного двигателя AUTHENTICATION_BACKENDS . По умолчанию это None .

  • form_class : форма, используемая для определения пароля. По умолчанию это SetPasswordForm .

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

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

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

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

    Атрибут класса reset_url_token был добавлен.

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

  • form : форма определения пароля нового пользователя (см. form_class выше).
  • validlink : логическое значение, True если ссылка (комбинация uidb64 и из token ) действительна или еще не используется.
класс PasswordResetCompleteView

Имя URL: password_reset_complete

Отображает представление, информирующее пользователя об успешной смене пароля.

Атрибуты:

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

Служебные функции

redirect_to_login( далее , login_url = None , redirect_field_name = 'next' )

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

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

  • next_page : URL-адрес для перенаправления после успешного подключения.

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

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

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

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

Заметка

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

класс AdminPasswordChangeForm

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

Принимается user как первый позиционный параметр.

класс AuthenticationForm

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

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

confirm_login_allowed( пользователь )

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

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

from django.contrib.auth.forms import AuthenticationForm

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

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

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

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

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

класс PasswordResetForm

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

send_mail( имя_имя_темплита , имя_элемента_почты , контекст , адрес_от_почты , адрес_элемента , html_email_template_name = Нет )

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

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

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

класс SetPasswordForm

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

класс UserChangeForm

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

класс UserCreationForm

Один ModelForm для создания нового пользователя.

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

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

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

Технические детали

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

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

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

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

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

Разрешения

Разрешения текущего авторизованного пользователя хранятся в переменной шаблона . Это экземпляр удобного для шаблонов прокси-объекта разрешений.{{ perms }} django.contrib.auth.context_processors.PermWrapper

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

{% if perms.foo %}

Поиск двухуровневых атрибутов как логического - это прокси-метод для . Например, чтобы проверить, есть ли у вошедшего в систему пользователя разрешение :{{ perms }} User.has_perm() foo.add_vote

{% if perms.foo.add_vote %}

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

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

Также можно ознакомиться с разрешениями по инструкции . Например :{% if in %}

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

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

Когда django.contrib.admin и django.contrib.auth оба установлены, сайт администрирования предлагает удобный интерфейс для просмотра и управления пользователями, группами и разрешениями. Пользователи могут создаваться и удаляться, как и любая другая модель Django. Можно создавать группы и назначать разрешения пользователям и группам. Изменения модели, внесенные пользователями в процессе администрирования, также регистрируются и отображаются.

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

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

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

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

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

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

Copyright ©2021 All rights reserved