Вывести всех пользователей django

Как вывести все записи пользователя на Django?

Скажу сразу, в Django начал разбираться только недавно. Сделал регистрацию/вход для пользователей по инструкциям, работает, регистрирует, входит.

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

Но я не совсем понимаю как это сделать, от слова Совсем.

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

1 ответ 1

Допустим у нас следующая модель записи:

Данная модель связаны с пользователем отношением ForeignKey , то есть у каждой записи может быть только 1 автор (пользователь), а у каждого пользователя может быть множество записей.

Примеры:

Чтобы получить все записи:

Чтобы получить все записи текущего пользователя:

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

Для того чтобы их вывести вам необходимо создать представление и шаблон.

Вот пример простого представления:

Примечание:
Для таких задач рекомендуется использовать представления на основе классов, подробнее можете прочитать в документации.

Вот пример простого шаблона:

В данном шаблоне мы используем язык шаблонизатора Django. Это аналог цикла for в Python. Так как в шаблон поступает список постов, мы его итерируем, чтобы отобразить каждый пост. Подробнее можете прочитать в документации.

Источник

Как получить список зарегистрированных пользователей в Django?

Добрый день. Подскажите, пожалуйста, как получить список зарегистрированных пользователей в Django? Пробовал способом, описанным тут, но получил ошибку:
relation «blog_userprofile» does not exist
LINE 1: . rprofile».»id», «blog_userprofile».»user_id» FROM «blog_user.
^
Request Method: GET
Request URL: 127.0.0.1:8000/admin_sees_everything
Django Version: 3.2.5
Exception Type: ProgrammingError
Exception Value:
relation «blog_userprofile» does not exist
LINE 1: . rprofile».»id», «blog_userprofile».»user_id» FROM «blog_user.
^
Exception Location: /home/yakamoz/.virtualenvs/blog-9i5ib5Bf/lib/python3.8/site-packages/django/db/backends/utils.py, line 84, in _execute
Python Executable: /home/yakamoz/.virtualenvs/blog-9i5ib5Bf/bin/python
Python Version: 3.8.10
Python Path:
[‘/home/yakamoz/blog’,
‘/usr/lib/python38.zip’,
‘/usr/lib/python3.8’,
‘/usr/lib/python3.8/lib-dynload’,
‘/home/yakamoz/.virtualenvs/blog-9i5ib5Bf/lib/python3.8/site-packages’]
Server time: Wed, 28 Jul 2021 13:31:10 +0000

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

• Вопрос задан 28 июл.
• 80 просмотров

Так ведь написано ведь:
relation «blog_userprofile» does not exist

Как выглядит вьюха и расширенная модель пользователя?

Про расширенную модель пользователя не очень понял.

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 :

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

Когда приложение 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 :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сырой способ ¶

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

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

Декоратор login_required ¶

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

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

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

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

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

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

Этот параметр 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 . Этот класс миксина должен находиться в крайнем левом положении в цепочке наследования.

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

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

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

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

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

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

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

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-адресе, что может быть полезно, если вы перенаправляете пользователей, не прошедших тест, на страницу, которая не используется для входа в систему и где нет понятие «следующая страница».

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

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

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

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

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

Декоратор permission_required ¶

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Возвращает логическое значение, указывающее, есть ли у текущего пользователя разрешение на запуск декорированного представления. По умолчанию это возвращает результат вызова 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 .

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

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

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

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

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

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

В зависимости от значения 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 сеанса стал недействительным:

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

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

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

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

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

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

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

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

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

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

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

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

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

Имя 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 :

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

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

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

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

Имя 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 (шаблона тела сообщения):

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

Имя 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’ По умолчанию содержит .

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

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

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

класс PasswordResetCompleteView ¶

Имя URL: password_reset_complete

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

Атрибуты:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 передаются в его контекст отправки электронной почты.

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

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

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

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

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

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

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

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

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

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

Разрешения ¶

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник