前端权限有哪些模式？

01. PBAC

这就是之前提到的，经常用的 基于权限码（操作点）的访问控制

也就是之前的

1

<customer v-if(hasPermission('user:view')) />

这种其实更多的是去判断按钮，判断组件是否有权限加载。

后端通过 token 找到用户权限，然后判断用户是否有权限去访问

这种往往后端是通过那种树形结构的权限

比如

1
2

首页 => 本身的权限 View(访问)
     => 首页下面有按钮有图标之类的，单独设置

这种就可以确定每个页面(或者路由每个页面)的访问权限

但是他这个的问题也很明显，前端和后端他需要手动的去匹配。

所以这个名字就很重要

1
2

user:view
user:delete

如果涉及页面可能就需要改成

1
2

user:list:view
user:mange:view

之类的，需要有一个结构出来。

前端就可以通过变量去动态生成。

而不用去两边都去存一个结构

1
2
3
4
5
6
7

{
    "home": {
        "user": {
            ....
        }
    }
}

之类的。

这种是配置起来麻烦但是灵活，理论上前端的什么都能控制到。

02. RBAC

这种是角色授权

其实角色授权和基于权限码授权并不冲突，很多时候是一起用的。

角色代表着一堆授权码。

用户 ⬅️ 绑定 ➡️ 角色

角色 ⬅️ 绑定 ➡️ 权限码

或者说角色是权限的集合

角色的好处是，

设定好角色以后，用户绑定角色即可。逻辑清楚方便

还可以用多角色去玩，继承之类

这种前端表现差异不大，还是用权限码去解决。

他也很难独立存在。不然代码自己维护太蠢了。

03. ABAC

Attribute-Based Access Control 基于用户属性的权限控制

这种比较复杂，其实用的比较少(我用的比较少…)

首先什么是属性？
ip 是一种属性，比如很多国外的AI是不对中国开放的，中国IP访问会说不支持。

比如一个OA.

那么我的部门，我的职位，我的职级，都会是属性。

比如部门之间有层级，他的权限关联就不一样。

比如最顶级部门的人有全部权限 => 下级部门挨个挨个继承权限，越来越少。

有一些基础权限.

这个设计起来比较复杂。

比如

1
2
3

你的角色 主治医生，你也是住院医师
科室是 心脑血管科
假设你的职级是5

这个时候一个病人来找你看病。

你要看他的病历。

这个时候看病里这个动作修需要审查

病人是否挂号？

是否在规定时间看病？

病人挂号的科室 == 你的科室

他是住院的还是什么？

他的病历是否是主治医生才能看的

每一次访问请求本质上就是用户（主体）试图对某个资源执行一个动作

然后根据你的属性 动作的要求的属性进行匹配。

匹配之后做出允许或者拒绝的判断

你可以理解为他重新抽象了角色这种定义。

04. ReBAC

Relationship-Based Access Control

之前的都是角色或者人对于某个动作或者某个功能，模块之类的有没有权限

这个是指对资源的权限。

比如一个文档，比如某个设备，或者医院病人也是资源。

他权限的点不一样。

比如资源他只有4个权限，增删差改

某个角色，某个人对于这个资源是否有权进行控制

他是另一种维度的权限。主要还是后端需要新建表，对应人对于资源增加权限

比如我新建了一个文档，那么我是 ower 那么我对这个文档有完全控制，另外的人我可以分给他部分权限，比如 reader

类似这样。

他和角色之类的可以共存。

05. Mac

这种在做军工或者涉密的时候用的比较多。

他是根据你的级别和文档或者说资源的级别来确定是否有权限访问的一种方式

权限由系统强制决定，个人无权更改

比如我的文件，在其他模式下我理论上都可以给其他人权限看。

在 ReBAC, 我可以给你一个 reader

但是这个不行。

你自身有权限级别，比如3，如果文档属于3级别，那么就可以直接访问。
只要达不到这个权限就是强制不让访问