Zuev/magistr

Fork 0

Files

Zuev ae0dd4c8b3 баг репорт

2026-07-10 22:20:50 +03:00

46 KiB

Raw Permalink Blame History

Отчёт по ошибкам и рискам проекта Magistr

Дата проверки: 2026-07-10

Объём и способ проверки

Проверены:

166 Java-файлов backend, JPA-модели, репозитории, контроллеры, сервисы и конфигурация мультитенантности;
обе Flyway-миграции без изменения существующих файлов;
23 JavaScript-файла, встроенный JavaScript страниц преподавателя/студента, HTML/CSS и SPA-маршрутизация;
compose.yaml, Dockerfile, Gitea Actions;
production-манифесты ../k8s/, которые AGENTS.md относит к внешним зависимостям проекта;
проектная документация и существующий граф связей graphify-out/graph.json.

Выполненные проверки:

mvn test в Maven-контейнере: 30 тестов, 0 failures, 0 errors, BUILD SUCCESS;
node --check для всех внешних JS-файлов и извлечённых inline-скриптов: ошибок синтаксиса нет;
docker compose config --quiet: Compose синтаксически корректен;
kubectl kustomize ../k8s: Kustomize-манифесты собираются;
сопоставление JPA-таблиц с Flyway DDL: отсутствующих таблиц для сущностей не найдено;
git diff --check: проблем с пробелами и маркерами конфликтов нет.

Ограничения проверки: не выполнялись E2E-тесты в браузере, нагрузочное тестирование, тестирование с реальным PostgreSQL и одновременной работой двух backend-pod. Конкурентные дефекты ниже подтверждены по коду и воспроизводимому сценарию, но не запускались против production-кластера.

Сводка

Приоритет	Количество
Критический	2
Высокий	10
Средний	19
Низкий	3
Всего	34

Критические проблемы

1. Production-манифесты содержат известные JWT/DB-секреты и хранят пароли в ConfigMap

Файлы:

backend/src/main/resources/application.properties:18-22
backend/src/main/java/com/magistr/app/config/auth/JwtProperties.java:13-17
../k8s/config.yaml:15-26
../k8s/backend.yaml:1-23
../k8s/otel-collector.yaml:1-25

Проблема: приложение имеет известный JWT-секрет по умолчанию и небезопасный дефолт refresh-cookie-secure=false. Production-манифест config.yaml передаёт другой, но также заранее известный placeholder-секрет, который удовлетворяет проверке длины. Пароли PostgreSQL записаны открытым текстом в Secret.stringData, tenant ConfigMap и ConfigMap коллектора OpenTelemetry. Kubernetes Secret в YAML не шифрует значение в исходном файле, а ConfigMap вообще не предназначен для секретов.

Риск: подделка access JWT, компрометация всех tenant-БД и метрик, повторное использование опубликованных credentials. Если эти значения когда-либо применялись, их нужно считать скомпрометированными.

Как исправить:

Немедленно ротировать JWT- и DB-секреты во всех окружениях.
Удалить реальные/фиксированные значения из файлов и истории репозиториев.
Использовать External Secrets, SOPS/Sealed Secrets или секреты CI/CD; tenant credentials и credentials OTel хранить в Secret, а не ConfigMap.
На production-профиле завершать запуск при пустом, дефолтном или известном placeholder JWT_SECRET и при JWT_REFRESH_COOKIE_SECURE != true.

2. Flyway создаёт во всех новых tenant-БД предсказуемые учётные записи и демонстрационные данные

Файлы:

backend/src/main/resources/db/migration/V1__init.sql:21-24,38-42,85-92,221-265
docs/README.md:45-54

Проблема: V1 создаёт администратора с публично документированным коротким паролем, а также несколько тестовых пользователей с одинаковым известным паролем. Эта же миграция запускается для tenant-БД, добавленных в production, и одновременно добавляет демонстрационные кафедры, группы и другие данные.

Риск: немедленный административный доступ к свежему tenant, если пароль не сменили вручную; загрязнение production-БД тестовыми сущностями.

Как исправить:

Не менять V1. Добавить новую миграцию V3__disable_demo_accounts.sql, которая архивирует/удаляет демонстрационные аккаунты и данные там, где они не были явно сохранены.
Создавать первого администратора отдельной bootstrap-процедурой с одноразовым случайным секретом.
Разнести demo/dev seed и обязательную production-схему.
Ротировать пароли уже созданных tenant-БД.

Высокий приоритет

3. Race condition при ротации refresh-токена

Файлы:

backend/src/main/java/com/magistr/app/config/auth/RefreshTokenService.java:50-91
backend/src/main/java/com/magistr/app/repository/AuthRefreshTokenRepository.java:10

Проблема: rotate() читает токен, проверяет его активность, а затем отзывает старый и создаёт новый без блокировки строки или условного атомарного UPDATE. Два параллельных запроса с одним cookie могут оба пройти проверку и создать две новые сессии.

Риск: повторное использование refresh-токена, раздвоение цепочки ротации и обход ожидаемой семантики single-use.

Как исправить: использовать PESSIMISTIC_WRITE либо атомарный UPDATE ... WHERE revoked_at IS NULL AND expires_at > now() и создавать следующий токен только при обновлении одной строки. Добавить конкурентный интеграционный тест с PostgreSQL.

4. `AuthContext` остаётся в servlet-потоке после отказа по роли

Файл: backend/src/main/java/com/magistr/app/config/auth/AuthorizationInterceptor.java:45-49,65-68

Проблема: пользователь записывается в ThreadLocal до проверки @RequireRoles. Если interceptor возвращает false, его собственный afterCompletion() не вызывается, поэтому контекст не очищается.

Риск: следующий запрос на том же потоке может увидеть данные предыдущего пользователя, особенно если он проходит через публичный auth endpoint или останавливается в более раннем interceptor.

Как исправить: очищать контекст в начале preHandle() и перед каждым return false; ещё лучше — устанавливать пользователя только после успешной проверки роли. Добавить MockMvc-тест последовательных запросов на одном executor-потоке.

5. Точечные изменения расписания создаются без проверки конфликтов и факта существования пары

Файлы:

backend/src/main/java/com/magistr/app/controller/ScheduleOverrideController.java:71-126
backend/src/main/java/com/magistr/app/service/ScheduleQueryService.java:67-141

Проблема: для MOVE/REPLACE проверяется только существование сущностей. Не проверяется занятость преподавателя, аудитории и групп в новой паре. Также можно сохранить override на дату, когда базовый слот вообще не генерируется, либо сохранить фактически пустой REPLACE.

Риск: двойное назначение ресурсов; накопление неработающих изменений, которые API считает успешными.

Как исправить: перед сохранением построить исходную пару на указанную дату, проверить action-specific поля и пересечения уже применённого расписания. При конфликте возвращать 409 Conflict.

6. Расписание преподавателя не показывает пары, назначенные ему через override

Файлы:

backend/src/main/java/com/magistr/app/service/ScheduleQueryService.java:47-63
backend/src/main/java/com/magistr/app/repository/ScheduleRuleRepository.java:36-58
backend/src/main/java/com/magistr/app/repository/ScheduleOverrideRepository.java:14-26

Проблема: запрос только по teacherId сначала выбирает базовые правила этого преподавателя. Если override заменяет преподавателя A на B, правило A не попадает в исходную выборку B, поэтому последующее applyOverrides() уже не может добавить пару.

Риск: преподаватель B не видит назначенную ему замену.

Как исправить: учитывать overrides с newTeacher.id = teacherId за период и достраивать соответствующие базовые пары до финальной фильтрации.

7. Валидатор правил расписания пропускает несколько нарушений инвариантов

Файлы:

backend/src/main/java/com/magistr/app/controller/ScheduleRuleAdminController.java:220-228,440-481,524-565
backend/src/main/java/com/magistr/app/service/ScheduleGeneratorService.java:252-293
backend/src/main/resources/db/migration/V1__init.sql:707-726

Проблемы:

конфликт ищется только с уже сохранёнными правилами; два конфликтующих/дублирующих слота внутри одного нового правила не сравниваются между собой;
пользователь слота проверяется на архивность, но не на роль TEACHER;
lessonFormat проверяется только на непустоту, хотя DB допускает лишь «Очно»/«Онлайн»;
нечётное число академических часов принимается, хотя генератор списывает по два часа и может выдать больше часов, чем задано.

Риск: дубли в один момент времени, назначение студента/администратора преподавателем, HTTP 500 на DB CHECK и неверный расход часов.

Как исправить: валидировать пары новых слотов между собой, роль пользователя, enum формата и кратность часов двум; продублировать ключевые ограничения новой Flyway-миграцией там, где это возможно.

8. Ошибка в строке календарной сетки возвращает 400, но удаляет старую сетку и коммитит часть новой

Файл: backend/src/main/java/com/magistr/app/controller/AcademicCalendarController.java:125-146

Проблема: saveGrid() работает в транзакции, сначала удаляет всю старую сетку, затем валидирует и сохраняет строки по одной. IllegalArgumentException ловится внутри transactional-метода и не выходит за границу proxy, поэтому транзакция считается успешной.

Воспроизведение: передать список, где первая строка корректна, а вторая содержит неверный день/дату. API вернёт 400, но старая сетка будет удалена, а первая новая строка сохранится.

Риск: тихая потеря календарного учебного графика при ошибке пользователя.

Как исправить: сначала провалидировать весь список и уникальность ключей, затем одним шагом заменять данные; либо не перехватывать исключение внутри транзакции/помечать транзакцию rollback-only.

9. Обновление tenant может удалить рабочее подключение и успешно сохранить нерабочее

Файлы:

backend/src/main/java/com/magistr/app/controller/DatabaseController.java:104-124,175-182
backend/src/main/java/com/magistr/app/config/tenant/TenantRoutingDataSource.java:135-148
backend/src/main/java/com/magistr/app/config/tenant/TenantConfigWatcher.java:133-160

Проблема: существующий DataSource сначала удаляется и закрывается. Новый Hikari pool создаётся с initializationFailTimeout=-1. Ошибка Flyway проглатывается, а результат записи ConfigMap игнорируется. API способен вернуть успех после неудачной миграции или неудачной персистенции.

Риск: одна опечатка в URL/пароле отключает рабочий tenant; разные pod получают разную конфигурацию.

Как исправить: создать временный pool, проверить соединение и миграции, затем атомарно заменить старый. Ошибки миграции и ConfigMap должны прерывать операцию; нужен compensating rollback.

10. Два backend-pod могут потерять изменения tenant-конфигурации, а probes не видят отказ БД

Файлы:

../k8s/backend.yaml:31,86-97
backend/src/main/java/com/magistr/app/controller/DatabaseController.java:177-182
backend/src/main/java/com/magistr/app/config/tenant/ConfigMapUpdater.java:62-92

Проблема: deployment имеет две реплики. Каждая PATCH-операция перезаписывает весь tenants.json из локальной in-memory карты без resourceVersion/compare-and-swap. Параллельное добавление A на pod-1 и B на pod-2 приводит к last-write-wins и потере A или B. TCP readiness/liveness считает pod здоровым, даже если все tenant-БД недоступны и Flyway завершился ошибкой.

Риск: потерянные конфигурационные изменения и маршрутизация трафика на фактически неработающий pod.

Как исправить: вынести операции в единый coordinator/CRD/БД либо применять optimistic locking к ConfigMap с повтором; добавить health endpoint, проверяющий миграции и доступность обязательных tenant.

11. Дашборд может показать зелёное «конфликтов нет», когда проверка фактически не выполнена

Файл: frontend/admin/js/views/dashboard.js:148-168,274-287

Проблемы:

диапазон недели вычисляется двойным мутированием одного Date; в первые дни месяца конец диапазона попадает в начало предыдущего месяца и оказывается раньше начала;
каждый запрос кафедры имеет catch(() => []), поэтому сетевые/серверные ошибки превращаются в пустое расписание;
после этого пустой результат отображается как «Конфликты расписания не обнаружены».

Проверенный пример: для 2026-07-02 код строит диапазон примерно 2026-06-29 … 2026-06-05 вместо 2026-06-29 … 2026-07-05.

Риск: ложное подтверждение безопасности расписания именно в панели контроля.

Как исправить: вычислять воскресенье как monday + 6 дней на отдельном объекте, форматировать локальную дату без UTC и различать состояния «нет конфликтов»/«проверка частично или полностью не выполнена».

12. Access JWT и удалённый JavaScript выполняются в одном origin

Файлы:

frontend/admin/js/api.js:5-7,155-163
frontend/script.js:5-28
frontend/admin/js/otel.js:1-8

Проблема: JWT хранится в localStorage. Страница входа динамически исполняет неприкреплённые по версии модули с esm.sh, а admin — удалённые модули без SRI. Такой код имеет доступ к DOM, введённому паролю и localStorage.

Риск: компрометация CDN/пакета или XSS сразу даёт учётные данные и Bearer-токен.

Как исправить: собирать и раздавать telemetry dependencies локально с lockfile; держать access token в памяти или перейти на защищённую cookie-сессию; добавить строгий CSP и убрать inline-скрипты.

Средний приоритет

13. Watcher не применяет изменения существующего tenant и не повторяет неудачную синхронизацию

Файл: backend/src/main/java/com/magistr/app/config/tenant/TenantConfigWatcher.java:60-71,102-125

Проблема: сравниваются только множества доменов — смена URL, логина или пароля существующего домена игнорируется. Кроме того, новый hash записывается до JSON parsing/sync; если синхронизация падает, следующий poll считает файл уже обработанным и не повторяет операцию.

Риск: pod продолжает использовать старые credentials либо навсегда остаётся в частично синхронизированном состоянии до следующего изменения файла/рестарта.

Как исправить: сравнивать весь нормализованный TenantConfig, записывать hash только после полного успеха и сохранять retry/backoff-состояние.

14. Полностью отключена проверка TLS Kubernetes API

Файл: backend/src/main/java/com/magistr/app/config/tenant/ConfigMapUpdater.java:74-76,104-119

Проблема: trust manager принимает любой сертификат. Kubernetes CA уже доступен в serviceaccount volume.

Риск: MITM к API server, утечка serviceaccount token и подмена tenant ConfigMap.

Как исправить: загружать /var/run/secrets/kubernetes.io/serviceaccount/ca.crt, использовать стандартную проверку цепочки и hostname.

15. Редактор временных слотов позволяет создать пересекающиеся интервалы и сломать базовые правила

Файлы:

backend/src/main/java/com/magistr/app/controller/TimeSlotAdminController.java:152-224
backend/src/main/java/com/magistr/app/service/ScheduleGeneratorService.java:418-435

Проблемы:

проверяется только уникальность номера пары, но не пересечение временных интервалов внутри сетки;
update разрешает перенести существующий базовый слот в MANUAL scope, хотя правила обязаны ссылаться на DEFAULT;
durationMinutes может не соответствовать разнице startTime/endTime.

Риск: два занятия реально идут одновременно, но конфликтный анализ считает их разными слотами; существующие правила исчезают из ожидаемой базовой сетки.

Как исправить: запретить пересечение интервалов, фиксировать scope используемого базового слота и вычислять duration на backend.

16. Учебные годы и семестры допускают пересечения и выход семестра за границы года

Файлы:

backend/src/main/java/com/magistr/app/controller/AcademicCalendarAdminController.java:46-129,188-237
backend/src/main/java/com/magistr/app/service/AcademicDateService.java:32-34
backend/src/main/java/com/magistr/app/repository/SemesterRepository.java:13-17

Проблема: проверяется только порядок двух дат. Можно пересечь учебные годы, пересечь осенний и весенний семестры, вынести семестр за границы года. При update также не проверяется дубликат title/type до DB constraint.

Риск: findFirst... выбирает произвольный семестр для даты; номер недели и чётность становятся недетерминированными, а часть update-запросов заканчивается HTTP 500.

Как исправить: централизовать календарную валидацию, запретить пересечения и добавить DB-level exclusion/range constraints новой миграцией.

17. Изменение календаря или группы нарушает уже сохранённые назначения

Файлы:

backend/src/main/java/com/magistr/app/controller/AcademicCalendarController.java:85-98,178-214
backend/src/main/java/com/magistr/app/controller/GroupController.java:173-212,322-359

Проблема: после назначения графика группе можно изменить у графика учебный год, специальность, профиль, форму или количество курсов; можно также изменить эти поля у группы. Существующее student_group_calendar_assignments не перепроверяется и не удаляется. При уменьшении courseCount остаются строки сетки старших курсов.

Риск: расписание строится по графику, который больше не соответствует группе/году, хотя API проверял соответствие при первоначальном назначении.

Как исправить: запрещать изменение ключевых измерений у используемого графика либо транзакционно перевалидировать назначения, grid и subjects.

18. Историческая модель кафедр преподавателя используется непоследовательно

Файлы:

backend/src/main/java/com/magistr/app/controller/UserController.java:218-259,310-324
backend/src/main/java/com/magistr/app/controller/WorkloadController.java:51-60,85-100
backend/src/main/java/com/magistr/app/controller/TeacherSubjectController.java:102-115

Проблемы:

будущий перевод немедленно меняет users.department_id, и преподаватель до validFrom появляется одновременно в старой и новой кафедре;
исторический список фильтрует User::isActiveRecord, поэтому архивный преподаватель исчезает даже для даты, когда он работал;
workload прошлых периодов относится к текущему users.department_id;
дополнительная активная кафедральная связь учитывается в списке преподавателей, но TeacherSubjectController разрешает связь только по legacy users.department_id.

Риск: неверные исторические отчёты и неработоспособность дополнительного назначения преподавателя.

Как исправить: считать кафедру через teacher_department_assignments на дату; legacy-поле обновлять только в дату вступления перевода в силу либо не использовать для бизнес-решений.

19. Роль `DEPARTMENT` может запрашивать workload чужой кафедры

Файл: backend/src/main/java/com/magistr/app/controller/WorkloadController.java:43-135

Проблема: endpoints принимают произвольный departmentId или отсутствие фильтра и не сопоставляют его с AuthContext.departmentId.

Риск: межкафедральное раскрытие отчётов и обход ограничений, которые уже применяются в DepartmentWorkspaceController и части UserController.

Как исправить: для DEPARTMENT принудительно использовать кафедру из токена; явно документировать endpoints, где глобальный просмотр действительно разрешён.

20. Глобальные workload/free-classrooms ломаются при количестве активных групп больше 50

Файлы:

backend/src/main/java/com/magistr/app/controller/WorkloadController.java:43-135
backend/src/main/java/com/magistr/app/service/ScheduleQueryService.java:160-180

Проблема: агрегирующие endpoints переиспользуют общий поиск с ограничением 50 групп. free-classrooms вообще не принимает scope, поэтому в крупном tenant неизбежно получает IllegalArgumentException вместо списка свободных аудиторий.

Риск: штатная функция перестаёт работать при росте университета.

Как исправить: сделать специализированные агрегирующие запросы/батч-генерацию, а не использовать ограничение интерактивного широкого поиска.

21. Импорт кафедры может переназначить дисциплину другой кафедры

Файл: backend/src/main/java/com/magistr/app/controller/DepartmentWorkspaceController.java:80-90

Проблема: дисциплина ищется по глобальному имени, после чего departmentId безусловно меняется на текущую кафедру.

Риск: потеря принадлежности и изменение расписаний/календарей другой кафедры.

Как исправить: не менять чужую запись; решить бизнес-правило уникальности и при необходимости перейти на (department_id, lower(name)) новой миграцией.

22. Права frontend и backend расходятся для учебного отдела

Файлы:

backend/src/main/java/com/magistr/app/controller/SpecialityController.java:23-24,38-58,196-213
backend/src/main/java/com/magistr/app/controller/EducationFormController.java:17-18,33-59
frontend/admin/js/views/academic-calendar.js:106-118,207-218
frontend/admin/settings/js/main.js:47-52

Проблемы:

EDUCATION_OFFICE видит вкладку календарных графиков, но её обязательные GET /api/specialties и profiles разрешены только ADMIN; инициализация попадает в 403;
settings показывает учебному отделу CRUD форм обучения, но POST/DELETE backend разрешены только ADMIN.

Риск: видимые штатные экраны частично или полностью не работают.

Как исправить: согласовать role matrix в одном источнике; либо расширить read/write права, либо скрыть недоступные действия.

23. Генерация расписания имеет выраженный N+1 по дням, правилам и группам

Файлы:

backend/src/main/java/com/magistr/app/service/ScheduleGeneratorService.java:64-90,107-124,187-229,297-308
backend/src/main/java/com/magistr/app/service/AcademicDateService.java:58-87

Проблема: семестр повторно ищется внутри каждого правила, а isTheoryDay() для каждой группы и даты выполняет отдельные запросы assignment + calendar day. В teacher mode это повторяется по всем группам правила.

Риск: диапазон 120 дней и десятки групп порождают тысячи/десятки тысяч SQL-запросов, таймауты и нагрузку на каждую tenant-БД.

Как исправить: заранее батчем загружать semesters, assignments и calendar days за диапазон; передавать уже найденный semester в processRuleForDate(). Добавить метрики query count и нагрузочный тест.

24. Истёкшие и отозванные refresh-токены никогда не удаляются

Файлы:

backend/src/main/java/com/magistr/app/config/auth/RefreshTokenService.java:34-107
backend/src/main/java/com/magistr/app/repository/AuthRefreshTokenRepository.java:8-11

Проблема: каждый login/refresh добавляет строку, ротация лишь ставит revoked_at. Cleanup job/repository delete отсутствует.

Риск: неограниченный рост auth_refresh_tokens и индексов.

Как исправить: периодически удалять давно истёкшие/отозванные строки с разумным audit retention; покрыть job тестом.

25. DB constraint violations превращаются в 500 и иногда раскрывают текст драйвера

Файлы:

backend/src/main/java/com/magistr/app/controller/GlobalExceptionHandler.java:23-55
backend/src/main/java/com/magistr/app/controller/GroupController.java:166-169,216-219
backend/src/main/java/com/magistr/app/controller/SubjectController.java:122-125
backend/src/main/java/com/magistr/app/controller/DatabaseController.java:121-124,166-171

Проблема: нет общего обработчика DataIntegrityViolationException/constraint name. Часть контроллеров ловит общий Exception и возвращает клиенту e.getMessage().

Риск: неправильный HTTP status, английские/технические сообщения в UI и раскрытие деталей схемы/JDBC.

Как исправить: добавить единый перевод constraint → 409/400 с русским сообщением; не отдавать внутренний exception text.

26. Чистый локальный запуск по документации не публикует приложение и имеет противоречивую конфигурацию БД

Файлы:

compose.yaml:1-43
backend/src/main/resources/application.properties:3-6,18-22
docs/README.md:33-43
docs/INFRASTRUCTURE.md:3-37

Проблемы:

frontend/backend не имеют ports, а Caddy не входит в Compose, поэтому на чистой машине localhost:80 после указанной команды недоступен;
POSTGRES_DB может изменить создаваемую DB, но backend URL жёстко указывает app_db;
JWT-переменные из .env не передаются контейнеру backend;
для PostgreSQL не объявлен именованный volume, поэтому после down/recreate данные могут остаться в потерянном anonymous volume.

Как исправить: добавить локальный reverse proxy/ports, передавать согласованный JDBC URL и JWT env, объявить named volume и обновить quick start.

27. CI/CD разворачивает код без запуска тестов, а tag pipeline перезапускает `:main`

Файлы:

.gitea/workflows/docker-build.yaml:3-8,35-40,63-68,73-96
backend/Dockerfile:1-6
../k8s/backend.yaml:45-46
../k8s/frontend.yaml:20-21

Проблема: workflow не имеет test job, а Dockerfile выполняет mvn package -DskipTests. На событии tag metadata публикует tag-образ, но deployment продолжает ссылаться на mutable :main и просто перезапускается.

Риск: production получает непроверенный commit; release-tag может перезапустить старый main-образ вместо релиза.

Как исправить: обязательные test/compile/static-check jobs до push/deploy; деплой image digest или конкретного release tag; concurrency lock и rollback при failed rollout.

28. Нет ограничения попыток входа

Файлы:

backend/src/main/java/com/magistr/app/controller/AuthController.java:57-86
../k8s/ingress.yaml:1-45

Проблема: login не имеет rate limit, задержки, lockout или CAPTCHA; в Ingress также нет соответствующего middleware/аннотации.

Риск: online brute force и password spraying, особенно опасные вместе с известными seed-аккаунтами.

Как исправить: rate limit по tenant+IP+username, прогрессивная задержка и аудит неудачных входов без логирования пароля.

29. Часовой пояс backend не зафиксирован, а часть frontend дат строится через UTC

Файлы:

backend/src/main/java/com/magistr/app/model/LifecycleEntity.java:94-98
backend/src/main/java/com/magistr/app/controller/UserController.java:85,164,235,271
backend/src/main/java/com/magistr/app/service/ScheduleGeneratorService.java:236
frontend/admin/js/views/dashboard.js:48,159-160
frontend/admin/js/views/department-workspace.js:494-504
compose.yaml и ../k8s/backend.yaml

Проблема: бизнес-даты используют LocalDate.now()/LocalDateTime.now() с timezone JVM, но контейнеры не получают TZ/user.timezone. Frontend использует toISOString(), поэтому в Москве до 03:00 получает предыдущую календарную дату.

Риск: архивирование, перевод, доступность ресурсов и «сегодняшнее расписание» сдвигаются на день/несколько часов в зависимости от окружения.

Как исправить: внедрить Clock и явный ZoneId для бизнес-даты, хранить абсолютные timestamps как UTC/Instant, форматировать date-only локальными компонентами.

30. Сборки и deployment используют mutable/непроверяемые артефакты

Файлы:

backend/Dockerfile:7
../k8s/otel-collector.yaml:59
../k8s/backend.yaml:45-46
../k8s/frontend.yaml:20-21
.gitea/workflows/docker-build.yaml:83-87

Проблема: javaagent и kubectl скачиваются как latest/stable без checksum, collector использует latest, приложения — mutable main.

Риск: невоспроизводимые сборки, неожиданные несовместимости и supply-chain подмена.

Как исправить: pin версии и image digest, проверять SHA256/signature, генерировать SBOM и сканировать образы.

31. Группы допускают некорректную численность и ломают существующее деление на подгруппы

Файлы:

backend/src/main/java/com/magistr/app/controller/GroupController.java:173-212,250-272
backend/src/main/java/com/magistr/app/controller/SubgroupController.java:151-175
backend/src/main/resources/db/migration/V1__init.sql:203-219

Проблема: groupSize проверяется только на null, yearStartStudy — только на ноль; DB не имеет CHECK для положительной численности. При update можно уменьшить группу ниже суммы активных подгрупп, хотя SubgroupController такой результат запрещает при редактировании подгрупп.

Риск: отрицательная/нулевая численность, неверный расчёт вместимости и внутренне противоречивые подгруппы.

Как исправить: единый валидатор create/update, проверка суммы подгрупп и новая миграция с CHECK constraints.

Низкий приоритет

32. Лимит «120 дней» фактически разрешает 121 дату

Файлы:

backend/src/main/java/com/magistr/app/service/ScheduleQueryService.java:148-157
backend/src/main/java/com/magistr/app/service/ScheduleGeneratorService.java:135-144

Проблема: проверяется DAYS.between(start, end) > 120, но обе границы включены. Разница 120 означает 121 календарную дату.

Как исправить: проверять включительную длину (between + 1) либо изменить текст/документацию.

33. Остались XSS-точки в сообщениях ошибок и видимые поля пароля

Файлы:

frontend/admin/settings/js/views/database.js:39,49
frontend/admin/js/main.js:260-262
frontend/admin/settings/js/main.js:130-133
frontend/admin/views/users.html:11-12
frontend/admin/js/views/teacher-requests.js:47-51

Проблема: несколько e.message вставляются через innerHTML без экранирования. Поля пароля при создании пользователя/одобрении заявки имеют type="text".

Риск: потенциальный DOM XSS при попадании управляемого текста ошибки; пароль виден на экране и может сохраняться как обычный текст формы.

Как исправить: использовать textContent/escapeHtml, а для паролей — type="password" и корректные autocomplete.

34. Проектный языковой регламент нарушен в UI и логах

Файлы:

backend/src/main/java/com/magistr/app/config/tenant/TenantRoutingDataSource.java:65,78,95
backend/src/main/java/com/magistr/app/config/tenant/TenantDataSourceConfig.java:60,123
frontend/admin/settings/js/views/database.js:14-16,60-62
frontend/admin/js/otel.js:47

Проблема: присутствуют английские production-логи и UI-метки Online/Offline; JDBC exception также может попасть в UI на английском.

Как исправить: привести пользовательские сообщения и проектные логи к русскому языку; технические идентификаторы оставлять в structured fields.

Что покрыть тестами в первую очередь

PostgreSQL/Testcontainers + Flyway: чистая БД, upgrade существующей БД, отсутствие активных demo-аккаунтов.
Два параллельных refresh-запроса с одним токеном.
Цепочка interceptor: 403, затем публичный/защищённый запрос на том же потоке.
Override с конфликтом и поиск преподавателя, назначенного через newTeacher.
Внутренние конфликты одного нового правила, роль преподавателя, нечётные часы и недопустимый формат.
saveGrid с корректной и ошибочной строкой: после 400 старая сетка должна остаться целой.
Изменение tenant URL/credentials, неудачная миграция, параллельные PATCH от двух pod.
Более 50 активных групп для workload/free-classrooms.
Future-dated перевод преподавателя и исторические отчёты.
E2E для EDUCATION_OFFICE: календарные графики и настройки форм обучения.
Frontend-тест дат в первые дни месяца и в 00:00–03:00 Europe/Moscow.

46 KiB Raw Permalink Blame History Unescape Escape

Отчёт по ошибкам и рискам проекта Magistr

Объём и способ проверки

Сводка

Критические проблемы

1. Production-манифесты содержат известные JWT/DB-секреты и хранят пароли в ConfigMap

2. Flyway создаёт во всех новых tenant-БД предсказуемые учётные записи и демонстрационные данные

Высокий приоритет

3. Race condition при ротации refresh-токена

4. AuthContext остаётся в servlet-потоке после отказа по роли

5. Точечные изменения расписания создаются без проверки конфликтов и факта существования пары

6. Расписание преподавателя не показывает пары, назначенные ему через override

7. Валидатор правил расписания пропускает несколько нарушений инвариантов

8. Ошибка в строке календарной сетки возвращает 400, но удаляет старую сетку и коммитит часть новой

9. Обновление tenant может удалить рабочее подключение и успешно сохранить нерабочее

10. Два backend-pod могут потерять изменения tenant-конфигурации, а probes не видят отказ БД

11. Дашборд может показать зелёное «конфликтов нет», когда проверка фактически не выполнена

12. Access JWT и удалённый JavaScript выполняются в одном origin

Средний приоритет

13. Watcher не применяет изменения существующего tenant и не повторяет неудачную синхронизацию

14. Полностью отключена проверка TLS Kubernetes API

15. Редактор временных слотов позволяет создать пересекающиеся интервалы и сломать базовые правила

16. Учебные годы и семестры допускают пересечения и выход семестра за границы года

17. Изменение календаря или группы нарушает уже сохранённые назначения

18. Историческая модель кафедр преподавателя используется непоследовательно

19. Роль DEPARTMENT может запрашивать workload чужой кафедры

20. Глобальные workload/free-classrooms ломаются при количестве активных групп больше 50

21. Импорт кафедры может переназначить дисциплину другой кафедры

22. Права frontend и backend расходятся для учебного отдела

23. Генерация расписания имеет выраженный N+1 по дням, правилам и группам

24. Истёкшие и отозванные refresh-токены никогда не удаляются

25. DB constraint violations превращаются в 500 и иногда раскрывают текст драйвера

26. Чистый локальный запуск по документации не публикует приложение и имеет противоречивую конфигурацию БД

27. CI/CD разворачивает код без запуска тестов, а tag pipeline перезапускает :main

28. Нет ограничения попыток входа

29. Часовой пояс backend не зафиксирован, а часть frontend дат строится через UTC

30. Сборки и deployment используют mutable/непроверяемые артефакты

31. Группы допускают некорректную численность и ломают существующее деление на подгруппы

Низкий приоритет

32. Лимит «120 дней» фактически разрешает 121 дату

33. Остались XSS-точки в сообщениях ошибок и видимые поля пароля

34. Проектный языковой регламент нарушен в UI и логах

Что покрыть тестами в первую очередь

Рекомендуемый порядок исправления

46 KiB

Raw Permalink Blame History

4. `AuthContext` остаётся в servlet-потоке после отказа по роли

19. Роль `DEPARTMENT` может запрашивать workload чужой кафедры

27. CI/CD разворачивает код без запуска тестов, а tag pipeline перезапускает `:main`