0016 — Доступ к DEV и защита маршрутов¶

Дата: 2026-08-22.
Статус: Частично заменено; SKUARO Auth и backend permissions действуют, Basic Auth policy заменена решением 0030, имя developer-docs домена заменено решением 0019.
Ответственный: владелец проекта.

Актуальная access policy определена решением 0030: Basic Auth не применяется без нового прямого запроса владельца; SKUARO Auth и backend permissions сохраняются.

Контекст¶

Решение 0006 защищало весь DEV общим Basic Auth. Это безопасно для раннего прототипа, но блокирует принятую открытую самостоятельную регистрацию. Продуктовые страницы должны защищаться сессией и ролевой моделью SKUARO, а не общим серверным паролем.

Решение¶

Публичный Auth-контур DEV¶

После реализации и проверки application guards без Basic Auth доступны:

/;
/register;
/login;
/forgot-password;
/reset-password;
/check-email;
необходимые публичные endpoint в /api/v1/auth/*.

Для неавторизованного посетителя / ведёт на /login. После входа стартовый маршрут выбирается из доступных пользователю модулей, но не обходит права.

Защищённые маршруты¶

/settings требует действующую сессию, подтверждённый email и active User; критическое изменение credentials может требовать повторную аутентификацию.
/today требует сессию, подтверждённый email, active User и Membership, подключённый организации модуль today, доступ membership к модулю и нужное permission.
/admin/* требует сессию, active User и роль super_admin или platform_admin; каждое действие проходит отдельную backend-проверку.
Защищённые API проверяют те же инварианты; frontend guard и скрытие меню не заменяют backend-авторизацию.

Отсутствие сессии возвращает 401; аутентифицированный пользователь без права получает 403. Деактивация пользователя отзывает его активные сессии.

Developer docs и API reference¶

doc-dev.skuaro.top остаётся под Basic Auth и noindex.
Developer API reference переносится в контур doc-dev; сгенерированный OpenAPI остаётся артефактом product-репозитория.
До завершения переноса текущий /api/docs/ на DEV не открывается публично.

Порядок перехода¶

Реализовать frontend route guards и backend authorization для /settings, /today, /admin/* и их API.
Проверить 401, 403, прямые API-запросы, inactive gate, session revoke и tenant/module isolation.
Проверить anti-abuse для публичных Auth endpoint и отсутствие account enumeration.
Только после успеха этих проверок изменить Caddy и снять общий Basic Auth с product DEV.
Сохранить noindex, HSTS, rate limits, security headers и логи без секретов.

До выполнения порядка перехода фактический DEV оставался за общим Basic Auth. Это было временное фактическое состояние, а не целевая модель доступа.

Статус применения¶

Применено в DEV 2026-08-22. Route/API guards, 401/403, inactive/session revoke, neutral recovery response и anti-abuse проверены; общий Basic Auth с product DEV снят, а /api/docs/* оставлен под отдельной защитой. До появления Organization, Membership, module entitlement и permissions доступ обычного пользователя к /today закрыт fail-closed. STAGE не изменён.

Последствия¶

Открытая регистрация и восстановление становятся доступны из интернета и требуют усиленных anti-spam, rate-limit и email-abuse мер.
Корректная UI-защита не заменяет проверку object-level authorization на backend.
STAGE и его текущий Basic Auth этим решением не изменяются.

Откат или замена¶

Возврат к закрытой регистрации, изменение public Auth-маршрутов или снятие backend authorization требует нового security-решения.