Авторизация

1.

Авторизация

2.

Авторизация — предоставление определённому лицу или группе лиц прав на выполнение определённых действий;
а также процесс проверки данных прав при попытке выполнения этих действий.
Для добавления проверки пользователя необходимо добавить данные о пользователе, который вносит изменения
в запись таблицы. В наше приложение энциклопедию добавим в таблицу с данными об известном человеке,
который добавил запись.
Не забывайте мигрировать изменения
при внесении обновлений в модели
Создадим представления с помощью классов
и пропишем URL

3.

На данный момент любой пользователь может совершенно спокойно удалять, добавлять, изменять и читать записи
из БД Men, используя соответствующие URL-запросы. Такое поведение нужно ограничивать. Как раз для этого и
используются permisions.
В базовом варианте фреймворка Django REST, они следующие:
AllowAny – полный доступ;
IsAuthenticated – только для авторизованных пользователей;
IsAdminUser – только для администраторов;
IsAuthenticatedOrReadOnly – только для авторизованных или всем, но для чтения.
Добавить эти разрешения можно просто добавив параметр permission_classes в наши классы. Разрешим всем
пользователям просмотр данных и только авторизованным их изменение.

4.

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

5.

Также у нас есть возможность создать пользовательские разрешения. Например, разрешим админу изменять
данные, а остальным только просматривать.
Для этого создадим файл permissions.py и в него будем вносить наши настройки для разрешений. Рассмотрим
базовый класс для создания своих ограничений
Первый метод has_permission позволяет
настраивать права доступа на уровне
всего запроса (от клиента), а второй
метод has_object_permission – права
доступа на уровне отдельного объекта
(данных, записи БД).
Изменим настройки базового класса по нашему примеру
Внутри класса переопределяем один метод
has_permission и вначале проверяем, если
запрос безопасный (GET, HEAD, OPTIONS), то
доступ разрешаем – возвращаем значение
True. Иначе, проверяем, что пользователь
должен быть администратором.

6.

Также часто используется следующий вариант разрешений: изменять запись может только автор, то есть,
пользователю, который ее добавил. А просматривать, по прежнему, все пользователи. Здесь также понадобится свой
собственный класс permission.
Добавим это ограничение в класс, который позволяет
получать и изменять данные одной записи
Также Django Дает нам установить глобальные настройки разрешений, которые устанавливаем в settings
для всех API-запросов ответ будет отдаваться только
авторизованным пользователям

7.

Авторизация и аутентификация
Авторизация – это когда пользователь входит в систему, обычно по логину и паролю и сервер идентифицирует этого
пользователя. При обращении к закрытым страницам этого сайта (например, личному кабинету) сервер выполняет
аутентификацию пользователя, то есть, проверяет, вошел пользователь в систему или это обычный сторонний
посетитель, которому не следует давать доступ. Таким образом, процессы авторизации и аутентификации
пользователей тесно связаны между собой.
Django REST Framework поддерживает несколько способов авторизации. Среди встроенных и поставляемых с самим
пакетом – это авторизация на основе сессий и токенов. Дополнительно в проектах нередко используют
авторизацию на основе токенов с помощью пакета Djoser, JWT (JSON Web Token) авторизацию, ну и, конечно же, при
необходимости авторизацию через социальные сети с использованием пакета Django REST framework OAuth.
https://www.django-rest-framework.org/api-guide/authentication/

8.

Авторизация на основе сессий
Одним из первых способов авторизации и аутентификации пользователей основывается на cookies браузеров и
сессиях сервера. Он широко используется и поныне. Идея алгоритма очень проста. Чтобы клиент был успешно
идентифицирован на стороне сервера, он прежде должен войти в систему (полагаем, что он в ней уже
зарегистрирован). Для этого сервер отправляет в браузер форму для ввода логина и пароля (опять же, как
пример). Пользователь их вводит и отправляет POST-запрос с данными обратно на сервер. Сервер ищет в БД
пользователя с указанными логином и паролем. Если не находит, то возвращает ошибку, например «Неверная
пара логин/пароль». Если находит, то формирует идентификатор сессии в виде набора произвольных букв и
цифр:
Заносит это значение в таблицу сессий, связывая session_id с пользователем (user_id). Затем, session id
отправляется клиенту и браузер сохраняет его в своих cookies. Это процедура авторизации посредством сессий
и cookies.
Если пользователь авторизован и в браузере хранится id сессии, то он может получать доступ к определенным,
закрытым страницам сайта. Для этого, например, при GET-запросе, в заголовке прописывается строчка:
в которой передается session id. Сервер ищет принятый id сессии с записями в БД и если находит такой session_id,
то идентифицирует пользователя и разрешает ему доступ к закрытым страницам. Если же, по каким-либо
причинам session_id в БД не находится, то авторизация не проходит и доступ остается закрытым.
Как правило, идентификатор сессии существует ограниченное время: от нескольких минут до нескольких месяцев.
Реже – постоянно. Также session id меняется, если пользователь выйдет из системы. В этом случае запись
удаляется из таблицы и повторная попытка зайти под этим же идентификатором уже будет безуспешной.
Пользователю нужно будет снова войти в систему, будет назначен другой session id и доступ вновь будет открыт.

9.

Реализация session-based аутентификации
Для реализации этого способа достаточно в коллекции urlpatterns (в файле urls.py) прописать строчку
И мы автоматически получаем 2 пути: для авторизации и выхода из учетки, и форму для входа.
Чтобы убедиться, что аутентификация пользователя производится по session id, можно открыть в браузере панель
«Инспектор», перейти во вкладку «Network», обновить страницу и здесь можно посмотреть на содержимое
переданного заголовка.
csrftoken для защиты от взлома (подмены
устройства, с которого осуществляется вход)
sessionid, по которому выполняется аутентификация
пользователя.

10.

Аутентификация по токенам. Пакет Djoser
Базовая идея, лежащая во всех подобных алгоритмах, использование определенного ключа (токена) для
идентификации пользователя. Причем токен не привязан ни к домену, ни к браузеру, главное указать его в заголовке
запроса, а откуда он был отправлен – неважно. Благодаря этому сайт легко может взаимодействовать с самыми
разными конечными устройствами при аутентификации пользователей.
В Django REST Framework популярны два подхода при реализации токенов:
• стандартная аутентификация токенами (библиотека Djoser);
• JWT-токены (библиотека Simple JWT).

11.

Идея аутентификации по токенам
Пользователь зарегистрирован на некотором сайте и вводит в форму логин и пароль. Данные отправляются обратно
на сервер POST-запросом и сверяются с БД. Если указанная пара логин/пароль присутствуют в таблице БД, то сервер
возвращает пользователю некую комбинацию из букв и цифр, которая и является токеном. Кроме того, данный
токен заносится в БД на сервере и сохраняется в любом защищенном локальном хранилище на устройстве.
В дальнейшем для аутентификации пользователя в каждом заголовке запроса от него к серверу прописывается
специальная строчка, например:
Сервер читает заголовок запроса, находит запись с токеном, сверяет его по своей БД и если находит, то
пользователь считается авторизованным. Время жизни токена, по умолчанию, достаточно большое (пока
пользователь не выйдет из системы и токен не будет удален из таблицы)

12.

Реализация токенов с помощью пакета Djoser
Для начала его нужно установить
Подключим эту библиотеку к проекту
Первая строка – это подключение стандартной модели таблицы для поддержки токенов, а вторая –
непосредственно пакет Djoser.
Обязательно нужно выполнить миграции для создания таблицы непосредственно в БД.
https://djoser.readthedocs.io/en/latest/authentication_backends.html
Теперь создадим маршруты для Djoser
А также добавим в настроках следующий код

13.

Пройдя по первому маршруту получим ссылку, по которой можно посмотреть информацию о пользователе (если
не админ) и данные всех пользователей (если админ)
Чтобы добавить нового пользователя достаточно отправить post запрос по адресу
http://127.0.0.1:8000/api/auth2/users/ Сделаем это через Postmen

14.

Для авторизации пройдем по 2 URL и добавим token/login/. В postmen Укажем данные для аутентификации
И получим токен
Для отправки токена при подключении, например Postmen, их нужно указать в разделе Headers наш токен

15.

Сейчас в нашем проекте пользователи могут использовать две независимые системы авторизации: через сессии и
токены. Однако, на уровне каждого отдельного класса представления можно конкретизировать способ
аутентификации пользователя. Например, если в классе МenAPIUpdate прописать атрибут authentication_classes с
классом TokenAuthentication, то данные по записи можно получать только при авторизации по токенам
Также разрешим получать доступ к
отдельной записи только авторизованным
пользователям, чтобы при проверке было
более наглядно.
Тогда даже не пройдя аутентификацию токеном мы не получим данные.

16.

Задание
Создать API для классного журнала в котором реализуется аутентификация сессией и токенами для разных
запросов.
БД:
Класс: Название класса (5Б), год обучения, ученики
Ученик: ФИО, возраст, предметы, оценки (оценки можно choises)
Предметы: Название предмета
CRUD для всего. Еще создайте группы пользователей в админке и попробуйте из админки раздать права
разным группам пользователей.