Лабораторная работа № 3 #
Проверяемые знания #
- Знание основ языка HTML.
- Умение структурировать HTML-документы.
- Знание основ языка CSS.
- Умение применять классы CSS к HTML-элементам.
- Умение подключать внешние CSS-файлы к HTML-документу.
- Знание основ маршрутизации HTTP-запросов с помощью библиотеки http4k.
- Умение обрабатывать GET и POST-запросы с помощью библиотеки http4k.
- Умение формировать динамические HTML-страницы с помощью шаблонизатора.
- Умение корректно обрабатывать параметры, приходящие от пользователя:
- Через маршруты к документам.
- Через параметры маршрута.
- Через содержимое интерактивной HTML-формы, приходящей в теле запроса.
- Умение применять средства статического анализа кода Kotlin: ktlint и detekt.
- Умение писать модульные тесты для проверки логики HTTP-обработчиков.
- Знание о возможности предоставления разных функций в зависимости от роли
- Умение формировать безопасное сохранение паролей пользователей.
- Умение работать с сессионными токенами для аутентификации пользователей.
- Знание о структуре JWT-токенов.
- Умение выполнять авторизацию действий пользователя.
Требования к лабораторной работе #
- Результат работы — исходные коды приложения без артефактов сборки приложения (без каталогов
build
,.gradle
,.idea
,bin
). - Приложение должно быть разработано с использованием языка программирования Kotlin.
- Приложение должно использовать актуальную версию библиотеки http4k.
- Просмотр документов должен осуществляться через обработку и отправку GET-запросов.
- Операции по редактированию данных (добавление, редактирование и удаление) должны осуществляться с помощью POST-запросов.
- Операции по фильтрации данных, включая постраничный вывод, должны осуществляться с помощью GET-запросов. Параметры фильтрации данных не должны сбрасываться при переходе между страницами.
- Для стилизации элементов на странице необходимо использовать классы CSS-фреймворков, следует избегать ручного указания CSS-свойств внутри HTML-документов. Вместо этого необходимо описывать собственные CSS-классы.
- Запрещается редактировать CSS-стили, входящие в состав скомпилированных файлов CSS-фреймворка. Если хотите внести в них изменения, то создайте свою собственную сборку из исходных кодов библиотеки.
- Для формирования динамических HTML-документов необходимо использовать шаблонизатор Pebble.
- Приложение должно корректно обрабатывать неправильные данные от пользователя:
- Всегда должны формироваться HTML-документы с корректным содержимым.
- Приложение не должно показывать техническую информацию об исключительных ситуациях, стеках вызова и прочее пользователю. Данные ситуации должны быть явно обработаны внутри вашего кода приложения и преобразованы в сообщения, понятные для пользователя. Запрещено использовать фильтр с перехватом всех исключительных ситуаций (например ServerFilters.CatchAll или подобный ему) приложения при сдаче лабораторной работы.
- В случае отсутствия искомого документа должна отображаться соответствующая страница.
- Приложение должно обеспечивать работу нескольких пользователей одновременно. Действия одного пользователя не должны влиять на работу другого пользователя, например:
- Изменение порядка сортировки данных должно менять представление только у того, кто запросил изменённый порядок.
- Параметры формы, введённые одним пользователем, не должны быть видны другому пользователю.
- Логику проверки данных, поступающих от пользователя, следует выделять в отдельный слой. Можно использовать механизм линз из библиотеки http4k, другую библиотеку или элементы, созданные врунчную.
- Если данные от пользователя не удовлетворяют требованиям приложения, то необходимо показать пользователю форму и предоставить информацию о проблемах с данными и способах их решения.
- Страницы со списками данных должны корректно обрабатывать ситуацию отсутствия данных. Вместо пустой страницы должно присутствовать информационное сообщение о том, что в данном списке нет данных (или что применение фильтров привело к отсутствию результатов).
- Приложение должно соответствовать требованиям к исходному коду, предоставляемыми актуальной версией инструмента ktlint. Конфигурация ktlint должна соответствовать требованиям.
- Рекомендуется исправить все недостатки, на которые указывает инструмент detekt.
- Необходимо подготовить тестовые данные для проверки работоспособности приложения.
- Данных должно быть достаточно. Минимальный объём данных — 10 000 записей на один список данных.
- Данные для проверки можно сгенерировать. Однако они должны быть репрезентативными:
- Числа, включая даты, должны быть распределены на некотором промежутке.
- Названия можно генерировать из базового набора частей. Например 100 фамилий, 100 имён и 100 отчеств должно быть достаточно для создания достаточно уникальных имён для всех записей.
- Данные необходимо считывать при старте приложения из файла, который хранится на жёстком диске рядом с исходными кодами. Можно воспользоваться СУБД для хранения данных, она выполнит чтение и запись данных с жёсткого диска.
- Изменённые данные приложения желательно сохранять на жёстком диске при завершении работы приложения.
- Модульные тесты приложения должны покрывать все сценарии работы HTTP-обработчиков.
- Для аутентификации пользователей необходимо использовать JWT-токены, которые необходимо сохранять в куках.
- Рекомендуется ограничить время жизни куков длиной в 7 дней.
- В рамках JWT-токена разрешено сохранять только идентификаторы пользователя, запрещено размещать информацию по ролям в сессионных токенах.
- При формировании и проверки JWT-токенов необходимо:
- Использовать поля об издателе токена.
- Ограничивать время жизни токена. Рекомендуемое время жизни — 7 дней.
- Помещать идентификатор пользователя в JWT-токен.
- Запрещено использовать куки для решения любых задач кроме хранения аутентификационного токена.
- Запрещено помещать в JWT-токены информацию, которая нужна для решения
Задача #
Разработать веб-приложение, решающее задачу по управлению данными в указанной тематике. Приложение должно:
- Реализовать ролевую модель доступа к данным приложения.
- Обязательными к реализации являются роли неавторизованного пользователя и администратора.
- Необходимо реализовать дополнительно минимум 1 роль. Можно использовать роли, указанные в задании, или сформировать свою.
- Отображать стартовую страницу с описанием предметной области.
- Необходимо отобразить список ролей приложения.
- Для каждой из ролей необходимо дать краткое описание и перечислить список доступных им действий в приложении.
- Обеспечить управление основным списком данных приложения:
- Отображать список на отдельной странице.
- Список должен быть отсортирован по порядку добавления элементов, если не указано иначе.
- Элементы списка на данной странице должны показывать минимально необходимый объём информации.
- На странице со списком реализовать постраничный вывод информации.
- На странице со списком обеспечить фильтрацию данных минимум по двум параметрам.
- Реализовать переход к странице с детальной информацией об элементе.
- Отображать список на отдельной странице.
- На странице с детальной информацией об элементе необходимо:
- Отображать все поля элемента в удобном для восприятия виде.
- Реализовать переход к странице информации о связном элементе или списке элементов.
- Приложение должно позволять добавлять новые элементы в каждый отображаемый список. Необходимо обеспечить:
- Проверку данных во всех полях ввода.
- Указание связных объектов необходимо обеспечить с помощью выбора из выпадающего списка.
- Формирование списка связных полей следует организовать отдельно от процедуры добавления нового элемента.
- Приложение должно обеспечивать редактирование существующих элементов в списке. При работе с формой редактирования должны применяться такие же правила, что и при работе с формой добавления.
- Приложение должно позволять удалять существующие элементы из списка. Удаление элементов должно осуществляться только после подтверждения.
- На всех страницах должен присутствовать блок навигации, позволяющий переходить между стартовой страницей и страницами списков.
- Содержать список пользователей приложения.
- Администратор системы должен иметь возможность просмотра и редактирования списка пользователей.
- Администратор может установить роль пользователя (или конкретные права на операции).
- Другие пользователи системы не должны видеть и уметь взаимодействовать со списком пользователей.
- Список пользователей должен быть доступен по маршруту
/users
. - Административная учётная запись должна быть доступна с именем пользователя
admin
и паролёмadmin
.
- Разрешать добавлять данные в приложение только авторизованным пользователям.
- Разрешать редактировать данные только тому пользователю, который их добавил. Удаление — частный случай редактирования.
- Разрешать удалять данные любых пользователей, если это действие выполняет администратор системы.
- Предоставлять возможность для самостоятельной регистрации новых пользователей в системе.
Все функции лабораторной работы № 2 должны быть реализованы, если обратное явно не указано в требованиях к лабораторной работе № 3.
Распределение задач #
Описание задач можно найти в разделе «Лабораторные работы» → «Задачи».