autorizacao-rbac-por-recurso

Create a resource_permissions table storing user_id, resource_type, resource_id, and role, then add an authorize(action, resourceType) middleware to every route. The middleware looks up the user's role and checks it against an immutable permission matrix before allowing the operation.

Permissions propagate from project to folder to text. If no direct permission record exists for a resource, the system checks the parent folder, then the parent project, and applies the role found there unless a more restrictive explicit permission exists on the child.

No. Hiding UI elements is only a usability measure, not a security control. Authorization must be enforced in backend middleware on every data-modifying route, otherwise users can send direct API requests to modify resources they should not access.

This design uses five roles: ADMIN and OWNER with full read, write, delete, and member management; EDITOR with read and write; and VIEWER and GUEST with read-only access. The creator of a project defaults to OWNER and invited users default to VIEWER.

Use per-resource RBAC when the same user needs different roles across resources within one tenant, such as editor in one project and viewer in another. For isolating data between different tenants, use database row-level security instead.