RBAC 模型的简单实现
RBAC 模型基本介绍
RBAC(Role-Based Access Control,基于角色的访问控制)是一种广泛应用的权限管理模型。它的核心思想是通过角色来管理权限,而不是直接分配权限给用户。用户被赋予一个或多个角色,而每个角色拥有不同的权限。
RBAC 的核心组件
用户(User):系统的使用者。
角色(Role):一组权限的集合。
权限(Permission):对系统资源的具体操作(如读、写、删除等)。
用户-角色分配(User-Role Assignment):将用户与角色关联。
角色-权限分配(Role-Permission Assignment):将角色与权限关联。
RBAC 的工作流程
- 管理员定义角色(如管理员、编辑、访客)。
- 为每个角色分配相应的权限(如管理员可以读写,访客只能读)。
- 将用户分配到相应的角色。
- 用户通过角色间接获得权限
举例:
场景:
存在某系统,系统包含 1 ~ 10 个菜单目录,现在用户群体 A 需要拥有 1~3 的菜单权限,用户群体 B 需要拥有 3~5 菜单的权限,用户群体 C 需要拥有 6~10 的菜单权限…
RBAC 处理方式:
- 系统管理员定义角色,为用户群体 A 创建角色 A1,A1包含 1~3 的菜单权限,为用户群里 B 创建角色 A2…
- 将角色分配到不同用户群体。
- 不同用户根据分配到的角色,间接获得系统的部分权限。
RBAC 优缺点
优点
- 简化权限管理:通过角色间接分配权限,减少了直接管理用户权限的复杂性。
- 易于扩展:新增用户只需分配角色,无需重新定义权限。
- 支持最小权限原则:可以为角色分配最小必要的权限,降低安全风险。
- 适合多用户系统:在企业级应用中,RBAC 可以很好地支持复杂的权限需求。
缺点
- 角色爆炸问题:当角色过多时,管理角色本身会变得复杂。
- 灵活性不足:对于需要动态权限的场景(如基于时间、地点的权限),RBAC 的支持较弱。
- 权限粒度有限:RBAC 的权限控制通常是粗粒度的,难以实现细粒度的权限控制。
RBAC 的实现
数据库设计
图中由左至右,依次为:菜单表、菜单-角色对应表、角色表、角色-用户对应表、用户表;
菜单表和角色表之间为多对多关系;
角色表和用户表之间为多对多关系;
后端实现(SpringBoot + SaToken)
@PostMapping("/addMenu")
@Operation(summary = "新增菜单")
@SaCheckPermission("system:menu:add") // 只有用户含有该权限标识符,才会放行请求,否则抛出异常
public ResponseResult addMenu(@Validated @RequestBody MenuForm menuForm) {
log.info("addMenu:{}", menuForm);
menuService.addMenu(menuForm, StpUtil.getLoginId().toString());
return ResponseResult.ok().message("添加成功");
}
SaCheckPermission实现原理
/** SaToken 处理逻辑 **/
public void checkPermissionAnd(String... permissionArray){
// 先获取当前是哪个账号id
Object loginId = getLoginId();
// 如果没有指定权限,那么直接跳过
if(permissionArray == null || permissionArray.length == 0) {
return;
}
// 获取该用户的所有权限
List<String> permissionList = getPermissionList(loginId);
for (String permission : permissionArray) {
// 判断该权限是否在该用户的权限列表中,若不存在,则抛出 NotPermissionException 异常
if(!hasElement(permissionList, permission)) {
throw new NotPermissionException(permission, this.loginType).setCode(SaErrorCode.CODE_11051);
}
}
}
前端实现
/** 前端动态路由 **/
const dynamicRoutesFromBackend = (backendRoutes: MenuEntity[]): RouteType[] => {
// 辅助函数:如果路径以 '/' 开头,则去掉 '/'
const normalizePath = (path?: string): string => {
return path && path.startsWith('/') ? path.slice(1) : path || ''; // 确保路径存在后再处理
};
// 生成动态路由
const dynamicChildren: RouteType[] = [];
backendRoutes
.filter(route => route.status === 1)
.forEach(route => {
if (route.menuType === 'M') {
const normalizedPath = normalizePath(route.path);
if (normalizedPath && !route.children) {
dynamicChildren.push({
path: normalizedPath,
element: withLoadingComponent(
lazy(() =>
(modules[`/src/views/${normalizedPath}/index.tsx`]?.()
.then((module) => ({ default: (module as { default: React.ComponentType }).default }))) // 类型断言
|| import('../views/Error')
.then((module) => ({ default: (module as { default: React.ComponentType }).default }))
)
),
children: []
});
}
if (!route.path && route.children) {
route.children.forEach(childRoute => {
const normalizedChildPath = normalizePath(childRoute.path);
dynamicChildren.push({
path: normalizedChildPath,
element: withLoadingComponent(
lazy(() =>
modules[`/src/views/${normalizedChildPath}/index.tsx`]
? (modules[`/src/views/${normalizedChildPath}/index.tsx`] as () => Promise<{ default: React.ComponentType }> )() // 使用类型断言并确保返回 Promise<{ default: React.ComponentType }>
: import('../views/Error').then((mod) => ({ default: mod.default })) // 错误页面的处理
)
),
children: []
});
});
}
}
});
/**动态加载菜单**/
function covertRoutesToMenuItems(routes: RouteType[]): MenuItem[] {
// 查找 path 为 '/' 的根路由
const rootRoute = routes.find(route => route.path === '/');
if (!rootRoute || !rootRoute.children) {
return [];
}
// 递归解析子路由
const convertToMenu = (routeList: RouteType[]): MenuItem[] => {
return routeList
.filter(route => !route.hidden) // 过滤掉 hidden 为 true 的路由
.map(route => ({
key: route.path,
label: route.name,
icon: route.icon,
children: route.children ? convertToMenu(route.children) : undefined, // 递归处理子菜单
}));
};
// 开始处理 '/' 的子路由
return convertToMenu(rootRoute.children);
}
完整代码
前端完整代码地址 : Gitee
后端完整代码地址 : Gitee