Skip to content

Latest commit

 

History

History
89 lines (70 loc) · 10.3 KB

README.md

File metadata and controls

89 lines (70 loc) · 10.3 KB
Raw

Курсовой Проект

Build Project

Формулировка

Взяв за основу лабораторные работы 2-4, реализовать Пользовательский Интерфейс, сделать свою реализацию Identity Provider с OpenID Connect и систему для сбора статистики, которая будет доступна пользователю с правами admin.

Требования к программной реализации

  1. Создать сервис, выполняющий функцию Identity Provider, реализовать протокол OpenID Connect. Реализовать scope:
    • openid – всегда передается, в ответ возвращается JWT;
    • profile – базовая информация о пользователе;
    • email – email пользователя.
  2. Для получения токена на Identity Provider реализовать Authorization Flow. UI рассматривается как 3rd party application и авторизация пользователя так же выполняется через Authorization Flow.
  3. Все методы /api/** (кроме /api/v1/authorize и /api/v1/callback) на всех сервисах закрыть token-based авторизацией. 4Так же реализовать ролевую модель:
    • руками создать пользователя с ролью Admin;
    • для зарегистрированных пользователей по-умолчанию роль User.
  4. На Identity Provider сделать возможность создания новых пользователей (запрос от пользователя с ролью Admin).
  5. Каждый сервис при получении запроса выполняет валидацию JWT токена с помощью JWKs, которые он получает из Identity Provider (запрос к Identity Provider делать не нужно).
  6. JWT токен пробрасывать между сервисами, при получении запроса валидацию токена так же реализовать через JWKs.
  7. Убрать заголовок X-User-Name и получать пользователя из JWT-токена.
  8. Если авторизация некорректная (отсутствие токена, ошибка валидации JWT токена, закончилось время жизни токена (поле exp в payload)), то отдавать 401 ошибку.
  9. Для функционала, реализованного в рамках лабораторных работ, реализовать пользовательский интерфейс как Single Page Application (React, Angular, Vue) или мобильный клиент. Использование CSS обязательно.
  10. Выделить сервис статистики: в него отправлять через Kafka информацию о выполненных действиях. В зависимости от задания по пришедшим данным строить отчет, доступ к которому должен быть только у пользователя с ролью Admin.
  11. Как и в ЛР #4 нужно развернуть Managed Kubernetes Cluster и настроить Ingress Controller (для публикации сервисов наружу можно использовать только Ingress).
  12. Для деплоя использовать helm charts, они должны быть универсальным для всех сервисов и отличаться лишь набором параметров запуска.

Требования к Техническому Заданию

Если вы выбрали для курсового проекта ту же тему, что и в курсе Технология Программирования, то при написании Технического задания нужно учитывать следующее:

Техническое задание является основополагающим документом, по которому ведётся разработка и приёмка работы. Поэтому ТЗ должно быть максимально четким и полным, не допускать двусмысленную трактовку фраз.

Пример

Неправильное ТЗ: "Реализовать систему управления полётами".

Правильное ТЗ (задание 2019-2020 уч. года): "Разработать прототип системы поиска объектов туризма и отдыха на базе веб-интерфейса. Система должна состоять из микросервисов, каждый из которых отвечает за свою задачу: сервис пользовательского интерфейса; сервис авторизации и данных пользовательских аккаунтов; сервис объектов туризма и отдыха; сервис тегов; сервис статистики; сервис агрегирования запросов и предоставления ограниченного функционала для сторонних приложений. Каждый сервис при необходимости может иметь доступ к связанной с ним базе данных, но не должен иметь доступа к базам данных других сервисов. Все запросы между сервисами требуют авторизацию. Запросы пользователей делятся на две категории: запросы, требующие авторизации пользователя, и запросы, доступные для всех пользователей, даже неавторизованных. Все ошибки должны обрабатываться; в случае недоступности некритичного функционала должна осуществляться деградация функциональности. Все действия на сервисах должны логгироваться. Все сервисы должны собираться и разворачиваться через CI/CD."

Требования к Расчетно-Пояснительной Записке

Расчетно-пояснительная записка является документом, описывающим как работает ваша система. Написать ее надо так, как будто вы получаете на поддержку незнакомую систему. Другими словами, любое архитектурное решение, костыль, нетривиальная оптимизация должна иметь пояснение почему сделано именно так.

РПЗ должна состоять из трех частей:

  1. Аналитический раздел. В данном разделе приводится обзор существующих систем описываются основные требования, к системе. Здесь же формулируется бизнес-логика будущей системы.
  2. Конструкторский раздел. Описание архитектуры и алгоритмов, используемых в системе. Если алгоритм стандартный – достаточно поставить ссылку на него. В этом разделе приводится общая схема системы и описание каждого компонента в отдельности. Обязательно описать выделенные сущности, чем они характеризуются, дать описание ролевой модели, описать схему взаимодействия систем с помощью Диаграммы последовательности действий.
  3. Технологический раздел. В данном разделе приводится описание типов и структур данных (структура БД), а также описываются нюансы реализации. Здесь же надо описать как выполняется сборка и деплой системы. Выбор языка (если это С#/Java/Python/Go) писать не надо, это информация не несет никакого смысла. Здесь описывается тестирование системы и ее поведение в случае отказа компонентов, ее составляющих.

Записка должна быть оформлена по ГОСТ 7.32-2017. В конце обязательно привести список литературы.

ТЗ, написанное в рамках лабораторных работ по курсу Технология программирования, не является РПЗ. Из ТЗ можно использовать формальную постановку задачи и требования к системе, их привести в Аналитическом разделе.

Варианты заданий

Распределение вариантов заданий аналогично ЛР #2.