Z1411_tyutterin_Yakov_KR
.pdf
Для представления API для работы с сервисом аутентификации – введен интерфейс, рисунок 13.
Рисунок 13 – Сервис аутентификации.
Его реализация представлена на рисунке 14.
Рисунок 14 – Имплементация сервиса аутентификации
В методе register дополнительно происходит проверка наличия пользователя с почтой, что передал пользователь, чтобы исключить дубли
(Хотя они исключены уже за счет наличия ограничения UNIQUE на уровне
21
таблицы БД). Как было оглашено ранее, пароль не хранится в чистом виде, а
шифруется без возможности дешифрования.
В методе login описана основная логика по авторизации. Первоначально происходит попытка загрузки пользователя из БД на основе переданной почты
(логина), после чего, если пользователь найден, с использованием метода matches проверяется корректность введенного пароля. Если данные корректны
– происходит аутентификация пользователя и генерация токена, по которому,
при последующих запросах, мы сможем идентифицировать пользователя нашей системы. Генерация токена происходит на основе алгоритма HS256 и
соли.
Соль (также модификатор входа хэш-функции) — строка входных данных, которая передаётся хеш-функции вместе с входным массивом данных
(прообразом) для вычисления хэша (образа).
Используется для:
— усложнения определения прообраза хэш-функции методом перебора по словарю возможных входных значений (прообразов); — скрытия факта использования одинаковых прообразов при использовании для них разной соли.
Различают:
— статическую соль (используемую для всех входных значений); —
динамическую соль (генерируемую для каждого входного значения).
Соль и заголовок, в котором мы будем ожидать токен – указан в файле конфигурации. Также описано время жизни токена на случай, если пользователь долго неактивен, рисунок 15.
Рисунок 15 – Конфигурирование безопасности
22
Основную роль в разграничении прав играет конфиг безопасности, где описаны правила доступа к отдельным эндпоинтам в зависимости от того,
аутентифицирован пользователь или нет, и, если да, то какую роль он имеет.
Рисунок 16 – Разграничение доступов.
В результате проделанной работы был разработан API интерфейс для взаимодействия с клиентским сервисом. На рисунках 17-18 представлены страницы аутентификации и регистрации.
Рисунок 17 – Страница регистрации
23
Рисунок 18 – Страница аутентификации
Дополнительно, на клиентской стороне заданы правила отображения стартовой страницы после входа в систему на основе полученной роли. При первой аутентификации, при вводе корректных данных, в локальное хранилище сохраняется токен, который затем будет подвязываться к каждому запросу к BackEnd по названию Authorization. Пользовательская страница и административная представлены на рисунках 19-20.
Рисунок 19 – Панель управления администратора
Рисунок 20 – Пользовательская панель
24
Так как с аутентификацией мы закончили, можно перейти к тем контроллерам, доступ к эндпоинтам которых доступен лишь аутентифицированным пользователям, но помним, что доступ к ним ограничивается за счет наличия ролевой модели.
Для упрощения ориентирования между ними, они были разделены на отдельные пакеты, рисунок 21.
Рисунок 21 – Разграничение по пакетам в зависимости от уровня доступа.
Теперь, когда пользователь аутентифицирован, получить информацию по нему достаточно легко из токена. На основе информации из нее мы можем отобразить его изображение в профиль и личную информацию, которую он указал при регистрации. Эндпоинты, отвечающие за это. Представлены на рисунке 22.
25
Рисунок 22 – Пользовательский контроллер
Также присутствует ранее неупомянутый метод updateImageProfile,
который отвечает за загрузку пользовательского изображения пользователя.
Результат отображения профиля для администратора и пользователя имеет один вид и представлен на рисунке 23.
Рисунок 23 – Профиль пользователя
Результат загрузки нового изображения представлен на рисунках 24-25.
26
Рисунок 24 – Результат загрузки
Рисунок 25 – Результат после автоматической перезагрузки страницы
Изображения сохраняются локально в директорию, указанную в файле конфигурации. Также там прописано стандартное изображение на случай,
если пользователь ничего не задаст. Все это представлено на рисунке 26.
Рисунок 26 – Изображение пользователя
27
Пришло время добавить категории тестов. Начнем с административного контроллера, который будет содержать эндпоинты создания, удаления,
обновления. Путь берется от /api/admin, поэтому доступ к нему будет лишь у администратора портала. Реализация контроллера представлена на рисунке 27.
Рисунок 27 – Административный контроллер управления категориями
Так же, для того чтобы пользователь мог получить информацию о всех доступных категорий, либо же о конкретной, необходимо добавить пользовательский контроллер. Его реализация представлена на рисунке 28.
28
Рисунок 28 – Пользовательский контроллер получения категорий(и).
Для преставления тела запроса и ответа были введены два класса-DTO. Они представлены на рисунках 29-30.
Рисунок 29 – Класс для представления тела запроса
29
Рисунок 30 – Класс для представления тела ответа
Для трансформации DTO в класс-сущность и обратно, введены мапперы.
За счет использования фреймворка MapStruct, добавление маппера становится достаточно легкой задачей. В большинстве случаев для описания логики маппинга не требуется более число затрат, чем от создания интерфейса и объявления нескольких методов. В результате, на этапе компиляции, с
использованием механизма Annotation Processing будут сгенерированы имплементации на основе декларативного описания. Объявление интерфейса и сгенерированная реализация представлены на рисунках 31-32.
Рисунок 31 – Объявление интерфейса
30