Повторный анализ кодовой базы (docs/reviews/2026-09-26-codebase-review-2.md) и доработки:
025 Ёмкость префикса — размер его подсети (а не сумма листьев); «Обзор» считает ёмкость
по корневым активным IPv4-префиксам и адреса внутри них.
026 Политика блокировки входа: 5 неудач на логин+IP, 20 на IP, 50 на логин со всех IP,
кроме известных IP (known_logins, миграция 0009) — владельца нельзя заблокировать анонимно.
027 Сериализация попыток входа по IP (advisory-lock после блокировки логина).
028 UI «Префиксы»: загрузка всех страниц (до 20 000), счётчики по total, предупреждение об усечении.
029 Advisory-lock по VRF для операций, меняющих дерево префиксов и раскладку адресов.
030 Исправление замечаний ревью 025-029: _lock_prefix (VRF блокируется до чтения префикса,
409 при одновременном переносе), константы политики входа перенесены в app/services.py.
Тесты: 14 passed (проверка ёмкости родителя приведена к семантике 025); сквозные сценарии
и гонки — docs/reviews/2026-09-26-changes-025-029-review.md, 2026-09-27-changes-030-review.md.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
3.4 KiB
3.4 KiB
Итог: сериализация попыток входа по IP (изменение 027)
Выполнено вместе с изменением 026 (один файл app/api/v1/auth.py, один проход); детали трёх областей лимита — в SUMMARY 026.
Что сделано
app/api/v1/auth.py,login: после advisory-lock по логину (pg_advisory_xact_lock(LOGIN_LOCK_NS, hashtext(name)), изменение 024) и до_retry_after— вторая блокировка по IP, еслиipизвестен:pg_advisory_xact_lock(IP_LOCK_NS, hashtext(ip)). Порядок всегда «логин, затем IP» — исключает взаимную блокировку.- Использована двухаргументная форма advisory-lock с раздельными пространствами ключей (
LOGIN_LOCK_NS = 7031,IP_LOCK_NS = 7032), чтобыhashtext(логин)иhashtext(ip)гарантированно не пересекались (не зависит от совпадения хэшей, как было бы при одноаргументной форме с общим пространством). - Комментарий в коде — плата за сериализацию: попытки с одного IP (в том числе за NAT) обрабатываются по одной, время ответа при массовом переборе растёт на время проверки argon2.
README.md, абзац «Вход»: добавлено предложение о второй сериализации и её цене.
Отклонения от плана
Нет.
Как проверено
venv/bin/python -c 'import app.main'— без ошибок.- Стенд пересобран и здоров (см. SUMMARY 026 — общая пересборка для 026+027).
- Сценарий из плана: 15 неудачных попыток по IP (докер-шлюз) вставлены напрямую в
login_attempts(порогMAX_PER_IP = 20, то есть до блокировки осталось 5); затем 16 параллельных (черезThreadPoolExecutor, 16 потоков) неверных входов на 16 разных несуществующих логинов с этого же IP:- ответы: 4×401, 12×429;
- новых строк в
login_attemptsдля этого IP (кроме затравки) — 5 (запрос, доведший счётчик до 20, тоже проверяет пароль и добавляет строку, но получает 429, а не 401 — поэтому 401 на один меньше числа добавленных строк, само число строк не превышает лимит). Соответствует условию плана «добавилось ≤ 5 записей». PASS.
login_attemptsочищена после проверки.
Не проверено
- Поведение при коллизии
hashtextмежду конкретным логином и конкретным IP в старой (одноаргументной) схеме — не воспроизводилось намеренно, замена на двухаргументную форму устраняет саму возможность, отдельно не тестировалось.