一个网站的权限系统设计思路分享

权限设计其实现方法千遍万化，但是本质主要要看你设计者是否考虑清楚了

• 权限颗粒度；
• 数据权限与功能权限的区分。

这里我引用我的一篇专栏文章具体来说：

一.权限体系简介

权限管理是一个几乎所有大中型B端系统的都会涉及的一个重要组成部分，主要目的是对整个后台管理系统进行权限的控制，而针对的对象是员工，避免因权限控制缺失或操作不当引发的风险问题，如操作错误，数据泄露等问题。

抽象来看权限体系可以分为如下两类：功能权限与数据权限两部分。

• 功能权限：指的是在系统中的一系列操作。常见的如：删除，编辑，提交等
• 数据权限：指数据中存在的数据是否能查看，如：钉钉中个人的出勤数据每人能看到，但是全公司的考勤数据却只有管理员能看到。

在这里权限的实现一共有两种模式：

“所见即所得”模式

用最通俗的话来说也就是，能看见相关操作就能执行对应的操作，所有的权限限制就在隐藏对应的操作页或按钮上，不进行区分查看与操作。

例如一个项目管理软件，当用户拥有了访问项目操作页的权限，在本模式里该项目的增删改查都对应拥有了，这里的核心就是只要能看到就能操作。

这个模式的好处是适合中小型B端客户，其本身没有复杂的岗位划分且要求系统简单易上手，毕竟一款B端的产品要是权限让用户配置半个小时，这对用户来说是个无比巨大的负担。

根据我的经验来看“所见即所得”这种模式基本满足80%的SaaS系统对权限管理的需求。

“读写分离”模式

所谓的读写分离，就是在第一种模式上进行了升级（这里的写泛指一切关于某模块的操作）。

怎么理解呢？当我们拥有了进入该页面的权限时，如果没有分配写的权限，就算看到了这些操作也不能使用。这种模式多用在数据权限上，而功能权限上是多用于预告给用户，只有当用户完成指定条件时才可以去操作。如未完成指定信息填写时，不能点击提交，但是提交按钮必须要在页面出现。

如果让我们用一张图来阐明这两种权限的设计体系的话，应该是这个样子的：

图：权限颗粒度
二.功能权限设计
具体来说我们可以划分为如下三步

图：设计步骤
让我们一步步来看：
步骤1：功能点封装
这里就是将我们系统中的功能进行梳理，得出一颗完整的功能树。你的权限系统想要控制到哪一层级，就将功能拆分到对应的层级即可。
例如：

图：功能拆分示例
步骤2：权限授予
在拆分完功能点后，我们就相当于有了一个完整的系统权限表（也称之为权限池），可以清楚的告诉用户什么环节可以进行配置，接下来我们需要设计的就是如何让用户去分配权限，即：权限授予。
在权限授予上我们要满足如下两个基本方向的设计：

• 角色概念：角色的理解，我们可以简单的理解为是一个个权限的集合。它通过提前将一部分权限进行配置成通用模板，随后只需将需要的人员授予这个角色就能拥有对应的权限。

• 权限池内自定义授予：在SaaS软件里经常我们会遇到这样的情况，之前我们配置的某某部门经理或助理的角色由于临时性工作借调可能会涉及多个岗位的工作，从而导致之前的角色权限不能满足，而此时这种个例现象又不好再单独创建角色给他，因此需要能在角色外再单独指派权限的功能。这里我们就称之为权限池内自定义授予。当然这里也适用于不在角色表中的任意权限分配。

值得提一句的是：一般的权限系统中要支持一人授予多个角色的功能。
步骤3：权限累加器
想必在步骤2大家肯定有疑问了，一人可以承接多个角色，又可以自定义额外权限，这样到最后个人权限要怎么定呢？
这里的权限累加器其实就是在解决这个问题，这里相当于是一个单独权限计算器，通过将前后授予的权限进行累加得到用户的最终权限。
这里的计算规则如下：

• 计算1：将变动前的权限集合在被授予新权限集合后两者取并集，去重相同的权限；
• 计算2：最终权限 = 角色权限 + 权限池内自定义授予权限

在一般权限授予中，我们给予权限一般都是越给越多。但是也有可能会是将某一角色的权限进行统一减少，此时我们就需要交由累加器帮我们去批量将多个拥有该角色的权限进行计算。
举个例来看：

在上面的例子中，我们的权限体系在上面进行了三次变动：
第一次：U298，278两位用户获得了初始员工权限并给予了发布新闻权限，此时由权限累加器帮我们计算出共拥有了7个权限；
第二次：新增了两位用户，并将四位用户在员工角色上又增加了部门助理角色，并额外增加了数据查看权限，此时权限累加器计算出这四位用户权限数为：
员工角色与部门助理的权限相同权限6项 + 部门助理独有的4项权限 + 发布新闻权限 + 数据权限 = 12项；
第三次：四位用户的共有角色部门助理被减去了一个权限，此时权限累加器计算出这四位用户权限数为11；