Skip to content

[Feature] Внедрение ролевой модели доступа на базе CASL #64

@soorq

Description

@soorq

Контекст

Текущая система требует перехода от простых проверок ролей к гибкому управлению доступом на основе атрибутов (ABAC) и разрешений. Использование библиотеки casl позволит централизовать логику авторизации, упростить масштабирование прав доступа для различных сущностей (команд, досок, задач) и обеспечить консистентность проверок как на бэкенде, так и в перспективе на фронтенде.


Технические требования

  • Локация логики: src/features/auth/abilities, src/shared/guards
  • Инструменты: @casl/ability, @casl/prisma (или аналог для используемой ORM).
  • Логика работы:
    1. Создать фабрику AbilityFactory, которая на основе user.role и user.permissions генерирует объект Ability.
    2. Описать базовые правила для сущностей: Project, Board, Task, Team. Например: участник команды может читать доски, но только ADMIN или OWNER может их удалять.
    3. Реализовать декораторы и глобальный Guard для автоматической проверки Ability в контроллерах/резолверах.
    4. Интегрировать проверку владения ресурсом (например, user_id === task.author_id).

Цель и критерии приемки (Definition of Done)

  • База: Установлены зависимости @casl/ability. Созданы базовые типы AppAbility, Actions (manage, create, read, etc.) и Subjects.
  • Функционал: Все эндпоинты защищены проверкой разрешений. Роли ADMIN, MEMBER, GUEST имеют корректно разграниченные уровни доступа.
  • Лимиты/SLA: Оценка прав доступа должна происходить в памяти (O(1)) после загрузки профиля пользователя, не создавая избыточных запросов к БД.
  • Интеграция: Логика авторизации встроена в текущий процесс JWT-валидации; обновлены юнит-тесты для проверки сценариев Forbidden (403).

Важные указания

  • Производительность: Использовать ленивую загрузку правил авторизации только при необходимости. Кешировать инстанс Ability в рамках жизненного цикла запроса.
  • Ошибки: Выбрасывать ForbiddenException (HTTP 403) при недостаточном уровне прав.
  • Безопасность: Реализовать принцип "Default Deny" — если правило не описано явно, доступ должен быть запрещен. Обеспечить проверку принадлежности пользователя к команде перед проверкой детальных прав на доску.

Metadata

Metadata

Labels

api-designEndpoint and CRUD'sdocumentationImprovements or additions to documentationenhancementNew feature or request
No fields configured for Feature.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions