{"id":20645033,"url":"https://github.com/romanow/rsoi-project","last_synced_at":"2025-04-16T02:10:50.668Z","repository":{"id":39797890,"uuid":"468348031","full_name":"Romanow/rsoi-project","owner":"Romanow","description":"Course project for Distributed Systems course","archived":false,"fork":false,"pushed_at":"2023-04-26T19:09:00.000Z","size":11,"stargazers_count":0,"open_issues_count":0,"forks_count":34,"subscribers_count":1,"default_branch":"master","last_synced_at":"2025-03-29T04:02:28.128Z","etag":null,"topics":["kubernetes","microservices"],"latest_commit_sha":null,"homepage":"","language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/Romanow.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2022-03-10T13:11:24.000Z","updated_at":"2023-03-02T14:20:36.000Z","dependencies_parsed_at":"2024-11-16T16:18:54.033Z","dependency_job_id":"1cdb0581-db69-4a60-a56c-7575661dd77a","html_url":"https://github.com/Romanow/rsoi-project","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Romanow%2Frsoi-project","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Romanow%2Frsoi-project/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Romanow%2Frsoi-project/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Romanow%2Frsoi-project/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Romanow","download_url":"https://codeload.github.com/Romanow/rsoi-project/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":249183106,"owners_count":21226142,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["kubernetes","microservices"],"created_at":"2024-11-16T16:18:28.295Z","updated_at":"2025-04-16T02:10:50.650Z","avatar_url":"https://github.com/Romanow.png","language":"Shell","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Курсовой Проект\n\n[![Build Project](https://github.com/Romanow/rsoi-project/actions/workflows/build.yml/badge.svg?branch=master)](https://github.com/Romanow/rsoi-project/actions/workflows/build.yml)\n\n## Формулировка\n\nВзяв за основу лабораторные работы 2-4, реализовать Пользовательский Интерфейс, сделать свою реализацию Identity\nProvider с OpenID Connect и систему для сбора статистики, которая будет доступна пользователю с правами `admin`.\n\n## Требования к программной реализации\n\n1. Создать сервис, выполняющий функцию Identity Provider, реализовать протокол OpenID Connect. Реализовать scope:\n    * `openid` – всегда передается, в ответ возвращается JWT;\n    * `profile` – базовая информация о пользователе;\n    * `email` – email пользователя.\n2. Для получения токена на Identity Provider реализовать Authorization Flow. UI рассматривается как 3rd party\n   application и авторизация пользователя так же выполняется через Authorization Flow.\n3. Все методы `/api/**` (кроме `/api/v1/authorize` и `/api/v1/callback`) на всех сервисах закрыть token-based\n   авторизацией. 4Так же реализовать ролевую модель:\n    * руками создать пользователя с ролью `Admin`;\n    * для зарегистрированных пользователей по-умолчанию роль `User`.\n5. На Identity Provider сделать возможность создания новых пользователей (запрос от пользователя с ролью `Admin`).\n6. Каждый сервис при получении запроса выполняет валидацию [JWT](https://jwt.io/introduction) токена с\n   помощью [JWKs](https://auth0.com/docs/security/tokens/json-web-tokens/json-web-key-sets), которые он получает из\n   Identity Provider (запрос к Identity Provider делать не нужно).\n7. JWT токен пробрасывать между сервисами, при получении запроса валидацию токена так же реализовать через JWKs.\n8. Убрать заголовок `X-User-Name` и получать пользователя из JWT-токена.\n9. Если авторизация некорректная (отсутствие токена, ошибка валидации JWT токена, закончилось время жизни токена\n   (поле `exp` в payload)), то отдавать 401 ошибку.\n10. Для функционала, реализованного в рамках лабораторных работ, реализовать пользовательский интерфейс как Single Page\n    Application ([React](https://reactjs.org/), [Angular](https://angular.io/), [Vue](https://vuejs.org/)) или мобильный\n    клиент. Использование CSS обязательно.\n11. Выделить сервис статистики: в него отправлять через Kafka информацию о выполненных действиях. В зависимости от\n    задания по пришедшим данным строить отчет, доступ к которому должен быть только у пользователя с ролью `Admin`.\n12. Как и в [ЛР #4](https://github.com/bmstu-rsoi/lab4-template) нужно развернуть Managed Kubernetes Cluster и настроить\n    Ingress Controller (для публикации сервисов наружу можно использовать _только_ Ingress).\n13. Для деплоя использовать [helm charts](https://helm.sh/docs/topics/charts/), они должны быть универсальным для всех\n    сервисов и отличаться лишь набором параметров запуска.\n\n## Требования к Техническому Заданию\n\nЕсли вы выбрали для курсового проекта ту же тему, что и в курсе Технология Программирования, то при написании\nТехнического задания нужно учитывать следующее:\n\nТехническое задание является основополагающим документом, по которому ведётся разработка и приёмка работы. Поэтому ТЗ\nдолжно быть максимально четким и полным, не допускать двусмысленную трактовку фраз.\n\n### Пример\n\n_Неправильное ТЗ_: \"Реализовать систему управления полётами\".\n\n_Правильное ТЗ (задание 2019-2020 уч. года)_: \"Разработать прототип системы поиска объектов туризма и отдыха на базе\nвеб-интерфейса. Система должна состоять из микросервисов, каждый из которых отвечает за свою задачу: сервис\nпользовательского интерфейса; сервис авторизации и данных пользовательских аккаунтов; сервис объектов туризма и отдыха;\nсервис тегов; сервис статистики; сервис агрегирования запросов и предоставления ограниченного функционала для сторонних\nприложений. Каждый сервис при необходимости может иметь доступ к связанной с ним базе данных, но не должен иметь доступа\nк базам данных других сервисов. Все запросы между сервисами требуют авторизацию. Запросы пользователей делятся на две\nкатегории: запросы, требующие авторизации пользователя, и запросы, доступные для всех пользователей, даже\nнеавторизованных. Все ошибки должны обрабатываться; в случае недоступности некритичного функционала должна\nосуществляться деградация функциональности. Все действия на сервисах должны логгироваться. Все сервисы должны собираться\nи разворачиваться через CI/CD.\"\n\n## Требования к Расчетно-Пояснительной Записке\n\nРасчетно-пояснительная записка является документом, описывающим как работает ваша система. Написать ее надо так, как\nбудто вы получаете на поддержку незнакомую систему. Другими словами, любое архитектурное решение, костыль, нетривиальная\nоптимизация должна иметь пояснение почему сделано именно так.\n\nРПЗ должна состоять из трех частей:\n\n1. **Аналитический раздел.** В данном разделе приводится обзор существующих систем описываются основные требования, к\n   системе. Здесь же формулируется бизнес-логика будущей системы.\n1. **Конструкторский раздел.** Описание архитектуры и алгоритмов, используемых в системе. Если алгоритм стандартный –\n   достаточно поставить ссылку на него. В этом разделе приводится общая схема системы и описание каждого компонента в\n   отдельности. Обязательно описать выделенные сущности, чем они характеризуются, дать описание ролевой модели, описать\n   схему взаимодействия систем с помощью Диаграммы последовательности действий.\n1. **Технологический раздел.** В данном разделе приводится описание типов и структур данных (структура БД), а также\n   описываются нюансы реализации. Здесь же надо описать как выполняется сборка и деплой системы. Выбор языка (если это\n   С#/Java/Python/Go) писать не надо, это информация не несет никакого смысла. Здесь описывается тестирование системы и\n   ее поведение в случае отказа компонентов, ее составляющих.\n\nЗаписка должна быть оформлена по ГОСТ 7.32-2017. В конце обязательно привести список литературы.\n\nТЗ, написанное в рамках лабораторных работ по курсу Технология программирования, не является РПЗ. Из ТЗ можно\nиспользовать формальную постановку задачи и требования к системе, их привести в Аналитическом разделе.\n\n### Варианты заданий\n\nРаспределение вариантов заданий аналогично [ЛР #2](https://github.com/bmstu-rsoi/lab2-template).","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fromanow%2Frsoi-project","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fromanow%2Frsoi-project","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fromanow%2Frsoi-project/lists"}