权限设计

权限控制

ACL

ACL（权限控制列表）：控制当前用户能访问的文件、文件夹等。此权限直接跳过了角色、账户，直接赋予用户权限

例如在 Linux 系统中，使用 chmod 命令赋予用户权限

自助访问控制（DAC: Discretionary Access Control）

系统为用户分配 权限控制列表、权限控制矩阵

对权限控制比较分散，不便于管理，无法将文件设置为统一的权限开发给指定用户

强制访问控制（MAC: Mandatory Access Control）

每个用户具有一些权限标识，每个对象也具有权限标识，用户是否能访问取决于双方的权限标识关系

RBAC

RBAC（基于角色的权限控制）：Who 可以对 What 进行 How 操作，RBAC 关注的是角色

User ==> Roles
Role ==> Permissions

1. 垂直权限（功能权限）：例如 Admin 拥有部分权限；A 角色拥有部分权限；B 角色拥有部分权限
2. 水平权限（数据权限）：当多个用户存在相同权限时，A 用户无法操作 B 用户数据

角色继承

可以继承其他角色

职责分离(Separation of Duty)

避免过多权限而产生利益冲突，对 RBAC 扩展

1. 静态职责分离：用户无法同时被赋予有冲突的角色
2. 动态职责分离：用户在一次会话（Session）中不能同时激活自身所拥有的、互相有冲突的角色，只能选择其一

OAuth

不提供账户和密码情况下，进行三方授权

基于属性的权限验证（ABAC: Attribute-Based Access Control）

ABAC 则是通过动态计算一个或一组属性来是否满足某种条件来进行授权判断（可以编写简单的逻辑）。属性通常来说分为四类：用户属性（如用户年龄），环境属性（如当前时间），操作属性（如读取）和对象属性（如一篇文章，又称资源属性），所以理论上能够实现非常灵活的权限控制，几乎能满足所有类型的需求

1. 集中化管理
2. 可以按需实现不同颗粒度的权限控制
3. 不需要预定义判断逻辑，减轻了权限系统的维护成本，特别是在需求经常变化的系统中
4. 定义权限时，不能直观看出用户和对象间的关系
5. 规则如果稍微复杂一点，或者设计混乱，会给管理者维护和追查带来麻烦
6. 权限判断需要实时执行，规则过多会导致性能问题

前端权限设计

全局路由判断

在每次路由跳转时，进行权限判断

优点

1. 设计和实现简单

缺点

1. 此种设计一般菜单和路由无法分离，此时如果菜单出现修改，也需要发版

登录页主页分离

登录页不存子主页内，在登录后，即可拿到账户所有权限，次数再根据权限加载页面或菜单

优点

1. 不比加载所有的路由和菜单，按需加载即可

缺点

1. 设计和实现较为复杂点，不再是纯粹的单页面应用了
2. 路由和菜单同样无法分离

路由和菜单分离

路由拆分：将通用路由和权限分离分离开来，对于权限路由动态配置，例如 vue 可以使用 addRoutes 来添加

菜单分离：菜单和路由之间肯定存在映射关系，可使用如下来管理配置

1. 配置文件：配置文件写死，每次更新配置文件即可
2. 后端返回：通过动态配置方式，后端每次返回配置列表

优点：

1. 实现菜单和路由完全分离；实现路由的完全分离

缺点

1. 前后端配合改造，成本更高
2. 可能出现别的问题，例如当路由完全由后端返回时，前端未引入路由文件，则 webpack 就 无法加载和解析文件了，可使用如下方式加载文件

// 路由文件定义
const UserInfo = () => import("../pages/UserInfo.vue");
export default {
  UserInfo,
};