前言

哈喽你好呀，我是 阿嘟嘟，今天我们来聊聊几乎所有企业系统都离不开的 权限管理，大家平时在做项目开发的时候，有没有留意过权限这块的设计呢？都是怎样实现的呢？如果现在脑子里对于这块儿不够清晰，那么，请跟我一起，来了解下企业系统常用的权限管理策略 – RBAC 模型。

介绍

为什么需要权限管理

要弄清楚这个问题，我们先来看看什么是权限？个人认为，权限就是一系列用户可用的系统资源的整合，可以大致分为以下三类：

菜单权限：用户使用的菜单、查看的页面等。
操作权限：系统页面中的交互功能按钮，如编辑，删除，新增等。
数据权限：用户在页面中查看的数据内容，业务系统数据一般存在机密性，不同身份的用户查看的数据范围也有所不同。

了解了权限，那么 权限管理 也就比较清晰了，其实就是对系统用户访问资源的管理。根据业务要求的不同，用户看到的菜单、使用的功能、查看的数据都有所不同。

那么为什么要控制访问权限呢？因为不同的用户所负责的业务范围是不同的，比如管理者可以看到所有下属的信息，但是普通只能看到自己的；比如行政可以看到所有人的打卡记录，而普通员工只能看自己的；比如财务可以看到所有人的工资，而普通员工只能看到自己的….等等等等，

这都离不开 权限管理，通过为系统用户分配不同的权限，以达到精准控制的目的。

什么是 `RBAC` 模型

RBAC（Role-Based Access Control）即：基于角色的权限控制。

基础设计如下：
一文带你了解多数企业系统都在用的 RBAC 权限管理策略

在整个流程中，将菜单、操作、组织等系统资源统一由权限管理，再通过角色关联用户，角色关联权限的方式间接赋予用户权限。

那么，为什么需要角色这一节点呢，直接将权限分配给用户不是也可以实现吗？

当然可以，但是试想一下，如果为每个用户直接分配权限，首先权限配置就是一个比较大的工作量。而且，如果某一类用户的权限发生变更，就需要再次为每个人都变更权限配置，可见其扩展性和维护性方面就弱了不少，只能适用于用户数量，权限分类较少的平台。

而有了角色这一节点，就可以为不同的角色分配不同的权限，用户只需要关联指定的角色，不需要为一一分配繁琐的权限。而且角色权限变更后，也只需要更新某一角色的权限配置，无需对每个用户进行调整。

实现

设计思路

清楚了什么是权限管理，接下来我们就来思考一下如何设计一套基础的权限系统，假设我们目前只需要管理菜单权限。

一文带你了解多数企业系统都在用的 RBAC 权限管理策略

如图所示，我们至少需要如下管理模块：

用户管理
菜单管理
权限管理
角色管理

其中，用户管理 和 菜单管理 负责基础信息维护，权限管理 是一系列 菜单资源 的集合，角色管理 是一系列权限的集合，可分配给指定用户。

从实际开发点来说，除了基础的 增删改查 之外，用户管理 需要 分配角色 功能，来为用户分配指定的一个或多个角色；权限管理 需要 分配菜单 功能，来为每个权限调整指定的菜单资源；角色管理 需要 分配权限 功能，来为每个角色分配一个或多个权限。

整个实现过程可大致分成三个部分：

实现前端管理模块
设计表结构，实现后端查询逻辑
前端路由管控，对标权限数据

1.实现前端管理模块

1.1 菜单层级设计

权限管理模块可以放到 系统设置 一级目录，与其他系统层级的配置一同管理。或者单独一个 权限管理 目录进行管理。

1.2 功能设计

我们来列举下相关的管理模块及可能涉及的操作：

角色管理：新增、删除、查看、编辑、分配权限、启用/停用。
权限管理：新增、删除、查看、编辑、分配菜单、启用/停用。
菜单管理：新增、删除、查看、编辑、启用/停用。
用户管理：新增、删除、查看、编辑、分配角色、启用/停用。

为什么需要 启用/停用 操作？

这是为了在状态上管理数据，如果数据没有状态，那么不需要的数据就只能删除，删除之后用户又想要找回这条数据怎么办。如果是逻辑删除的话还有办法，可以让技术在数据库后台手动恢复；但若是物理删除呢，那不好意思，只能用户重新建一条一样的了。不过无论是哪种删除模式，用户都没办法在前端界面直接操作。有了状态就不一样了，肯定不需要的数据直接删除，可能后续需要恢复的数据，就停用，需要时再次启用即可。

除了以上功能，角色管理 还可以加入 添加用户，菜单管理 可以添加 指定权限 等类似的功能，使得配置入口更加灵活，可以在 用户管理 处分配角色，也可在 角色管理 添加用户，减少用户使用系统的心智负担。

2.表关系设计

此部分为后端内容，其实整个权限系统的的核心逻辑都是在后端，工作量大概占了 70% 左右。

我们先来看看涉及到的几个实体类及关系：
一文带你了解多数企业系统都在用的 RBAC 权限管理策略

其中角色与用户，角色与权限，权限与菜单都是 多对多 的关系，即一个权限可以分配给多个用户，一个用户也可被分配多个权限，以此类比角色与权限，，权限与菜单。

鉴于此，数据表方面除了角色，用户，权限，菜单四个基础表之外，还需要 角色-用户，角色-权限， 权限-菜单 中间表，用于维护他们之间 多对多 的关联关系。

比如我们要实现菜单权限的控制，后端提供的菜单查询接口核心逻辑就是 根据当前用户所分配的所有角色，去匹配所有的菜单权限后做去重处理。

本部分属于业务代码，就不贴代码了，后续代码会上传到[个人项目](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) 等等等等。欢迎评论区，大家一起讨论学习。

感谢阅读！愿你我共同进步，谢谢！！！

原文链接：https://juejin.cn/post/7351708519177322530 作者：是嘟老板呐