Лабораторная работа № 3

Лабораторная работа № 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. Реализовать ролевую модель доступа к данным приложения.
    • Обязательными к реализации являются роли неавторизованного пользователя и администратора.
    • Необходимо реализовать дополнительно минимум 1 роль. Можно использовать роли, указанные в задании, или сформировать свою.
  2. Отображать стартовую страницу с описанием предметной области.
    • Необходимо отобразить список ролей приложения.
    • Для каждой из ролей необходимо дать краткое описание и перечислить список доступных им действий в приложении.
  3. Обеспечить управление основным списком данных приложения:
    1. Отображать список на отдельной странице.
      • Список должен быть отсортирован по порядку добавления элементов, если не указано иначе.
      • Элементы списка на данной странице должны показывать минимально необходимый объём информации.
    2. На странице со списком реализовать постраничный вывод информации.
    3. На странице со списком обеспечить фильтрацию данных минимум по двум параметрам.
    4. Реализовать переход к странице с детальной информацией об элементе.
  4. На странице с детальной информацией об элементе необходимо:
    1. Отображать все поля элемента в удобном для восприятия виде.
    2. Реализовать переход к странице информации о связном элементе или списке элементов.
  5. Приложение должно позволять добавлять новые элементы в каждый отображаемый список. Необходимо обеспечить:
    1. Проверку данных во всех полях ввода.
    2. Указание связных объектов необходимо обеспечить с помощью выбора из выпадающего списка.
    3. Формирование списка связных полей следует организовать отдельно от процедуры добавления нового элемента.
  6. Приложение должно обеспечивать редактирование существующих элементов в списке. При работе с формой редактирования должны применяться такие же правила, что и при работе с формой добавления.
  7. Приложение должно позволять удалять существующие элементы из списка. Удаление элементов должно осуществляться только после подтверждения.
  8. На всех страницах должен присутствовать блок навигации, позволяющий переходить между стартовой страницей и страницами списков.
  9. Содержать список пользователей приложения.
    1. Администратор системы должен иметь возможность просмотра и редактирования списка пользователей.
    2. Администратор может установить роль пользователя (или конкретные права на операции).
    3. Другие пользователи системы не должны видеть и уметь взаимодействовать со списком пользователей.
    4. Список пользователей должен быть доступен по маршруту /users.
    5. Административная учётная запись должна быть доступна с именем пользователя admin и паролём admin.
  10. Разрешать добавлять данные в приложение только авторизованным пользователям.
  11. Разрешать редактировать данные только тому пользователю, который их добавил. Удаление — частный случай редактирования.
  12. Разрешать удалять данные любых пользователей, если это действие выполняет администратор системы.
  13. Предоставлять возможность для самостоятельной регистрации новых пользователей в системе.

Все функции лабораторной работы № 2 должны быть реализованы, если обратное явно не указано в требованиях к лабораторной работе № 3.

Распределение задач #

Описание задач можно найти в разделе «Лабораторные работы» → «Задачи».

© A. M. Васильев, 2023, CC BY-SA 4.0, andrey@crafted.su