Nestjs框架: RBAC基于角色的权限控制模型初探
概述
- 我们业务系统中，最简单和经典的权限模型是 RBAC 基于角色的权限控制
- 同时，我们需要区分前端和后端权限的概念
1 ) 权限分层模型
| 前端权限 | 后端权限 |
|---|---|
路由权限：控制页面访问（Vue Router/React Router 的前置守卫） | 接口权限：控制 API 访问（如 /api/user） |
操作权限：控制按钮显隐（如编辑/删除按钮） | 数据权限：控制接口返回的数据范围（如仅查看本人数据） |
关键点：
- 前端权限依赖后端数据（避免前端硬编码，防止 Console 篡改）
- 后端权限需通过
角色或策略封装，避免直接管理用户-接口映射
2 ) 权限控制方案对比
| 方案 | 原理 | 优势 | 劣势 |
|---|---|---|---|
| RBAC | 权限绑定角色 → 用户关联角色 | 维护高效（批量调整角色权限） | 颗粒度较粗（角色内权限一致） |
| ACL | 直接定义用户→操作策略（如 user:delete） | 颗粒度精细（精确到操作） | 维护成本高（用户量激增时复杂） |
最佳实践：RBAC 为主 + ACL 补充（例如角色分配基础权限，ACL 控制特殊操作）
前端权限控制
前端权限主要通过路由权限和操作权限实现，需依托后端接口或数据支持
若权限逻辑完全写在前端，用户可通过修改代码绕过限制，失去权限意义：
1 ） 路由权限（菜单权限）
在Vue、React等框架中，通过路由守卫（前置/后置守卫）判断用户角色或菜单权限，控制页面访问
例如：用户无权限时，路由守卫拦截跳转请求
2 ） 操作权限
在页面详情中，根据用户权限控制新增、删除、编辑等按钮的显示/隐藏，对应接口请求的权限校验
其精细度高于路由权限，通常与路由权限结合使用
后端权限控制
后端权限核心是接口权限和数据权限，需通过权限模型封装实现：
- 接口权限：控制用户能否访问特定接口；
- 数据权限：限制用户可读取/操作的数据范围（如部分接口返回数据需按用户角色过滤）。
直接将用户与接口权限绑定会导致配置量呈指数级增长（如100个用户对应200个接口，需维护20000条关系），因此需采用基于角色或基于策略的权限模型
基于角色的权限控制（RBAC）
- 核心逻辑：将权限分配给角色，再将角色赋予用户。例如：为“管理员”角色分配“用户管理”接口权限，所有被赋予该角色的用户自动获得权限。
- 优势：简化权限管理，支持批量调整用户权限（只需修改角色权限）。
基于策略的权限控制
- 核心逻辑：通过策略列表（如接口的增删改查权限）直接定义用户权限。例如：用户需单独配置“API_user:delete”策略才能删除用户。
- 优势：颗粒度精细；
- 缺点：维护成本高，易出错，通常与RBAC结合使用（如角色关联基础策略，特殊权限单独配置策略）。
RBAC模型的实现方式
RBAC在后端实践分为动态和静态两种实现：
1 ）动态实现
将用户、角色、权限信息存储在数据库（如user表、role表、permission表），权限校验时从数据库读取配置（如路由守卫逻辑中查询用户角色对应的权限）
2 ）静态实现
在代码（如Controller、路由注解）或配置文件中硬编码权限规则，无需查询数据库
// 伪代码示例：静态权限注解
@Controller('/user')
class UserController { @RequirePermission('admin') // 静态配置：仅admin角色可访问 @Get('/list') async getUserList() { /* ... */ }
}
3 ）参考Nestjs 官方文档
- authorization
这里的基础RBAC主要是指：一个用户可能拥有一个角色，该角色对应不同controller或路由的访问权限
其核心实现逻辑如下：
首先，官方方案定义了一个枚举类型，包含user、admin等角色，作用是通过装饰器读取用户角色类型，并在controller或路由层面打标签。但该方案存在局限性：角色列表在代码中硬编码（inline写死），应用面较窄。实际开发中，角色及用户-角色关联关系建议存储在数据库，而非直接写死在代码中
官方方案的核心逻辑为：通过路由装饰器标记可访问角色，首位（守卫）读取装饰器中的角色信息，与用户拥有的角色（从request对象的user.roles属性解析）进行比对，判断是否允许访问。但这种硬编码方式不合理——后续新增角色需修改代码，不符合动态权限管理需求
优化方案的核心逻辑如下：
- 数据库设计：用户与角色为多对多关系（一个用户可拥有多个角色），角色关联模块和路由信息，通过角色管理用户可访问的路由
- 动态权限校验：创建守卫，当用户访问模块中的路由时，校验用户角色是否包含该模块及路由的访问权限（替代装饰器硬编码标签）
- 唯一标识生成：为避免模块/路由名称修改导致权限混乱，为每个路由生成唯一字符串标识（由controller唯一字符串+路由唯一字符串组合而成），存储于数据库作为角色-路由关联的关键信息
实现步骤建议：
- 修改数据库，添加角色表、用户-角色关联表，存储动态角色信息
- 开发RBAC功能，替换硬编码装饰器，通过守卫动态读取数据库权限并校验
核心代码示例（伪代码）：
// 数据库模型定义（示例）
class Role { id: number; name: string; module: string; // 模块标识 route: string; // 路由标识 uniqueKey: string; // controller唯一标识+路由唯一标识
} // 权限守卫逻辑
@Injectable()
export class RbacGuard implements CanActivate { constructor(private roleService: RoleService) {} async canActivate(context: ExecutionContext): Promise<boolean> { const request = context.switchToHttp().getRequest(); const user = request.user; // 从请求中解析用户信息 const { module, route } = this.getRouteInfo(context); // 获取当前路由的模块和路由标识 const requiredRoles = await this.roleService.findRolesByModuleAndRoute(module, route); // 从数据库查询允许访问的角色 return user.roles.some(role => requiredRoles.includes(role.name)); // 角色比对 }
}
总结
- 前端权限：通过路由守卫和按钮级控制实现，依赖后端数据
- 后端权限：核心是接口与数据权限，推荐使用RBAC模型简化管理
- 实现选择：动态实现（数据库存储）灵活但复杂度高，静态实现（代码/配置文件）简单但扩展性弱