有关权限自动化的实践在我们项目中已经落地了一段时间,运行的也很顺利了,下面就来分享一下我们项目运行时遇到了什么问题,以及我们是怎么解决的。
我们后台管理权限采用的是权限设计模型中的 RBAC(Role-Based Access Control)
也就是基于 角色 的权限控制。
在实际的项目中应用的架构图基本上是这样的:
flowchart LR
menu1[菜单模块]
menu2[菜单模块]
menu11[菜单模块]
menu21[菜单模块]
api2[接口权限] --> menu1
api3[接口权限] --> menu1
api4[接口权限] --> menu2
api5[接口权限] --> menu2
api11[接口权限] --> menu11
api21[接口权限] --> menu11
api41[接口权限] --> menu21
api51[接口权限] --> menu21
menu1 --> role1
menu2 --> role1
role11[角色]
role1[角色]
menu11 --> role11
menu21 --> role11
user[用户]
role1 --> user
role11 --> user
key
,根据这个 key
,来判断当前用户信息中是否存在该 key
,从而决定前端的显示,目前该 key
,是前端开发在开发中自己定义的一个 唯一字符串我们生成环境的角色权限都是由 产品、运营 来配置的,而他们只清楚每个角色应该有哪些菜单模块的权限,不知道菜单模块对接着那些接口权限,而页面中对应那些接口权限只有前端知道,这就造成一个问题,每当有新增菜单模块的需求上线是,前端需要告诉产品,新增了那些菜单对应的 key
,以及 key
对应这那些接口权限。
而对于产品和运营来讲,他们只关心角色和菜单之间的关系,至于菜单和接口之间的关系对他们来说是负担,而当后台的管理系统用的人和覆盖的国家线越来越多时,沟通成本和理解成本也会越来越高。
flowchart LR
menu1[菜单模块]
menu2[菜单模块]
menu11[菜单模块]
menu21[菜单模块]
api2[接口权限] --> menu1
api3[接口权限] --> menu1
api4[接口权限] --> menu2
api5[接口权限] --> menu2
api11[接口权限] --> menu11
api21[接口权限] --> menu11
api41[接口权限] --> menu21
api51[接口权限] --> menu21
role11[角色]
role1[角色]
subgraph 实际关心
menu1 --> role1
menu2 --> role1
menu11 --> role11
menu21 --> role11
user[用户]
role1 --> user
role11 --> user
end
那么关于菜单和接口之间的关联关系,可不可以任何人不需要关心呢?
可以。方案是通过 扫描 项目中的每个页面所调用的接口,然后生成一个页面相关的 JSON
文件,然后根据该文件和项目中菜单配置文件生成一个新的文件,该文件的 key
是由菜单的路径标题拼接后hash
生成的唯一 key
。
这里有一个基本实现扫描的脚本的 例子,可以参考一下,执行
node index.js
就会扫描项目并生成一个menu-config.json
文件。