南宁响应式网站制作中企动力做网站 知乎

概述

• 我们业务系统中，最简单和经典的权限模型是 RBAC 基于角色的权限控制
• 同时，我们需要区分前端和后端权限的概念

1 ) 权限分层模型

前端权限	后端权限
路由权限：控制页面访问（Vue Router/React Router 的前置守卫）	接口权限：控制 API 访问（如 /api/user）
操作权限：控制按钮显隐（如编辑/删除按钮）	数据权限：控制接口返回的数据范围（如仅查看本人数据）

关键点：

• 前端权限依赖后端数据（避免前端硬编码，防止 Console 篡改）
• 后端权限需通过 角色 或 策略 封装，避免直接管理用户-接口映射

2 ) 权限控制方案对比

方案	原理	优势	劣势
RBAC	权限绑定角色 → 用户关联角色	维护高效（批量调整角色权限）	颗粒度较粗（角色内权限一致）
ACL	直接定义用户→操作策略（如 user:delete）	颗粒度精细（精确到操作）	维护成本高（用户量激增时复杂）

最佳实践：RBAC 为主 + ACL 补充（例如角色分配基础权限，ACL 控制特殊操作）

前端权限控制

前端权限主要通过路由权限和操作权限实现，需依托后端接口或数据支持
若权限逻辑完全写在前端，用户可通过修改代码绕过限制，失去权限意义：

1 ） 路由权限（菜单权限）

在Vue、React等框架中，通过路由守卫（前置/后置守卫）判断用户角色或菜单权限，控制页面访问
例如：用户无权限时，路由守卫拦截跳转请求

2 ） 操作权限

在页面详情中，根据用户权限控制新增、删除、编辑等按钮的显示/隐藏，对应接口请求的权限校验
其精细度高于路由权限，通常与路由权限结合使用

后端权限控制

后端权限核心是接口权限和数据权限，需通过权限模型封装实现：

1. 接口权限：控制用户能否访问特定接口；
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属性解析）进行比对，判断是否允许访问。但这种硬编码方式不合理——后续新增角色需修改代码，不符合动态权限管理需求

优化方案的核心逻辑如下：

1. 数据库设计：用户与角色为多对多关系（一个用户可拥有多个角色），角色关联模块和路由信息，通过角色管理用户可访问的路由
2. 动态权限校验：创建守卫，当用户访问模块中的路由时，校验用户角色是否包含该模块及路由的访问权限（替代装饰器硬编码标签）
3. 唯一标识生成：为避免模块/路由名称修改导致权限混乱，为每个路由生成唯一字符串标识（由controller唯一字符串+路由唯一字符串组合而成），存储于数据库作为角色-路由关联的关键信息

实现步骤建议：

1. 修改数据库，添加角色表、用户-角色关联表，存储动态角色信息
2. 开发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模型简化管理
• 实现选择：动态实现（数据库存储）灵活但复杂度高，静态实现（代码/配置文件）简单但扩展性弱