В больших системах требуется гибкая и масштабируемая модель прав. Классическая проверка доступа строится вокруг ролей: пользователь получает одну или несколько ролей (например, admin, manager, viewer), и каждая роль содержит набор разрешений.

При использовании такого подхода появляются проблемы: - Роли начинают разрастаться и дублировать друг друга. - Возникают “почти одинаковые” роли с минимальными отличиями. - Сложно управлять точечными исключениями: если одному пользователю нужно дать доступ только к одной дополнительной кнопке, добавлять новую роль становится избыточно.

Чтобы решить эту задачу и избежать подобных проблем мы используем комбинацию RBAC (Role-Based Access Control) и permission-based подхода ⚙️

У нас есть два уровня:

1 уровень — группы пользователей (можно назвать их ролями: admin, manager, top-manager и т.д).

Это верхнеуровневая агрегация прав. Группа содержит набор доступных для неё permissions.

2 уровень — permissions (разрешение на выполнение действия)

Это атомарные флаги, которые описывают конкретное действие: - user.read - user.edit - order.create - order.cancel - feature.toggleX

Конечный пользователь в итоге получает список доступных permissions через включение его в группы + индивидуальные permissions.

Как это выглядит на frontend

После аутентификации backend возвращает список permissions пользователя. Frontend не работает напрямую с кодами групп/ролей — только с уже “развернутыми” permissions:

const canEdit = usePermission(‘user.edit’);

return {canEdit && editComponent};

Такой подход даёт баланс между управляемостью и гибкостью: роли упрощают администрирование, permissions позволяют точно контролировать поведение интерфейса, а изменение прав пользователей осуществляется  без доработок front/back-сервисов ✨

#js #javascript #typescript #frontend #фронтенд #разработка #dev #webdev #react #nodejs #backend #rbac #permissions