搬砖小抄

总结一下后台管理系统中的菜单权限

字数统计: 1.1k阅读时长: 3 min
2021/08/25 Share

前段时间空闲时候开发了一个后台管理的原型系统,做好之后发现菜单管理部分并不好用,主要问题就是菜单集API绑定、UI视图定义、UI路由定义三种功能一身,下面这个新增菜单的表单,你很难一次填正确。

ji-admin-ui-menu-add

你可以自己体验一下:http://ji-boot-demo.etcd.ltd/#/sys/resource

虽然这个表单会根据类型自动隐藏掉不需要的输入项,但还是有很多“猫腻”,比如:

  • 路由名称必须和Vue页面组件的name一致,否则路由缓冲失效

  • 路由地址有时候可以不填,有时候应该填URL,有时候应该填路径,不熟悉代码的人无从下手

  • 如果父节点是根节点,那么UI组件得填一个特殊的值

  • 等等。。。

所以潜规则太多,我曾经想写个文档说明一下这个地方应该怎么填,但是各种组合非常多,我自己都放弃了。

前端是基于D2-Admin二开,因此得按照既有的架构来做

目前的前端页面布局是这样的

ji-admin-ui

菜单管理页面是这样的

ji-admin-ui-menu-tree

重新设计

我总结下来,主要问题就是菜单这个东西承担了太多的职责,所以很复杂,因此思路是进行功能拆分。

API 注册表

API注册表的用处就是将后台的API接口收集起来,保存到数据库中,它包含的信息大概是这样

api-reg

当然实际上要存到数据库中的字段要多一些,比如这样

api-permission

总之,这个表保存了系统中所有的API接口信息,这样API接口的权限定义就完成了。

UI 资源表

个人觉得,后台管理系统中,除开业务功能,玩的的就是权限管理,为了能够让前后台在权限控制方面有一个比较好的体验,后台是需要管理UI资源的。

ui-res

目前UI资源包含视图按钮两类,他们可以关联API接口,而API接口的ID就来自前面的API注册表。这里关联的含义是进行API需求申明:

  • 对于视图类型,表示该视图的展示需要调用某些API。
  • 对于按钮类型,表示该按钮的动作执行需要调用某些API

这里的按钮并非就是Button,而是一切位于视图页面中的,需要进行权限控制的UI控件

菜单

菜单主要是为了实现以下需求:

  • 后台管理系统是通过菜单进行页面导航
  • 菜单的结构需要支持自定义
  • 对用户进行授权是通过菜单来进行,而不是直接使用API注册表UI资源表,因为菜单更加直观

menu2-info

现在,菜单的职责就很简单了,就是为了让前端去渲染菜单布局,根据后台配置定义菜单的执行动作。

业务操作

按照新的思路,一个新功能上线前需要新建对应的功能菜单,流程应该是这样

  • 第一步:后端开发工程师登记API接口信息(这个步骤可以自动化)
  • 第二部:前端工程师在系统中登记UI资源信息,API引用是通过勾选完成
  • 第三步:产品在系统中创建菜单(填写名字,选择上级菜单之类),对于视图导航的菜单需要关联一个视图(通过下拉框选择)

这样就把原来一个表单的业务拆分成了三个业务,分别由专业的人去做,容易出错的内容变成了下拉框选择的模式,技术要求就大大降低了。

权限控制

最后在梳理一下权限控制

前端的权限控制:根据登录用户是否拥有某个UI资源的权限编码控制视图、按钮、菜单的展示

后端的权限控制:通过安全框架(比如Spring Security)进行API鉴权

授权

授权是仍然是通过菜单来完成,从菜单->UI资源->API引用这个关系链上就能获取到完整的UI资源和API接口的权限集合。

CATALOG
  1. 1. 重新设计
    1. 1.1. API 注册表
    2. 1.2. UI 资源表
    3. 1.3. 菜单
    4. 1.4. 业务操作
    5. 1.5. 权限控制
      1. 1.5.1. 授权