ipam_control/docs/reviews/2026-09-26-changes-011-023-review.md

# Ревью изменений 011–023 (доработки по ревью кодовой базы) — 2026-09-26

**Объём:** незакоммиченные изменения рабочего дерева поверх `cd09ef0`: 19 файлов, +514/−149, миграции `0005`–`0008`, скрипты `find_duplicate_addresses.py` и `find_unusable_addresses.py`, `requirements.lock`.
**Метод:** чтение diff. Подозрительные места проверены на стенде `ipam_control_006` на временных данных, после проверки данные удалены. Все экраны UI открыты в headless Chromium под новым CSP. Выполнены `alembic check` и `pytest`.

Пометки: ✅ — воспроизведено на стенде, 🔎 — вывод по коду.

## Итог

Изменения в целом соответствуют планам и работают. Подтверждено на стенде:
- `alembic check` без расхождений, миграции 0005–0008 применены;
- контейнер работает от `uid=10001` и в статусе `healthy`;
- под CSP все экраны UI открываются без ошибок в консоли, шрифты загружаются;
- перенос префикса в другой VRF каскадно обновляет `addresses.vrf_id`;
- поиск по `%`, отзыв токенов, ограничение попыток входа и границы пагинации работают;
- тесты: 13 из 14 проходят.

**Одна существенная находка:** лимит попыток входа обходится параллельными запросами (№ 1). Ещё одно расхождение между 011 и 015 и несколько мелких замечаний перечислены ниже.

| # | Серьёзность | Изменение | Кратко |
|---|---|---|---|
| 1 | Средняя | 012 | Параллельные запросы обходят лимит входа: 16 одновременных попыток проверили 16 паролей при лимите 5 ✅ |
| 2 | Низкая | 011 × 015 | Перенос адресов в новый вложенный префикс может сделать адрес его адресом сети/broadcast ✅ |
| 3 | Низкая | 023 | `tests/test_users.py` падает: тест ожидает прежнее поведение токенов после смены пароля ✅ |
| 4 | Низкая | 012 | Журнал входов: первые неудачи по новым логинам с «шумного» IP не пишутся; `session.locked` не вытесняется первым при ротации 🔎 |
| 5 | Низкая | 023 | Сброс администратором **своего** пароля через `PATCH /users/{id}` завершает его сессию без выдачи нового токена 🔎 |
| 6 | Низкая (выявлено попутно) | — | `PATCH /devices/{id}` не проверяет `name` и `mac` (принимает `"bad name!"`, `"zz"`) ✅ |
| 7 | Инфо | 023 | Claim `iat` пишется, но не используется; версия пароля считается через `float` 🔎 |

---

## Находки

### 1. Параллельные запросы обходят лимит входа ✅ (012)
В `login` (`app/api/v1/auth.py`) шаги идут в таком порядке:
1. `_retry_after` проверяет блокировку;
2. проверяется пароль (argon2, около 50–100 мс);
3. попытка записывается;
4. блокировка проверяется повторно.

Параллельные запросы проходят первую проверку до того, как любая из них запишет попытку, поэтому пароль проверяется в каждой.
**Воспроизведение:** 16 одновременных запросов с неверным паролем для одного логина. Ответы: 4 × 401 и 12 × 429, но в `login_attempts` 16 записей, то есть проверено 16 паролей. Если бы один из них был верным, запрос вернул бы токен: ветка успеха не смотрит на счётчик. Лимит «5 за 10 минут» фактически превращается в «5 + степень параллелизма».
**Исправление (любое из двух):**
- сериализовать попытки по логину: `SELECT pg_advisory_xact_lock(hashtext(:login))` в начале обработчика, до `_retry_after`;
- или записывать попытку **до** проверки пароля (пессимистично), а при успехе удалять её вместе с остальными. Тогда параллельные запросы видят растущий счётчик.

Первый вариант проще и не меняет семантику журнала.

### 2. Новый вложенный префикс может получить адрес сети или broadcast ✅ (011 × 015)
`rehome_addresses()` переносит адреса родителя в самый узкий префикс, не проверяя правило из 015. То же делает шаг переноса в миграции `0007`.
**Воспроизведение:** в `/24` назначен `198.51.100.128`, затем создан `198.51.100.128/25`. Адрес переехал в дочерний префикс и стал его адресом сети, хотя назначить его туда напрямую нельзя (422).
**Исправление:** в `create_prefix` и при переносе VRF (`_move_to_vrf`) отклонять операцию (422 или 409), если среди адресов, которые перейдут в новый префикс, есть его адрес сети или broadcast, и перечислять такие адреса. `allocate_subnet` это не затрагивает: он уже считает адреса родителя занятыми. В миграции 0007 такие случаи выводить в лог как предупреждение (`find_unusable_addresses.py` их найдёт).

### 3. Устаревший тест токенов ✅ (023)
`tests/test_users.py::test_users_management`, строка 55: `other.get("/auth/me").status_code == 200  # выданный ранее токен продолжает работать`. После 023 ответ 401. Поведение изменено намеренно (отзыв токенов при смене пароля), тест нужно привести к новой семантике:
- старый токен даёт 401;
- токен из ответа `POST /users/me/password` работает.

### 4. Полнота журнала входов 🔎 (012)
- В журнал пишется «первая неудача в окне». Счётчик `before` берётся как максимум по логину и по IP, поэтому если с этого IP уже были неудачи по другим логинам, первая неудача по **новому** логину не попадёт в журнал. При переборе логинов с одного IP в журнале останется одна запись `session.failed` и затем `session.locked` с областью `ip`. Число и список логинов из записей не восстановить.
  **Исправление:** считать `before` отдельно по логину для решения о `session.failed`, а в `diff` записи `session.locked` по IP класть число различных логинов.
- При ротации первыми удаляются только `session.failed`. Записи `session.locked` тоже порождаются анонимными клиентами и вытесняют события данных.
  **Исправление:** добавить `locked` в список удаляемых первыми.

### 5. Сброс своего пароля через PATCH 🔎 (023)
`PATCH /users/{id}` с `password` для собственной учётной записи меняет `password_changed_at` и тем самым отзывает текущий токен администратора, но нового токена в ответе нет. UI такой сценарий не допускает (для своей записи поле пароля скрыто), а клиент API окажется разлогинен.
**Исправление:** для `id == admin.id` отклонять `password` с 422 «Используйте /users/me/password» (проверка текущего пароля там обязательна), либо возвращать новый токен.

### 6. Нет валидации `PATCH /devices/{id}` ✅ (выявлено попутно)
`DeviceUpdate` не проверяет `name` (FQDN) и `mac` (формат, нормализация), хотя `DeviceIn` проверяет. PATCH с `name="bad name!"` и `mac="zz"` возвращает 200. Проблема существовала и до 011–023, но изменение 018 затронуло эту схему.
**Исправление:** переиспользовать валидаторы `DeviceIn._name` и `DeviceIn._mac` в `DeviceUpdate`, пропуская `None`.

### 7. Мелочи 🔎 (023)
- `iat` добавлен в токен, но нигде не проверяется. Отзыв работает по `pv`, поэтому `iat` можно оставить как информационное поле или убрать.
- `_password_version` считает `int(changed.timestamp() * 1_000_000)` через `float`. Результат детерминирован, так как значение в сессии и в БД совпадает до микросекунды, но надёжнее считать целочисленно: `(changed - EPOCH) // timedelta(microseconds=1)`.

---

## Соответствие планам

| Изменение | Статус | Замечания |
|---|---|---|
| 011 уникальность IP в VRF | ✅ с замечанием | № 2; перенос в VRF и каскад `vrf_id` проверены |
| 012 лимит входа | ⚠️ | № 1 (обход параллелизмом), № 4 |
| 013 границы пагинации | ✅ | Вместо общей зависимости используется константа `MAX_OFFSET` (отражено в SUMMARY) |
| 014 экран адресов | ✅ | IPv6 `offset=9·10⁶` отвечает за 0,02 с |
| 015 адрес сети/broadcast | ✅ с замечанием | Обход через перенос адресов (№ 2) |
| 016 роль по умолчанию | ✅ | — |
| 017 проверка секретов | ✅ | — |
| 018 null в PATCH | ✅ | Попутно № 6 |
| 019 N+1 | ✅ частично | «Обзор» не переписан (отражено в SUMMARY) |
| 020 автоназначение адреса | ✅ | Параллельный сценарий не проверялся |
| 021 блокировки | ✅ | Параллельное отключение двух администраторов не проверялось |
| 022 эксплуатация | ✅ | `APP_BIND` по умолчанию `0.0.0.0` (сознательно, отражено в SUMMARY) |
| 023 мелкие улучшения | ✅ с замечаниями | № 3, 5, 7; CSP проверен в браузере |

## Не проверено (для этапа тестов)
- Остановка миграции 0007 на реальном дубле и миграции 0008 на логинах, совпадающих без учёта регистра.
- Снятие блокировки входа через 10 минут; лимит по IP (20 попыток).
- Параллельные сценарии 020 (разные адреса) и 021 (двое администраторов отключают друг друга).
- Одновременный запуск двух `alembic upgrade head`.

## Рекомендуемые действия до коммита
1. Исправить № 1: advisory-lock по логину в `login`.
2. Исправить № 2: проверка адреса сети и broadcast при переносе адресов в новый префикс.
3. Обновить тест из № 3 на этапе тестов.
4. № 4–7 — по желанию, вместе с этапом тестов.