Как сделать авторизацию по номеру телефона django

Обновлено: 03.07.2024

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

Для работы с авторизацией пользователей предлагаю использовать отдельное приложение/модуль, который будет называться accounts.

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

Структура модуля accounts

В данном модуле используется два шаблона:

• login.html - это шаблон для страницы авторизации
• login_widget.html - это шаблон для виджета авторизации, который может быть помещён на любой странице сайта, чтобы пользователь мог авторизоваться не только со страницы авторизации, но и с любой страницы со статьёй, например.

1. 1. Структура модуля accounts
2. 2. login_widget.html
3. 3. login.html
4. 4. urls.py файлы
5. 5. settings.py и apps.py
   1. 1. apps.py
   2. 2. settings.py

   login_widget.html

   Напоминаю, что я использую django_bootstrap3 на сайте, поэтому и шаблон будет с его использованием.

   login.html

   В шаблоне авторизации добавляется данный виджет. По тому же самому принципу можно добавлять виджет авторизации на любой странице в любом месте сайта.

   urls.py файлы

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

   urls.py файл модуля accounts будет выглядеть следующим образом:

   settings.py и apps.py

   Не забудьте зарегистрировать модуль авторизаций в настройках сайта.

   apps.py

   settings.py

   views.py

   А теперь перейдём к представлению, которое будет обрабатывать авторизацию, как со страницы авторизации, так и с люой другой страницы.

   Для Django рекомендую VDS-сервера хостера Timeweb .

   
   

   Рекомендуем хостинг TIMEWEB

   Стабильный хостинг, на котором располагается социальная сеть EVILEG. Для проектов на Django рекомендуем VDS хостинг.

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

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

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

   К концу вы научитесь:

   Начало работы

   Чтобы лучше понять авторизацию, вам понадобится проект для экспериментов. Код в этом руководстве очень похож на код, показанный в уроках 1 и 2. Вы можете продолжить, загрузив образец кода по ссылке ниже:

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

   Создание проекта

   Сначала вам нужно создать новый проект Django. Поскольку Django не входит в стандартную библиотеку, рекомендуется использовать виртуальную среду. Когда у вас будет виртуальная среда, вам нужно будет выполнить следующие шаги:

   • Установите Django.
   • Создайте новый проект.
   • Создайте приложение внутри проекта.Добавьте в проект каталог шаблонов.
   • Создайте суперпользователя сайта.

   Для этого используйте следующие команды:

   Теперь у вас есть проект блога, но вам все равно нужно сообщить Django о созданном вами приложении и новом каталоге, который вы добавили для шаблонов. Вы можете сделать это, изменив файл Blog/settings.py, сначала изменив INSTALLED_APPS :

   Выделенная строка указывает на добавление основного приложения в список установленных приложений. После добавления приложения вам необходимо изменить объявление TEMPLATES :

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

   Образец сайта, с которым вы будете работать, — это базовое приложение для ведения блога. Основному приложению необходим файл models.py, содержащий модели, хранящие контент блога в базе данных. Отредактируйте core/models.py и добавьте следующее:

   Теперь о некоторых веб‑страницах. Создайте два представления: одно для перечисления всех блогов и одно для просмотра блога. Код для ваших представлений находится в core/views.py:

   Добавление данных

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

   Обнаружение вошедших в систему пользователей и их ролей в представлении

   Теперь добавьте новое представление в Blog/urls/py:

   Все пользовательские объекты, включая AnonymousUser, имеют некоторые атрибуты, которые дают вам больше информации о пользователе. Чтобы увидеть, как это работает, добавьте следующий код в core/views.py:

   Добавьте это представление в Blog/urls.py:

   Если пользователь вошел в систему, is_anonymous изменится с True на False . Атрибут имени пользователя сообщает вам, кто является пользователем. В этом случае вы вошли в систему с учетной записью суперпользователя, созданной с помощью команды manage.py createduperuser . Атрибуты is_staff , is_superuser и is_active теперь имеют значение True .

   Django использует сеансы для управления состоянием пользователя. Сессии управляются с помощью промежуточного программного обеспечения. Вы можете узнать больше об этих концепциях в документации Django по сеансам и промежуточному программному обеспечению.

   Реализация авторизации Django View

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

   В Python есть функция, называемая декораторами. Декоратор — это способ обернуть функцию другой функцией. Django использует эти декораторы для обеспечения аутентификации. Чтобы узнать больше о том, как работают декораторы, ознакомьтесь со статьёй Декораторы в Python.

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

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

   Чтобы увидеть @login_required в действии, добавьте приведенный выше код в core/views.py и зарегистрируйте связанный URL в Blog/urls.py:

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

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

   Сначала добавьте URL‑адреса авторизации в Blog/urls.py:

   Это позволяет вам использовать все встроенные представления аутентификации Django. Вам также понадобится соответствующий шаблон входа в систему. Создайте подпапку Registration/ в templates/, а затем создайте в ней login.html:

   Ограничение просмотра для администраторов и персонала

   Вы написали представление Django с авторизацией. Но авторизация может быть более сложной, чем просто проверка подлинности пользователя. У Django из коробки три роли:

   1. Пользователь.
   2. Штат сотрудников.
   3. Суперпользователь.

   В представлении private_place() выше используется декоратор @login_required , чтобы узнать, аутентифицирован ли пользователь и активна ли его учетная запись. Вы также можете авторизоваться на основе трех ролей.

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

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

   
   

   Прокрутите вниз и нажмите Save and add another. И снова вам будет предложено создать пользователя. На этот раз создайте silvia. При запросе дополнительных сведений о silvia прокрутите вниз до раздела Разрешения и установите флажок Staff status:
   Установим роль Status staff

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

   Теперь у вас есть постоянный пользователь, сотрудник,и суперпользователь. Используя эти три учетные записи, попробуйте посетить /admin/, /private_place/ и /user_info/, чтобы увидеть различия.

   Декоратор @login_required — это все или ничего: вы либо вошли в систему, либо нет. В Django также есть декоратор @user_passes_test. Этот декоратор позволяет вам указать проверку, которая позволяет пользователю войти, если она пройдена.Попробуйте добавить это представление в core/views.py:

   Декоратор @user_passes_test принимает хотя бы один параметр — тест, который нужно пройти. Этот тест является либо функцией, либо, чаще всего, лямбда. Если вы раньше не видели лямбду, подумайте о ней как о миниатюрной анонимной функции. После ключевого слова лямбда идет именованный параметр лямбда, которым в данном случае является пользователь. Справа от двоеточия ( : ) находится тест.

   Создав новое представление, обновите файл Blog/urls.py, чтобы зарегистрировать его:

   • Bob не является сотрудником, поэтому его отправляют обратно на страницу входа.
   • Silvia — сотрудник, поэтому она может видеть вид.
   • superuser — это одновременно и штатный, и суперпользователь, и он также может войти.

   Команда manage.py createduperuser , которую вы использовали для создания суперпользователя, автоматически устанавливает учетные записи суперпользователя как штатные.

   Под обложками декоратор @login_required фактически вызывает декоратор @user_passes_test и использует следующий тест:

   Все, что делает декоратор @login_required — это проверяет, что значение is_authenticated пользователя равно True , что будет иметь место для любой аутентифицированной учетной записи.

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

   Чтобы использовать messages.add_message() , вам необходимо зарегистрировать представление как URL:

   Заключение

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

   В этом уроке вы узнали, как:

   Чтобы воссоздать примеры, которые вы видели выше, вы можете загрузить образец кода по ссылке.

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

   ст. преп. кафедры ЦЭиИТ. Автор более 130 научных и учебно-методических работ. Лауреат ВДНХ (серебряная медаль). Посмотреть больше записей

   На предыдущем занятии мы рассмотрели механизм регистрации пользователей. Продолжим эту тему и поговорим об авторизации пользователей на сайте.

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

   
   

   Если же пользователь не авторизован, то на сайте должен быть реализован механизм авторизации. Обычно, это форма, где пользователь вводит логин и пароль:

   
   

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

   Итак, первым делом добавим в файле views.py класс представления, отвечающий за отображение формы авторизации:

   В качестве базового класса используется LoginView, в котором реализована вся необходимая логика работы, а также стандартный класс формы AuthenticationForm. Затем, мы указываем наш шаблон login.html для отображения формы со стандартным содержимым:

   Осталось в файле urls.py связать маршрут login с нашим классом представления:

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

   в файле settings.py пакета конфигурации coolsite.

   Следующим шагом улучшим отображение формы авторизации. Для этого в файле forms.py пропишем класс LoginUserForm, унаследовав его от базового AuthenticationForm:

   И, затем, укажем его в классе представления LoginUser:

   Также в шаблоне login.html сделаем вывод полей через цикл:

   Обратите внимание, вначале не забываем делать отображение общих ошибок коллекции form.non_field_errors. Теперь форма выглядит гораздо лучше.

   Мы здесь используем стандартную функцию logout() фреймворка Django для выхода пользователя. А, затем, перенаправляем его на форму авторизации.

   В принципе, в базовом варианте авторизация готова. Но мы сделаем еще одно улучшение. При успешной регистрации пользователя будем автоматически его авторизовывать, что, мне кажется логичным действием. Для этого, в классе RegisterUser переопределим специальный метод form_valid():

   Он отрабатывает при успешной проверки формы регистрации, а значит, при успешной регистрации. Здесь мы самостоятельно сохраняем форму (добавляем пользователя в БД), а затем, вызываем функцию фреймворка Django login для авторизации пользователя. После этого, делаем перенаправление на главную страницу.

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

   Видео по теме

   
   

   
   

   
   

   
   

   
   

   
   

   
   

   
   

   
   

   
   

   
   

   
   

   
   

   
   

   
   

   
   

   
   

   
   

   
   

   
   

   
   

   
   

   
   

   
   

   
   

   
   

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

   А что подразумевает такая регистрация? Это будет полноценный джанго-юзер, со всеми вытекающими возможностями, или же у него будет какой-то ограниченный функционал? Если это полноценный юзер, тогда нужно переопределить стандартную модель юзера, чтобы вместо юзернэйма был телефон. А если же ограниченный юзер, то можно написать собственную апликуху для данных юзеров, с любыми необходимыми Вам полями. 😉

   А что подразумевает такая регистрация? Это будет полноценный джанго-юзер, со всеми вытекающими возможностями, или же у него будет какой-то ограниченный функционал?

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

   Как раз один тип юзера, и как быть с юзернеймом? Есть идея записывать в поле юзернейм номер или токен (кто как захочет), а потом проверять регуляркой и делать ветвления. Или можете посоветовать что то лучшее?

   Нужно переопределять тогда модель стандартного юзера. Вот пример кода, где в качестве логина, используется email:

   Нужно переопределять тогда модель стандартного юзера. Вот пример кода, где в качестве логина, используется email:

   email = models.EmailField(max_length=255, unique=True)

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

   Регистрации и аутентификации пользователя на Django

   
   

   
   

   К данному моменту мы создали блог на Django, который использует формы для создания, редактирования и удаления статей, однако главный элемент большинства веб-сайтов все еще отсутствует: аутентификация пользователя.

   Содержание статьи

   Есть вопросы по Python?

   На нашем форуме вы можете задать любой вопрос и получить ответ от всего нашего сообщества!

   Telegram Чат & Канал

   Вступите в наш дружный чат по Python и начните общение с единомышленниками! Станьте частью большого сообщества!

   Паблик VK

   Одно из самых больших сообществ по Python в социальной сети ВК. Видео уроки и книги для вас!

   Мы используем объект User для реализации входа, выхода и регистрации пользователя в блоге на Django.

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

   По умолчанию, Django поставляется с представлением LoginView для страницы входа. Нам нужно только настроить:

   Теперь наполните файл следующим контентом:

   Log In

   
   

   После ввода логина и пароля нашего аккаунта мы будем направлены на домашнюю страницу. Обратите внимание, что мы не добавляли никаких логических операции для представления и не создавали модели базы данных. Система аутентификации Django сама предоставляет все необходимое. Спасибо, Django!

   Руководство Django Часть 8: Аутентификация и авторизация пользователя

   В данном руководстве мы продемонстрируем вам систему входа пользователя на ваш сайт используя его собственный аккаунт. Кроме того, мы покажем как реализовать контроль того, что может видеть и делать пользователь, в зависимости от того, залогинен он, или нет, а также имеет ли он соответствующий уровень прав доступа (permissions). Для того чтобы продемонстрировать все это, мы расширим LocalLibrary, добавив страницы для входа/выхода, а также страницы просмотра/редактирования книг, специфические для пользователя и персонала.

   Требования:	Завершить изучение предыдущих тем руководства, включая Руководство Django Часть 7: Работа с сессиями.
   Цель:	Понимать как настроить и использовать механизм аутентификации пользователя и разграничений прав доступа.

   Обзор

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

   В данном разделе руководства мы покажем вам реализацию аутентификации пользователя на сайте LocalLibrary, создание страниц входа/выхода, добавления разграничения доступа (permissions) к вашим моделям, а также продемонстрируем контроль за доступом к некоторым страницам. Мы будем использовать аутентификацию/авторизацию для показа пользователям и сотрудникам библиотеки, списков книг, которые были взяты на прокат.

   Мы покажем вам как реализовать разграничение доступа (permissions), а также выполнять соответствующую проверку статусов авторизации и прав доступа, в отображениях, и в шаблонах страниц.

   Подключение аутентификации

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

   Соответствующие настройки сделаны в параметрах INSTALLED_APPS и MIDDLEWARE файла проекта (locallibrary/locallibrary/settings.py), как показано ниже:

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

   Вы уже создали своего первого пользователя когда мы рассматривали Административная панель сайта Django в части 4 (это был суперпользователь, созданный при помощи команды python manage.py createsuperuser ). Наш суперпользователь уже авторизован и имеет все необходимые уровни доступа к данным и функциям, таким образом нам необходимо создать тестового пользователя для отработки соответствующей работы сайта. В качестве наиболее быстрого способа, мы будем использовать административную панель сайта для создания соответствующих групп и аккаунтов locallibrary.

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

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

   
   

   В первую очередь, в качестве нового члена нашего сайта, давайте создадим новую группу.

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

   Настройка представлений проверки

   Django предоставляет почти все, что нужно для создания страниц аутентификации входа, выхода из системы и управления паролями из коробки. Это включает в себя url-адреса, представления (views) и формы,но не включает шаблоны — мы должны создать свой собственный шаблон!

   В этом разделе мы покажем, как интегрировать систему по умолчанию в Сайт LocalLibrary и создать шаблоны. Мы поместим их в основные URL проекта.

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

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

   Проектирование URLs

   Добавьте следующее в нижней части проекта urls.py файл (locallibrary/locallibrary/urls.py) файл:

   Каталог шаблонов

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

   Для этого сайта мы разместим наши HTML-страницы в каталоге templates / registration /. Этот каталог должен находиться в корневом каталоге проекта, то есть в том же каталоге, что и в каталоге и папках locallibrary). Создайте эти папки сейчас.

   Примечание: ваша структура папок теперь должна выглядеть как показано внизу:
   locallibrary (django project folder)
   |_catalog
   |_locallibrary
   |_templates (new)
   |_registration

   Чтобы сделать эти директории видимыми для загрузчика шаблонов ( т. е. помещать этот каталог в путь поиска шаблона ) откройте настройки проекта (/locallibrary/locallibrary/settings.py), и обновите в секции TEMPLATES строку ‘DIRS’ как показано.

   Шаблон аутентификации

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

   Создайте новый HTML файл, названный /locallibrary/templates/registration/login.html. дайте ему следующее содержание :

   
   

   Откройте настройки проекта (/locallibrary/locallibrary/settings.py) и добавьте текст ниже. Теперь, когда вы входите в систему, вы по умолчанию должны перенаправляться на домашнюю страницу сайта.

   Шаблон выхода

   Создайте и откройте /locallibrary/templates/registration/logged_out.html. Скопируйте текст ниже:

   Шаблон сброса пароля

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

   Форма сброса пароля

   Это форма, используемая для получения адреса электронной почты пользователя (для отправки пароля для сброса пароля). Создайте /locallibrary/templates/registration/password_reset_form.html и дайте ему следующее содержание:

   Сброс пароля

   Эта форма отображается после того, как ваш адрес электронной почты будет собран. Создайте /locallibrary/templates/registration/password_reset_done.html, и дайте ему следующее содержание:

   Сброс пароля по email

   Этот шаблон предоставляет текст электронной почты HTML, содержащий ссылку на сброс, которую мы отправим пользователям. Создайте /locallibrary/templates/registration/password_reset_email.html и дайте ему следующее содержание:

   Подтверждение на сброс пароля

   На этой странице вы вводите новый пароль после нажатия ссылки в электронном письме с возвратом пароля. Создайте /locallibrary/templates/registration/password_reset_confirm.html и дайте ему следующее содержание:

   Сброс пароля завершён

   Это последний шаблон сброса пароля, который отображается, чтобы уведомить вас о завершении сброса пароля. Создайте /locallibrary/templates/registration/password_reset_complete.html и дайте ему следующее содержание:

   Тестирование новых страниц аутентификации

   Теперь, когда вы добавили конфигурацию URL и создали все эти шаблоны, теперь страницы аутентификации должны работать! Вы можете протестировать новые страницы аутентификации, попытавшись войти в систему, а затем выйдите из учётной записи суперпользователя, используя эти URL-адреса:

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

   Для получения дополнительной информации см. Отправка email (Django docs).

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

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

   Тестирование в шаблонах

   Откройте базовый шаблон (/locallibrary/catalog/templates/base_generic.html) и скопируйте следующий текст в sidebar блок непосредственно перед тегом шаблона endblock.

   Как вы можете видеть, мы используем теги шаблона if-else-endif для условного отображения текста на основе того, является ли > истинным. Если пользователь аутентифицирован, мы знаем, что у нас есть действительный пользователь, поэтому мы вызываем >, чтобы отобразить их имя.

   Тестирование в представлениях

   Если вы используете функциональные представления, самым простым способом ограничить доступ к вашим функциям является применение login_required декоратор к вашей функции просмотра, как показано ниже. Если пользователь вошёл в систему, ваш код просмотра будет выполняться как обычно. Если пользователь не вошёл в систему, это перенаправит URL-адрес входа, определённый в настройках проекта. ( settings.LOGIN_URL ), передав текущий абсолютный путь в качестве next параметра URL. Если пользователю удастся войти в систему, они будут возвращены на эту страницу, но на этот раз аутентифицированы.

   Для получения дополнительной информации ознакомьтесь с Django docs here.

   Теперь, когда мы знаем, как ограничить страницу определённому пользователю, создайте представление о книгах, которые заимствовал текущий пользователь.

   К сожалению, у нас пока нет возможности пользователям использовать книги! Поэтому, прежде чем мы сможем создать список книг, мы сначала расширим BookInstance модель для поддержки концепции заимствования и использования приложения Django Admin для заимствования ряда книг нашему тестовому пользователю.

   Модели

   Прежде всего, мы должны предоставить пользователям возможность кредита на BookInstance (у нас уже есть status и due_back дата, но у нас пока нет связи между этой моделью и пользователем. Мы создадим его с помощью поля ForeignKey (один ко многим). Нам также нужен простой механизм для проверки того, просрочена ли заёмная книга.

   Откройте catalog/models.py, и импортируйте модель User из django.contrib.auth.models (добавьте это чуть ниже предыдущей строки импорта в верхней части файла, так User доступен для последующего кода, что позволяет использовать его):

   Затем добавьте поле borrower в модель BookInstance :

   Пока мы здесь, давайте добавим свойство, которое мы можем вызвать из наших шаблонов, чтобы указать, просрочен ли конкретный экземпляр книги. Хотя мы могли бы рассчитать это в самом шаблоне, использование свойства, как показано ниже, будет намного более эффективным. Добавьте это где-нибудь в верхней части файла:

   Теперь добавьте следующее определение свойства внутри класса BookInstance:

   Примечание. Сначала мы проверим, является ли due_back пустым, прежде чем проводить сравнение. Пустое поле due_back заставило Django выкидывать ошибку, а не показывать страницу: пустые значения не сопоставимы. Это не то, что мы хотели бы, чтобы наши пользователи испытывали!

   Теперь, когда мы обновили наши модели, нам нужно будет внести новые изменения в проект, а затем применить эти миграции:

   Admin

   Займите несколько книг

   Примечание: Мы не будем описывать процесс, так как вы уже знаете, как использовать Admin сайт!

   Займ в представлении

   Добавьте следующее в catalog/views.py:

   URL-адрес для заёмных книг

   Шаблон для заёмных книг

   Добавить список на боковую панель

   Откройте базовый шаблон (/locallibrary/catalog/templates/base_generic.html) и добавьте выделенную строку из sidebar, как показано на рисунке.

   На что это похоже?

   
   

   Права доступа

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

   Модели

   Откройте catalog/models.py, и добавьте разрешение, как показано выше. Вам нужно будет повторно выполнить миграцию (вызвав python3 manage.py makemigrations и python3 manage.py migrate ) для надлежащего обновления базы данных.

   Шаблоны

   Представления

   Функция в представлении с декоратором:

   Требуется разрешение mixin для представлений на основе классов.

   Пример

   Мы не будем обновлять LocalLibrary здесь; возможно, в следующем уроке!

   Испытайте себя

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

   Важно: Не забудьте использовать вашего суперпользователя для тестирования на основе разрешений (проверки разрешений всегда возвращают true для суперпользователей, даже если разрешение ещё не определено!). Вместо этого создайте пользователя-библиотекаря и добавьте необходимые возможности.

   Когда вы закончите, ваша страница должна выглядеть примерно, как на скриншоте ниже.

   
   

   Подводим итоги

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

   Читайте также:

     
   • Разлочка айфона 4s своими руками
     
   • Тюнинг навара своими руками
     
   • Замена передних стоек ниссан теана j32 своими руками
     
   • Как сделать запись экрана на компьютере со звуком без программ
     
   • Замена датчика коленвала ниссан альмера классик своими руками