Лабораторная работа № 4 #

Проверяемые знания #

• Знание основ языка HTML.
• Умение структурировать HTML-документы.
• Знание основ языка CSS.
• Умение применять классы CSS к HTML-элементам.
• Умение подключать внешние CSS-файлы к HTML-документу.
• Умение использовать CSS-стили фреймворка.
• Умение формировать динамические HTML-страницы на основе данных.
• Умение считывать информацию из структурированных файлов.
• Знание основ маршрутизации HTTP-запросов с помощью библиотеки http4k.
• Умение обрабатывать GET и POST-запросы с помощью библиотеки http4k.
• Умение формировать динамические HTML-страницы с помощью шаблонизатора.
• Умение корректно обрабатывать параметры, приходящие от пользователя:
  • Через маршруты к документам.
  • Через параметры маршрута.
  • Через содержимое интерактивной HTML-формы, приходящей в теле запроса.
  • Через содержимое HTML-формы, закодированной в поток данных.
• Умение применять средства статического анализа кода Kotlin: ktlint и detekt.
• Умение писать модульные тесты для проверки логики HTTP-обработчиков.
• Знание о возможности предоставления разных функций в зависимости от роли
• Умение формировать безопасное сохранение паролей пользователей внутри приложения.
• Умение работать с сессионными токенами для аутентификации пользователей.
• Знание о структуре JWT-токенов.
• Умение выполнять авторизацию действий пользователя.

Требования к лабораторной работе #

• Результат работы — исходные коды приложения без артефактов сборки приложения (без каталогов bin, build, .gradle, .idea) и без журналов работы приложения (без каталога logs).
  • Не надо добавлять в архив с исходными кодами файлы, которые не нужны для компиляции, запуска. Исключением является — документация по работе приложения.
  • В передаваемом архиве должны отсутствовать результаты работы приложения. Приложение должно запускаться и продуцировать результаты на любом компьютере, удовлетворяющем требованиям.
  • В передаваемом архиве должны находиться данные, которые необходимы приложению для запуска. Такие данные не должны быть размещены в каталоге с исходными кодами приложения.
• Приложение должно запускаться из любого каталога, не должно быть привязок к местоположению каталога приложения в абсолютных путях.
• Приложение должно быть разработано с использованием языка программирования Kotlin.
• Приложение должно быть разбито на логические части: функции, пакеты и классы.
• HTML-код внутри создаваемых документов должен соответствовать спецификации HTML5.
• Для стилизации элементов на странице необходимо использовать классы CSS-фреймворков, запрещено указание CSS-свойств внутри HTML-кода.
  • Если требуется доработка CSS-свойств HTML-элементов, то необходимо определить CSS-классы в CSS-файлах, подключить данные файлы к нужным HTML-документам и применить классы к нужным элементам.
• Для указания пути к HTML-документам внутри приложения необходимо использовать относительные пути. Запрещено использование абсолютных путей.
• Для формирования HTML-документов рекомендуется использовать шаблонизатор.
• В созданных HTML-документах должна находится общая навигационная панель, позволяющая переходить между ключевыми разделами сайта.
• Приложение должно корректно обрабатывать некорректные данные от пользователя:
  • Всегда должны формироваться HTML-документы с корректным содержимым.
  • Приложение не должно показывать техническую информацию об исключительных ситуациях, стеках вызова и прочее пользователю. Данные ситуации должны быть явно обработаны внутри вашего кода приложения и преобразованы в сообщения, понятные для пользователя. Для решения этой задачи запрещено использовать фильтр с перехватом всех исключительных ситуаций приложения.
  • В случае отсутствия искомого документа должна отображаться соответствующая страница.
• Логику проверки данных, поступающих от пользователя, следует выделять в отдельный слой.
• Страницы со списками данных должны корректно обрабатывать ситуацию отсутствия данных. Вместо пустой страницы должно присутствовать информационное сообщение о том, что в данном списке нет данных.
• Приложение должно соответствовать требованиям к исходному коду, предоставляемыми актуальной версией инструмента ktlint. Конфигурация ktlint должна соответствовать требованиям.
• Рекомендуется исправить все недостатки, на которые указывает инструмент detekt.
• В приложении и в используемых файлах не должны систематически дублироваться данные. Для описания одной сущности приложения в глобальном хранилище данных должно хранится не более одной копии
• Рекомендуется разработать модульные тесты для проверки работоспособности HTTP-обработчиков.
• Приложение должно обрабатывать HTTP-запросы по порту 9000.
  • Приложение должно формировать только частичные URI. Запрещено использовать полные URI.
• Необходимо подготовить тестовые данные для проверки работоспособности приложения.
  • Данных должно быть достаточно. Минимальный объём данных — 1000 записей на один список данных.
  • Данные для проверки можно сгенерировать. Однако они должны быть репрезентативными:
    • Числа, включая даты, должны быть распределены на некотором временном промежутке.
    • Названия можно генерировать из базового набора частей. Например 10 фамилий, 10 имён и 10 отчеств должно быть достаточно для создания достаточно уникальных имён для всех записей.
  • Данные необходимо считывать при старте приложения из файла, который хранится на файловой системе рядом с исходными кодами.
• Данные, изменённые пользователем в результате работы с приложением, должны сохраняться на файловой системе. При следующем запуске приложения эти данные должны быть считаны приложением и доступны пользователю для работы.
• Для аутентификации пользователей необходимо использовать JWT-токены, которые необходимо сохранять в куках.
  • Рекомендуется ограничить время жизни куков длиной в 7 дней.
• Запрещено использовать куки для решения любых задач кроме хранения аутентификационного токена.
• В рамках JWT-токена разрешено сохранять только идентификаторы пользователя, запрещено размещать другуие данные, например роль пользователя.
• При формировании и проверки JWT-токенов необходимо:
  • Использовать поля об издателе токена.
  • Ограничивать время жизни токена. Рекомендуемое время жизни — 7 дней.
  • Помещать идентификатор пользователя в JWT-токен.
• Запрещено помещать в JWT-токены информацию, которая нужна для решения задач.
• Рекомендуется реализовать процедуру обновления JWT-токена.

Задача #

Разработать веб-приложение, решающее задачу по отображению большого объёма данных по указанной тематике. Приложение должно:

1. Отображать стартовую страницу с описанием предметной области.
2. Обеспечить отображение ключевых списков данных приложения:
   1. Отображать список на отдельной странице.
      • Список должен быть отсортирован по порядку добавления элемента, если не указано иначе.
      • Элементы списка на данной странице должны показывать минимально необходимый объём информации.
   2. На странице со списком реализовать постраничный вывод информации.
   3. На странице со списком обеспечить фильтрацию данных минимум по двум параметрам.
   4. Реализовать переход к странице с детальной информацией об элементе.
3. На странице с детальной информацией об элементе необходимо:
   1. Отображать все поля элемента в удобном для восприятия виде.
   2. Реализовать переход к странице информации о связном элементе или списке элементов.
   3. Реализовать отображение элементов связных списков.
4. На всех страницах должен присутствовать блок навигации, позволяющий переходить между стартовой страницей и ключевыми страницами приложения.
5. Приложение должно позволять изменять каждый отображаемый список данных (минимум 2 ключевых списка приложения):
   1. Пользователю должна быть доступна возможность добавления элементов в список.
   2. Пользователю должна быть доступна возможность редактирования элемента в списке.
   3. Пользователю должна быть доступна возможность удаления элементов из списка.
6. При добавлении и редактировании данных приложение должно выполнять техническую и логическую проверку данных. При возникновении ошибки ввода приложение должно показать форму со всеми данными, введёнными пользователем, и сообщениями об ошибках ввода.
7. При удалении данных приложение должно запрашивать у пользователя подтверждение действий. Для удаления пользователю необходимо совершить минимум два действия.
8. Содержать список пользователей приложения.
   1. Приолжение должно предоставлять возможность для самостоятельной регистрации новых пользователей.
   2. Список пользователей должен быть доступен по маршруту /users.
   3. Административная учётная запись должна быть доступна с именем пользователя admin и паролём admin.
   4. Администратор системы должен иметь возможность просмотра и редактирования списка пользователей.
   5. Администратор может установить роль пользователя (или конкретные права на операции).
   6. Другие пользователи системы не должны видеть и уметь взаимодействовать со списком пользователей в разрезе предоставления и управления их правами.
9. Предоставлять разным пользователям приложения разные возможности.
   1. Только авторизованные пользователи могут добавлять данные в приложение.
   2. Только автор данных их может изменять и удалять.
   3. Администратор системы может удалять любые данные внутри приложения. Удаление данных не должно приводить к потере работоспособности приложения.

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

Список ролей и действий в приложении следует брать из задачи к лабораторной работе № 4.