# README
РАЗРАБОТКА ИНФОРМАЦИОННОЙ СИСТЕМЫ ОНЛАЙН ДИРЕКЦИИ ИНСТИТУТА
Цель работы: разработка информационной системы для обеспечения деятельности дирекции института. Предметная область: автоматизация работы дирекции института.
В современных условиях образовательные учреждения сталкиваются с необходимостью повышения эффективности управления и оптимизации внутренних процессов. Информационная система, предложенная в рамках данной работы, призвана решить ряд проблем, связанных с управлением и координацией деятельности дирекции института.
Разработанная информационная система предоставляет эффективные инструменты для улучшения управления и координации деятельности дирекции института. Внедрение данной системы позволит сократить временные и материальные затраты, повысить точность и доступность данных, а также улучшить коммуникацию внутри института. Это, в свою очередь, будет способствовать повышению общего уровня управления образовательным учреждением и улучшению качества предоставляемых образовательных услуг.
Структура ИС
ИС представляет собой микросервисную архитектуру, состоящую из двух сервисов: – Сервис аутентификации, использующий систему удаленного вызова процедур gRPC. Его основная функция – регистрация и аутентификация пользователей ИС. После успешной аутентфикации пользователя, сервис генерирует и возвращает JWT для доступа к сервису дирекции. Без токена выполнение операций пользователем в дирекции невозможно. – Сервис дирекции – это основное приложение ИС, которое реализует все методы, описанные в данной курсовой работе. Архитектурный стиль данного сервиса – REST API, бдагодаря чему клиентами сервиса могут выступать как бразуеры, так и мобильные приложения. Помимо этого, сервис авторизует пользователя, выдавая ему права доступа.
Каждый сервис имеет свою собственную БД SQLite 3. Языком программирования обоих сервисов является Go. Форматом документов общения с сервисами выступает JSON. Использующийся протокол передачи данных – HTTP.
Политика разграничения доступа
В сервисе дирекции используется ролевая модель управления доступом. Каждому зарегистрированному в системе пользователю назначается роль r из множества ролей R {admin, tecaher, student}. В JWT, который пользователь получает из сервиса аутентификации, содержится его электронная почта. Когда пользователь отправляет любой запрос для взаимодействия с сервисом дирекции, сервис расшифровывает, валидирует JWT и получает электронную почту пользователя, хранившуюся в нем. Далее возможны две ситуации:
- Пользователь впервые воспользовался сервисом дирекции или в его cookie нет авторизованных данных. В этом случае сервис пытается получить ID и роль пользователя из БД, основываяся на его почте, и в случае успеха зашифровывает их и заносит зашифрованные данные в cookie пользователя. Далее сервис продолжает обрабатывать запрос пользователя, основываясь на его роли и ID. Если запись в БД отсутствует, то пользователь получает HTTP код 403 “Отказано в доступе”.
- Пользователь имеет cookie авторизации. В этом случае cookie расшифровываются и данные, хранящиеся в них извлекаются. Почта, полученная из JWT, и почта, полученная из cookie, сравниваются, и в случае совпадения пользователь проходит дальше и обращается к требуемому ресурсу ИС. Если почты не совпали, то сервис пытается выдать cookie, как в случае №1.
Благодаря такому подходу, сервис дирекции всегда знает ID и роль пользователя, который обращается к ресурсу, и в зависимости от этих данных разрешает или запрещает доступ. Помимо этого, используя данный подход, сокращается количество запросов к БД.