企业网站源码怎么用,石家庄设计公司,网站建设免费建站免费源代码,建英文网站有用吗前言
哈喽你好呀#xff0c;我是 嘟老板#xff0c;今天我们来聊聊几乎所有企业系统都离不开的 权限管理#xff0c;大家平时在做项目开发的时候#xff0c;有没有留意过权限这块的设计呢#xff1f;都是怎样实现的呢#xff1f;如果现在脑子里对于这块儿不够清晰#…前言
哈喽你好呀我是 嘟老板今天我们来聊聊几乎所有企业系统都离不开的 权限管理大家平时在做项目开发的时候有没有留意过权限这块的设计呢都是怎样实现的呢如果现在脑子里对于这块儿不够清晰那么请跟我一起来了解下企业系统常用的权限管理策略 - RBAC 模型。
介绍
为什么需要权限管理
要弄清楚这个问题我们先来看看什么是权限个人认为权限就是一系列用户可用的系统资源的整合可以大致分为以下三类
菜单权限用户使用的菜单、查看的页面等。操作权限系统页面中的交互功能按钮如编辑删除新增等。数据权限用户在页面中查看的数据内容业务系统数据一般存在机密性不同身份的用户查看的数据范围也有所不同。
了解了权限那么 权限管理 也就比较清晰了其实就是对系统用户访问资源的管理。根据业务要求的不同用户看到的菜单、使用的功能、查看的数据都有所不同。
那么为什么要控制访问权限呢因为不同的用户所负责的业务范围是不同的比如管理者可以看到所有下属的信息但是普通只能看到自己的比如行政可以看到所有人的打卡记录而普通员工只能看自己的比如财务可以看到所有人的工资而普通员工只能看到自己的…等等等等
这都离不开 权限管理通过为系统用户分配不同的权限以达到精准控制的目的。
什么是 RBAC 模型
RBACRole-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) 等等等等。欢迎评论区大家一起讨论学习。
感谢阅读愿你我共同进步谢谢
