# Отчёт по ошибкам и рискам проекта 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. ## Что покрыть тестами в первую очередь 1. PostgreSQL/Testcontainers + Flyway: чистая БД, upgrade существующей БД, отсутствие активных demo-аккаунтов. 2. Два параллельных refresh-запроса с одним токеном. 3. Цепочка interceptor: 403, затем публичный/защищённый запрос на том же потоке. 4. Override с конфликтом и поиск преподавателя, назначенного через `newTeacher`. 5. Внутренние конфликты одного нового правила, роль преподавателя, нечётные часы и недопустимый формат. 6. `saveGrid` с корректной и ошибочной строкой: после 400 старая сетка должна остаться целой. 7. Изменение tenant URL/credentials, неудачная миграция, параллельные PATCH от двух pod. 8. Более 50 активных групп для workload/free-classrooms. 9. Future-dated перевод преподавателя и исторические отчёты. 10. E2E для `EDUCATION_OFFICE`: календарные графики и настройки форм обучения. 11. Frontend-тест дат в первые дни месяца и в 00:00–03:00 Europe/Moscow. ## Рекомендуемый порядок исправления 1. Ротация/удаление секретов и отключение seed-аккаунтов. 2. Data-loss и security races: calendar grid, refresh rotation, AuthContext. 3. Атомарность tenant-конфигурации и реальные health checks. 4. Конфликты overrides/rules и корректность расписания преподавателя. 5. Согласование ролей, календарных инвариантов и исторической модели кафедр. 6. Производительность генератора, Compose/CI/CD и frontend hardening. Существующие Flyway-миграции не изменять. Все исправления схемы оформлять новой миграцией, начиная с `V3__...sql`.