Права доступа

Замер: 2026-08-14 · чем проверено: модель доступа, договор гостевых ключей, php vendor/phpunit/phpunit/phpunit tests/Feature/BusinessAccessTest.php, python3 -m pytest data_api/tests/test_rate_limit_guest.py -q -rs Читать перед тем, как выдавать доступ, добавлять роль или решать, кому что видно.

Какой цели служит

Внутренние действия ограничены ролью и площадкой, а внешнее чтение вынесено в отдельный канал, который не даёт гостю права управлять системой.

Для чего это нужно

Права решаются на трёх уровнях, потому что у данных три разные границы: что человек может делать (отчёты, финансы, операции), с какими площадками (менеджер Wildberries не видит Ozon), и можно ли видеть общие страницы, где площадки сведены вместе. Последнее — отдельное право, потому что сводить площадки в общее число вообще-то нельзя: правило неслияния.

У super_admin в таблицах может быть назначено меньшинство отдельных прав, и это устройство, а не дефект: проверка роли даёт владельцу прямой обход до проверки конкретного разрешения. Поэтому полный доступ не зависит от длины списка назначений; это аварийный путь, который не ломается при добавлении нового права.

guest — не роль человека и не синоним бренд-менеджера. Это метка внешнего ключа Data API: она включает предел частоты, а области ключа разрешают только чтение данных и состояния. Бренд-менеджер — человек, которому такой канал нужен для работы без нашего посредничества; его описания страниц затем показывает наш интерфейс. Сам гостевой ключ не содержит площадочного профиля и не превращает получателя в пользователя интерфейса.

Что станет невозможным без этого

Разделение ответственности: любой сотрудник сможет действовать со всеми площадками, а внешний ключ нельзя будет ограничить, отозвать и замедлить отдельно от боевого сайта. При этом скрытый пункт меню ничего не защищает — запрет обязан действовать на прямой переход, а не на видимость пункта.

Какой ценой это даётся

Сложностью проверок: каждый запрос к данным проходит через права, и каждый случай «показать нельзя» — написанная и проверенная логика. Платим и поддержкой: изменение профилей требует теста и повторной синхронизации на среде.

Что здесь работает, а что только объявлено

Работает модель доступа нового интерфейса: роли, площадочные ограничения, проверка прямых переходов и тест BusinessAccessTest. Отдельно работают гостевые ключи Data API через WireGuard; это другой контур доступа, а не ещё одна роль интерфейса. В действующем формате гостевого ключа нет площадочного ограничения, а отдельный журнал «кто что читал» в приложенном договоре не объявлен — эти границы нельзя выдавать за готовые.

Как это устроено

Модель — в ACCESS-CONTROL; проверка запросов — блок «Выдача»; выдача ключей наружу — в админке бренд-менеджеров.