本文主要是介绍一文带你了解多数企业系统都在用的 RBAC 权限管理策略,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
前言
哈喽你好呀,我是 嘟老板,今天我们来聊聊几乎所有企业系统都离不开的 权限管理,大家平时在做项目开发的时候,有没有留意过权限这块的设计呢?都是怎样实现的呢?如果现在脑子里对于这块儿不够清晰,那么,请跟我一起,来了解下企业系统常用的权限管理策略 - RBAC
模型。
介绍
为什么需要权限管理
要弄清楚这个问题,我们先来看看什么是权限?个人认为,权限就是一系列用户可用的系统资源的整合,可以大致分为以下三类:
- 菜单权限:用户使用的菜单、查看的页面等。
- 操作权限:系统页面中的交互功能按钮,如编辑,删除,新增等。
- 数据权限:用户在页面中查看的数据内容,业务系统数据一般存在机密性,不同身份的用户查看的数据范围也有所不同。
了解了权限,那么 权限管理 也就比较清晰了,其实就是对系统用户访问资源的管理。根据业务要求的不同,用户看到的菜单、使用的功能、查看的数据都有所不同。
那么为什么要控制访问权限呢?因为不同的用户所负责的业务范围是不同的,比如管理者可以看到所有下属的信息,但是普通只能看到自己的;比如行政可以看到所有人的打卡记录,而普通员工只能看自己的;比如财务可以看到所有人的工资,而普通员工只能看到自己的…等等等等,
这都离不开 权限管理,通过为系统用户分配不同的权限,以达到精准控制的目的。
什么是 RBAC
模型
RBAC(Role-Based Access Control)
即:基于角色的权限控制。
基础设计如下:
在整个流程中,将 菜单、操作、组织 等系统资源统一由权限管理,再通过角色关联用户,角色关联权限的方式间接赋予用户权限。
那么,为什么需要角色这一节点呢,直接将权限分配给用户不是也可以实现吗?
当然可以,但是试想一下,如果为每个用户直接分配权限,首先权限配置就是一个比较大的工作量。而且,如果某一类用户的权限发生变更,就需要再次为每个人都变更权限配置,可见其扩展性和维护性方面就弱了不少,只能适用于用户数量,权限分类较少的平台。
而有了角色这一节点,就可以为不同的角色分配不同的权限,用户只需要关联指定的角色,不需要为一一分配繁琐的权限。而且角色权限变更后,也只需要更新某一角色的权限配置,无需对每个用户进行调整。
实现
设计思路
清楚了什么是权限管理,接下来我们就来思考一下如何设计一套基础的权限系统,假设我们目前只需要管理菜单权限。
如图所示,我们至少需要如下管理模块:
- 用户管理
- 菜单管理
- 权限管理
- 角色管理
其中,用户管理 和 菜单管理 负责基础信息维护,权限管理 是一系列 菜单资源 的集合,角色管理 是一系列 权限 的集合,可分配给指定用户。
从实际开发点来说,除了基础的 增删改查 之外,用户管理 需要 分配角色 功能,来为用户分配指定的一个或多个角色;权限管理 需要 分配菜单 功能,来为每个权限调整指定的菜单资源;角色管理 需要 分配权限 功能,来为每个角色分配一个或多个权限。
整个实现过程可大致分成三个部分:
- 实现前端管理模块
- 设计表结构,实现后端查询逻辑
- 前端路由管控,对标权限数据
1.实现前端管理模块
1.1 菜单层级设计
权限管理模块可以放到 系统设置 一级目录,与其他系统层级的配置一同管理。或者单独一个 权限管理 目录进行管理。
1.2 功能设计
我们来列举下相关的管理模块及可能涉及的操作:
- 角色管理:新增、删除、查看、编辑、分配权限、启用/停用。
- 权限管理:新增、删除、查看、编辑、分配菜单、启用/停用。
- 菜单管理:新增、删除、查看、编辑、启用/停用。
- 用户管理:新增、删除、查看、编辑、分配角色、启用/停用。
为什么需要 启用/停用 操作?
这是为了在状态上管理数据,如果数据没有状态,那么不需要的数据就只能删除,删除之后用户又想要找回这条数据怎么办。如果是逻辑删除的话还有办法,可以让技术在数据库后台手动恢复;但若是物理删除呢,那不好意思,只能用户重新建一条一样的了。不过无论是哪种删除模式,用户都没办法在前端界面直接操作。有了状态就不一样了,肯定不需要的数据直接删除,可能后续需要恢复的数据,就停用,需要时再次启用即可。
除了以上功能,角色管理 还可以加入 添加用户,菜单管理 可以添加 指定权限 等类似的功能,使得配置入口更加灵活,可以在 用户管理 处分配角色,也可在 角色管理 添加用户,减少用户使用系统的心智负担。
2.表关系设计
此部分为后端内容,其实整个权限系统的的核心逻辑都是在后端,工作量大概占了 70%
左右。
我们先来看看涉及到的几个实体类及关系:
其中 角色 与 用户,角色 与 权限,权限 与 菜单 都是 多对多 的关系,即一个权限可以分配给多个用户,一个用户也可被分配多个权限,以此类比 角色 与 权限,,权限 与 菜单。
鉴于此,数据表方面除了 角色,用户,权限,菜单 四个基础表之外,还需要 角色-用户,角色-权限, 权限-菜单 中间表,用于维护他们之间 多对多 的关联关系。
比如我们要实现 菜单 权限的控制,后端提供的 菜单 查询接口核心逻辑就是 根据当前用户所分配的所有角色,去匹配所有的菜单权限后做去重处理。
本部分属于业务代码,就不贴代码了,后续代码会上传到[个人项目](github.com/ying2gege/z…
3.前端路由对标权限
这一步是前端处理的重点,在 2.数据管理逻辑处理 步骤中提供了匹配权限后的菜单查询接口,前端可以调用该接口获取到菜单数据。
那么请想一想,拿到菜单数据之后,前端需要做些什么呢?
前端需要根据菜单数据,来匹配前端路由数据,仅保留和菜单数据匹配的路由配置。
那么什么是路由呢?
对于 SAP
项目,前端只有一个 html
页面,但是在项目中会有很多个页面,他们会分别对应一个特定的 url
,以实现页面刷新、跳转和后退等操作,能够实现以上功能的工具就是路由。以 Vue
项目为例,对应的路由工具叫做 VueRouter
,可以通过 VueRouter
提供的 配置项,组件 和 API
实现页面的渲染和导航。
清楚了什么是路由,接下来就是匹配过程。那么问题又来了 拿什么来匹配前端路由配置?
还是以 Vue
项目为例,路由至少需要以下配置项:
{name: 'Root',path: '/',component: () => import('@views/root/index.vue')
}
其中
name
是路由名称,全局唯一;path
是页面对应的url
,全局唯一;component
是对应的页面代码地址,即vue
页面。
既然 name
属性全局唯一,我们自然就可以拿 name
属性作为匹配指标,但是和什么匹配呢,回想下关于 菜单 结构的设计,有一个 Code
字段,即菜单编码,我们可以将此字段同样设计成全局唯一,作为与路由 name
属性匹配的数据指标,只要路由 name
属性能够与菜单 Code
字段匹配上,就保留该路由配置。
核心代码贴上:
export function matchRoutesByAuthMenus(routes: RouteRecordRaw[],menus: ZiMuAuth.Menu[]
) {if (!menus.length || !routes.length) return []const menuCodes = menus.map(m => m.code)const matchRoutes = (routes: RouteRecordRaw[]) => {const target: RouteRecordRaw[] = []for (const route of routes) {const matched = !route.name || menuCodes.includes(route.name as string)if (matched) {if (route.children?.length) {route.children = matchRoutes(route.children)}target.push(route)}}return target}const result: RouteRecordRaw[] = matchRoutes(routes)return result
}
参数 routes
是 所有路由配置,menus
是 后端返回的菜单列表。由于 路由配置 基本都存在嵌套的情况,所以采用 递归 的方式匹配子配置项,最终筛选出与菜单完全匹配的路由配置。
然后使用 VueRouter
的 addRoute API
将匹配后的路由配置循环添加到 router
中。
for (const route of matchedRoutes) {router.addRoute(route)
}
若想深入了解本步骤的实现逻辑,可前往《论真实 Vue 项目引发的对于路由权限的思考》
注: “添加到
router
中” 里提到的router
是调用VueRouter
的createRouter
函数创建的路由实例,后续的应用中所有路由相关的操作,如导航,都会用到该实例对象。不清楚的小伙伴可查看 官网。
增强
我们在上一趴实现了基础的权限管理,然而实际的企业系统,由于业务体量、人员基数等因素,可能需要更为复杂的权限管理系统。
经过无数业务实践的积累,业内也针对 RBAC
模型有个比较细致的分类,复杂度层层递进,着力满足绝大多数的业务场景。
RBAC0
模型:最基础的用户、角色、权限管理模型,与我们上面实现的相近。RBAC1
模型:在RBAC0
的基础上,增加了 子角色,引入继承的概念,即子角色可以继承父角色所有的权限,并支持在父角色的权限基础上进行删减。RBAC2
模型:在RBAC0
的基础上,增加对角色的一些限制,如角色互斥、基数约束、先决条件角色 等。RBAC3
模型:称为统一模型,综合了RBAC0
、RBAC1
、RBAC2
的所有特点。
虽然 RBAC
模型分了很多类,但是在实际项目中,应该结合企业的实际情况进行分析设计,不必非要追求实现某一个模型设计。比如公司规模不大的小型企业,比较基础的 RBAC0
模型就完全可以满足要求;若公司规模大、业务复杂、权限配置难度大,可以选择性的加入子角色,互斥角色,先决条件角色 等确保权限配置的建议性的精准度;若公司内部权限按部门划分,或某些小组划分,还可以加入 用户组,开辟另一个维度的管理方式,简化权限配置工作。
总之,权限管理并不是一种特定的范式,与企业实际业务情况息息相关。
结语
好啦,关于 RBAC
的内容就到这里啦,相信小伙伴在实际项目中也接触过其他的权限管理策略,比如访问控制列表(ACL)、属性访问控制(ABAC)、强制访问控制(MAC) 等等等等。欢迎评论区,大家一起讨论学习。
感谢阅读!愿你我共同进步,谢谢!!!
这篇关于一文带你了解多数企业系统都在用的 RBAC 权限管理策略的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!