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

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

Проверено вручную: backend Spring Boot, мультитенантность, авторизация, генерация расписания, основные frontend JS-файлы. Автотесты не запущены: в окружении нет `mvn` и `./mvnw`.

## Нужно исправить в первую очередь

### 1. Высокая — JWT имеет небезопасные production-дефолты

**Файлы:**
- `backend/src/main/java/com/magistr/app/config/auth/JwtProperties.java:13-17`
- `backend/src/main/resources/application.properties:18-22`
- `backend/src/main/java/com/magistr/app/controller/AuthController.java:162-168`

**Проблема:** если на проде не задан `JWT_SECRET`, приложение использует известный дефолтный секрет `dev-only-change-this-jwt-secret-32-bytes-minimum`. При этом `JWT_REFRESH_COOKIE_SECURE` по умолчанию `false`, и refresh-cookie может уходить без флага `Secure`.

**Риск:** подделка access-токенов при известном секрете; утечка refresh-cookie при ошибочной HTTP/прокси-конфигурации.

**Как исправить:**
- На production-профиле падать при отсутствии `JWT_SECRET` и при секрете короче требуемой длины.
- Для production сделать `app.jwt.refresh-cookie-secure=true` обязательным.
- Разделить dev/prod профили: дефолтный секрет оставить только в `application-dev.properties`.

---

### 2. Высокая — race condition при ротации refresh-токена

**Файл:** `backend/src/main/java/com/magistr/app/config/auth/RefreshTokenService.java:50-78`

**Проблема:** `rotate()` читает refresh-токен через `findByTokenHash()`, проверяет активность, затем отзывает старый и создаёт новый. Нет блокировки строки или атомарного `UPDATE ... WHERE revoked_at IS NULL`. Два параллельных запроса с одним refresh-токеном могут оба пройти проверку и создать две активные сессии.

**Риск:** повторное использование одного refresh-токена, раздвоение сессий, некорректная ротация `rotatedToTokenHash`.

**Как исправить:**
- Добавить pessimistic lock в репозиторий (`@Lock(PESSIMISTIC_WRITE)` для поиска по `tokenHash`) внутри транзакции.
- Либо сделать атомарное обновление: `UPDATE auth_refresh_tokens SET revoked_at = now, rotated_to_token_hash = :newHash WHERE token_hash = :hash AND revoked_at IS NULL AND expires_at > now` и создавать новый токен только если обновлена 1 строка.
- Добавить тест на два параллельных refresh-запроса.

---

### 3. Высокая — `AuthContext` может протечь между запросами при `403`

**Файл:** `backend/src/main/java/com/magistr/app/config/auth/AuthorizationInterceptor.java:35-49`

**Проблема:** пользователь кладётся в `AuthContext` на строке 45, а при нехватке роли метод возвращает `false` на строке 49. В таком сценарии `afterCompletion()` текущего interceptor'а может не выполниться, и `ThreadLocal` останется в потоке до следующей очистки.

**Риск:** утечка контекста пользователя между запросами в servlet thread pool. Сейчас это в основном риск безопасности и будущих багов, но его лучше устранить сразу.

**Как исправить:** перед каждым `return false` после `AuthContext.setCurrentUser(user)` вызывать `AuthContext.clear()`. Ещё лучше — не устанавливать `AuthContext`, пока не пройдена ролевая проверка, или обернуть обработку отказов в безопасный helper.

---

### 4. Высокая — точечные изменения расписания не проверяются на конфликты

**Файл:** `backend/src/main/java/com/magistr/app/controller/ScheduleOverrideController.java:71-127`

**Проблема:** при `MOVE`/`REPLACE` валидируется только существование нового преподавателя, аудитории и слота. Не проверяется, свободны ли преподаватель/аудитория/группа в выбранную дату и пару.

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

**Как исправить:**
- Перед сохранением override построить расписание на `lessonDate` и проверить занятость нового `timeSlot`, `teacher`, `classroom`, групп/подгрупп базового слота.
- Переиспользовать/вынести конфликтную логику из `ScheduleRuleAdminController` в сервис.
- Вернуть `409 Conflict` с описанием конфликтующего занятия.

---

### 5. Средняя/высокая — расписание преподавателя не показывает пары, где он назначен через override

**Файлы:**
- `backend/src/main/java/com/magistr/app/service/ScheduleQueryService.java:47-58`
- `backend/src/main/java/com/magistr/app/repository/ScheduleRuleRepository.java:36-54`

**Проблема:** если поиск выполняется только по `teacherId`, сервис строит расписание через `buildScheduleForTeacher(teacherId)`, то есть берёт только базовые правила, где преподаватель указан в слоте. Если override заменил преподавателя на этого teacherId, базовое правило в выборку не попадёт, и после `applyOverrides()` такая пара не появится.

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

**Как исправить:**
- При поиске по `teacherId` дополнительно учитывать overrides с `newTeacher.id = teacherId` за период.
- Либо строить расписание по группам для затронутых override-слотов и после применения override фильтровать по преподавателю.
- Добавить тест: базовый преподаватель A, override `newTeacher=B`, поиск по `teacherId=B` должен вернуть пару.

---

### 6. Средняя — обновление существующего тенанта может удалить рабочее подключение и сохранить нерабочее

**Файлы:**
- `backend/src/main/java/com/magistr/app/controller/DatabaseController.java:104-116`
- `backend/src/main/java/com/magistr/app/config/tenant/TenantRoutingDataSource.java:135-148`
- `backend/src/main/java/com/magistr/app/config/tenant/TenantConfigWatcher.java:147-158`

**Проблема:** при добавлении тенанта с уже существующим доменом старый DataSource сначала удаляется и закрывается (`removeTenant()`), затем добавляется новый. Hikari настроен с `setInitializationFailTimeout(-1)`, поэтому невалидная БД может быть добавлена без ошибки. `initDatabaseForTenant()` ловит исключения Flyway и не пробрасывает их наружу, поэтому API может вернуть успех и записать нерабочий конфиг.

**Риск:** админ одной ошибкой в JDBC URL/пароле может выключить рабочий tenant и разнести нерабочую конфигурацию через ConfigMap.

**Как исправить:**
- Сначала создать и проверить новый DataSource во временном объекте (`testConnection`, Flyway migrate) и только после успеха атомарно заменить старый.
- `initDatabaseForTenant()` должен возвращать результат или бросать исключение, чтобы `DatabaseController` не писал невалидный ConfigMap.
- При ошибке оставлять старое подключение активным.

---

### 7. Средняя — watcher не применяет изменения URL/логина/пароля существующего тенанта

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

**Проблема:** `syncTenants()` добавляет только новые домены и удаляет исчезнувшие. Если в `tenants.json` изменились `url`, `username` или `password` для уже существующего `domain`, текущий DataSource не заменяется.

**Риск:** после обновления ConfigMap часть pod'ов продолжит ходить в старую БД/со старыми credentials до рестарта.

**Как исправить:** сравнивать весь `TenantConfig` для существующих доменов. При отличии — безопасно пересоздавать DataSource после успешной проверки нового подключения.

---

### 8. Средняя — отключена проверка TLS-сертификата Kubernetes API

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

**Проблема:** `createInsecureClient()` доверяет любому сертификату (`checkServerTrusted` пустой). Комментарий объясняет это self-signed CA, но в Kubernetes правильный CA доступен в serviceaccount volume.

**Риск:** MITM внутри сети кластера может подменить Kubernetes API и получить serviceaccount token/подменить ConfigMap.

**Как исправить:** использовать CA из `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt` и стандартную проверку hostname/cert chain. Не использовать trust-all клиент.

---

### 9. Средняя — кабинет кафедры может перезаписать дисциплину другой кафедры при импорте

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

**Проблема:** импорт ищет дисциплину только по глобальному имени (`findByName`) и затем без проверки меняет `departmentId` на кафедру текущего пользователя. Если дисциплина с таким названием уже принадлежит другой кафедре, она будет переназначена.

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

**Как исправить:**
- Не менять `departmentId` существующей дисциплины другой кафедры.
- Сделать уникальность по `(department_id, lower(name))`, если одинаковые названия допустимы у разных кафедр.
- При конфликте возвращать понятную ошибку или создавать отдельную запись в рамках кафедры.

---

### 10. Средняя — кафедра может смотреть workload по чужим кафедрам

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

**Проблема:** endpoints `/api/workload/*` доступны роли `DEPARTMENT` и принимают произвольный `departmentId`, но не сверяют его с `AuthContext.departmentId`. Также при `departmentId` отсутствующем запрос строится по всем группам/кафедрам.

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

**Как исправить:** для роли `DEPARTMENT` принудительно использовать `AuthContext.getCurrentUser().departmentId()` и игнорировать/запрещать чужой `departmentId`. Аналогично проверить `ScheduleSearchController`, если расписание не должно быть глобально видимым.

---

### 11. Средняя — семестры можно создать вне учебного года или с пересечениями

**Файлы:**
- `backend/src/main/java/com/magistr/app/controller/AcademicCalendarAdminController.java:95-129,201-211`
- `backend/src/main/java/com/magistr/app/service/AcademicDateService.java:32-34`
- `backend/src/main/java/com/magistr/app/repository/SemesterRepository.java:13`

**Проблема:** при создании/обновлении семестра проверяется только `endDate >= startDate`. Нет проверки, что семестр лежит внутри своего учебного года и не пересекается с другим семестром. При этом расписание ищет `findFirstByStartDateLessThanEqualAndEndDateGreaterThanEqual()`, то есть при пересечении дата будет сопоставляться с произвольным первым семестром.

**Риск:** генерация расписания и чётность недель будут работать некорректно на пересекающихся датах.

**Как исправить:**
- Валидировать границы семестра относительно `AcademicYear.startDate/endDate`.
- Запрещать пересечение семестров в рамках учебного года.
- Желательно добавить DB-level exclusion constraint/range constraint или хотя бы сервисную проверку и тест.

---

### 12. Низкая/средняя — access-токен хранится в `localStorage`

**Файл:** `frontend/admin/js/api.js:5-7,155-163`

**Проблема:** access JWT хранится в `localStorage`, откуда его может украсть любой XSS в админке. Refresh-токен уже вынесен в HttpOnly cookie, но access-токен остаётся доступным JS.

**Риск:** при XSS злоумышленник получает Bearer token и может выполнять API-запросы до истечения TTL.

**Как исправить:**
- По возможности держать access token в памяти и обновлять через HttpOnly refresh cookie.
- Усилить CSP (`script-src` без inline), запретить небезопасные вставки HTML.
- Провести отдельный XSS-аудит всех `innerHTML`.

---

### 13. Низкая — frontend местами вставляет текст ошибки через `innerHTML` без экранирования

**Файл:** `frontend/admin/settings/js/views/database.js:37-49`

**Проблема:** `e.message` вставляется в `innerHTML` без `escapeHtml()`. Сейчас большинство серверных ошибок фиксированные, но часть ошибок может включать текст из внешних систем/драйверов.

**Риск:** потенциальный XSS в настройках БД при попадании HTML в сообщение ошибки.

**Как исправить:** заменить на `textContent` или оборачивать `escapeHtml(e.message)`.

---

### 14. Низкая — backend image скачивает OpenTelemetry javaagent по `latest`

**Файл:** `backend/Dockerfile:7`

**Проблема:** сборка всегда скачивает `latest` javaagent с GitHub без pin версии/checksum.

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

**Как исправить:** закрепить конкретную версию javaagent и проверять checksum.

## Дополнительно проверить после исправлений

1. Добавить Maven Wrapper (`mvnw`), чтобы проверки запускались одинаково в CI и локально.
2. Прогнать `mvn test` и добавить тесты на:
   - параллельную ротацию refresh-токена;
   - override с конфликтом преподавателя/аудитории;
   - расписание преподавателя, назначенного через override;
   - обновление существующего tenant config;
   - запрет чужого `departmentId` для роли `DEPARTMENT`.
3. Не изменять существующие Flyway-миграции. Если нужны DB constraints/indexes — добавлять новую миграцию `V3__...sql`.
