Регрессионный тест прав API для pull request в GitHub Actions
Регрессионный тест должен упасть, если убрать проверку владельца, и остаться зелёным, когда оба пользователя могут читать только свои записи. Проверьте сам тест на намеренно уязвимом варианте: это отличает защиту от всегда проходящего сценария.
Что подготовить
Сохраните authorization-contract.py и access-fixture.py рядом в каталоге ci/, скачайте workflow в .github/workflows/. Пример использует стандартную библиотеку Python и временный порт на loopback, без внешнего сервиса и токенов.
Порядок проверки
Сравните два варианта локально
В фиксированном режиме тест проверяет обе пары «владелец → свой документ» и оба перекрёстных запроса. В уязвимом режиме первый чужой маркер завершает тест с кодом 1. Ошибка загрузки стенда или неожиданное поведение дают код 2.
Перенесите контракт на собственное приложение
В job поднимите своё тестовое приложение, создайте две сессии штатным способом и замените адаптер чтения. Ожидаемый отказ должен соответствовать вашему API: например, согласованный 404 вместо 403. Не ослабляйте проверку содержимого.
Выполните из корня репозитория с файлами в ci/
python3 ci/authorization-contract.py --mode fixed
python3 ci/authorization-contract.py --mode vulnerableКритерий результата и ограничения
Приложенный workflow проверяет именно код 1 для сломанного режима. Отсутствующий файл или упавший сервер не должны считаться успешно обнаруженной регрессией.
Что остаётся непроверенным
Пока тест вызывает только учебный сервер, зелёная job ничего не говорит о вашем продукте. После адаптации разделите тесты чтения, записи и экспорта.