手把手教你做系统权限设计，看完不要说还不会

权限设计在B端的管理系统里比较常见。一般的场景是不同类型的人员需要在一个系统里协同完成某项业务操作，他们分别具有不同的权限，操作不同的资源。在C端产品里，也能够看到权限的设计的存在，相对管理系统来讲的话，要简单一些。

先从简单的说起吧，比如，微信群里，有两个角色，群主和普通成员，分别有不同的权限。

普通成员：添加群成员，一般发言等

群主：删除群成员，设置群公告，群主管理权转让。

群主不仅有普通成员所有的权限，还有一些特殊权限，这些权限是普通成员所没有的。下图是根据微信的权限例子画的一个简单权限结构模型。

对系统来说，不论是群主还是普通成员，他们都是用户，但各自的权限不相同，但软件设计不可能根据不同的类型的用户单独去配置功能。如果后期增添了某一功能，岂不是需要分别对不同类型的用户配置相应功能。不管这个操作后期是不是让电脑来操作完成，都达不到功能灵活配置的需要。

权限控制本质是用户与资源的的配置，但是我们不可能为每个用户都要去配置权限。引入了角色对象，是为了将用户与权限隔离开，降低两者之间的耦合度，也就是两者之间的关系。通过角色来控制用户的权限分配，做到弱化用户与权限之间关联。比如，某个角色因需求的变化引起权限的增加或减少，我们只需要控制需求变动对用户角色的影响即可。

微信群的例子里面，群主与用户面向的资源有重叠的部分，也有差异的部分。不管是重叠的部分也好，还是差异的部分也好，他们对权限都是通过功能的有无控制来实现。比如说，当群成员较少的时候，群内每个人都可以改群名称，他们都有这个功能。但群成员的删除，只有群主有，群成员无。这里未涉及到不同用户角色拥有同一个功能，但操作的资源的广度不一样。所以说，这里权限设计通过功能的控制已经满足系统设计的需要。

但在一些较为复杂的例子里面，仅仅从功能上考虑是不够的，还要考虑到数据范围的控制。

举例说，公司内部管理系统软件的权限设计，根据业务类型划分，使用产品的用户角色有：

按照上面业务类型的划分，他们抽象的功能划分结构是这样的：

接着考虑下面的例子，在一个部门里，有不同级别的职位，不同的职级的人功能权限相同，但操作的数据范围是不一样的。比如说，销售部门的某一个副总监，能查阅到公司在整个华南地区的业务数据，他下属带的一个的业务员，负责广州地区业务，那么他就只能看到广州的业务数据，他上级的总监，不仅能查阅到华南地区的业务数据，还能查到其它地区的业务数据。总监，副总监，业务员都有查阅数据功能，但职位不同，所能够查看的数据范围也就一样。

不在一个部门里，同样会需要这样的考量。财务部门的财务总监，因为财务审计，可能需要查看所有地区的业务数据，他就需要有查看销售部门负责的所有地区的业务数据。产生这种需求是由公司的职能结构决定的。

上面的两个例子可以看到，对于业务不复杂的产品，仅从功能去设计是足够的。当系统变得复杂的时候，就需要在功能限制的基础上，加上数据范围的限制。可以认为，数据权限是对功能权限的补充。两者并不是独立的分类。

在权限的设计上，我是从两个方向来分解的，横向和纵向，横向对应的即是功能权限的设计，纵向对应的是数据权限的设计。其划分的原则：

横向（功能权限）。 在B端产品上，按组织的内部业务主体结构类型来划分。这种参照的现实依据是公司在实际业务运转中对在内部已经作了分割。比如，公司A内部，有部门a，b，c，d。一般情况下，a，b，c，d各自的内部数据是无法相互查阅的，业务操作都是相互独立，彼此因为没有对方的功能权限而无法进行相应的业务操作。C端产品上的会员制，等级制也都是功能权限的体现。

纵向（数据权限）。 纵向的划分的建立在功能基础上的，通常是反映的是不角色的等级关系的。在B端产品上，数据权限的划分往往基于组织架构的，这是为了满足管理的需要。比如说，销售部门里，销售总监和普通销售业务在一些重叠的功能上，看到数据范围不一样，前者显然要比后者大。

权限设计的难度在角色和资源的分配上，因为不同角色不仅在资源有业务交叉，不同角色之间在业务的又有交叉，最终反映的是功能权限和数据权限的设计。如果处理好功能权限和数据权限对资源的分割，那么不同用户角色的划分及用户角色之间的关联就有较为清晰的划分，也会为后期的产品迭代提供足够的空间。附权限设计的思路：

上图是个人对权限设计的总结，把系统看作一个完整的资源，不同角色处于不同位置，占据的资源不同。其中把握的核心点就是，从两个方向解构：

用户与用户角色是多对多的关系。一个用户可以有多个角色，一个角色可以对应多个用户。每个角色对应不同的权限，管理员可以对用户进行角色编辑和权限的分管理与分配。

一般情况下，系统对角色的扩展和权限的扩展都是有一定需求的：

最理想权限设计的是能够从业务上与职级上对权限进行打包，然后将权限赋给某一用户，只要是后期公司在业务结构上不做大的调整，都能满足自身角色变化之后权限所需的相应更改，并不需要考虑使用用户角色来满足权限的扩展。

功能权限和数据权限的区分是什么，各自的边界在哪里？

权限是对资源的控制和约束，如果只从这一点来出发，就难以去划分功能权限和数据权限的区别。起初，我的理解是数据权限是在数据上做的限制，功能权限是在功能操作上的限制，两者是独立的，这么理解似乎是对的。可是在后面梳理的时候发现了问题，销售部与生产部两个不同的业务部门，那么在权限控制上是归类到数据权限呢还是功能权限呢？还是说两者同样适用。如果说两者都能通用，那么两者的概念定义有问题，是不是应该去掉一项呢？如果我们在产品设计上，标尺是不清晰的，多面的，那么最终产品结构肯定混乱的，无法适应后期的扩展。这也是促使我去思考并决心找到两者的切入问题的出发点，以期达到「庖丁解牛」。所以我先从QQ群的例子来着手分析，在业务并不复杂的情况下，只考虑功能权限已足够达到权限管理的需要。在管理系统的例子里面，才有了数据权限的引入。也因此有了前面对权限的理解，先横向进行功能权限分解，在功能权限分解不能满足产品设计的需要，再考虑数据权限的补充。

另一种解决办法是你也可以把无权限的按钮的背景色设定为其它颜色（比如灰色），但不能禁用它，当点击它时就可以弹出你的提示了。

如果没有，简单了，3个实体表，用户，角色，菜单。

用户：（ID，姓名，……，角色ID）

角色：（ID，角色名称，角色描述……）

菜单：（ID，菜单名称，描述……，角色ID）

如果多个角色可能有同一个菜单，且一个人可能同时有多个角色，稍微麻烦一点。

3个实体表，用户，角色，菜单。2个关系表，用户—角色，菜单—角色。

用户：（ID，姓名，……）

角色：（ID，角色名称，角色描述……）

菜单：（ID，菜单名称，描述……）

用户—角色：（角色ID，用户ID）

菜单—角色：（角色ID，菜单ID）

实际系统开发中都是用第二个的。

从本质来说，无论何种类型的权限管理模型都可以抽象出三个基本的要素——即：用户（user）、系统/应用（system/application）、策略（policy）。

策略决定了用户和不同功能应用之间如何交互。反过来，也就是说，无论设计何种权限管理的模型，都是基于这三个基本要素来展开。

本文聚焦于目前应用最广的RBAC模型，但在这里提出三个基本要素，主要是为了帮助大家更好的理解权限管理，不至于在众多权限模型中迷失。

不同的公司或软件提供商，设计了无数种控制用户访问功能或资源的方法。但无论哪种设计，都可归到四种经典权限模型里——自主访问控制(DAC，Discretionary Access Control)、强制访问控制 (MAC，Mandatory Access Control)、基于角色访问控制 (RBAC，Role-based Access Control) 和基于属性访问控制 (ABAC，Attribute-based Access Control).

（我觉得翻译不好，但也找不到更贴切的。本文下面内容均以英文首字母来代替：DAC，MAC，RBAC，ABAC）。

本文主要就RBAC展开分析该模型的使用场景，以及如何基于该模型设计出合适的权限管理体系。但从文章便于理解的完整性的角度来考虑，会对DAC，MAC和ABAC进行简要的介绍。

DAC： 被操作对象，根据访问控制规则，来判断操作主体可对操作对象做哪些操作，比如只读或者是可写的权限。而自主的含义，则是拥有某种权限的用户，可以把权限赋予其他用户。

MAC： 被操作对象及用户两方均有各自的权限标识，用户能否对对象进行操作，取决于权限标识的对照关系。这种模型多用于等级制度明显，信息访问安全性要求高的场景，比如军事。

ABAC和RBAC有很多相通的地方，而且相比较而言ABAC实际上更灵活，符合未来发展的方向。因此，我们分析完RBAC后，再回过头来看ABAC。

Role-based Access Control，基于角色的权限控制模型。

顾名思义，给用户定义角色，通过角色来控制权限。 目前来说基于角色权限控制模型是应用较广的一个。特别是2B方向SAAS领域，应用尤其常见。

如上图示，用户拥有角色，且可拥有多个角色，而每个角色对应不同权限。

这样的好处是：不必为每一个用户去配置权限，拥有极大的灵活性和便利性。而当用户及权限的量级又大到另一个级别时，又引入了角色组和权限组概念，此处不做延伸，有兴趣的读者可以去搜些资料来看。

我们已经知道什么是RBAC模型了，在分析怎么来根据此模型来设计权限体系之前，我们再把这个模型要素进行拆分一下。

首先是：用户、角色、权限。

而权限，具体到某个软件来说，实际上包含两个方面。一个是菜单权限，另一个是数据权限。

不同的行业会有不同的使用场景，用户角色权限模型也会有不同程度上的变化。但归到底层来说，还是离不开上面我画的这个图。

上面这个图是从官网看到的，销售自动化领域十分典型的用户权限管理设计。

接下来，我们来抽象一个场景或者说案例，来辅助我们理解整个权限管理设计的过程。假设A公司是个中大型的生产制造公司，公司有OA、HR、CRM、ERP一系列管理软件。公司员工以万计，不同人员职责不同，体现在管理软件上，就是会需要使用不同的功能来完成工作。

帐号是人和软件进行交互时的一个身份的转化。账号的背后，代表了这个操作的人。账号管理应该是所有需要和系统交互的人的统一管理，包含基础信息，比如：这个人的名字，性别、手机号、部门以及其他属性。

角色管理，就是要从实际场景出发，比如：使用系统的企业或者团体，有哪几类使用的角色——也就是说，有哪几类人，是需要有不同的业务菜单和业务数据的。

说到底，角色管理，就是把这个角色对应的人平时工作需要的菜单、功能给划到一个组里。给这一个个的操作组定义不同的名称——即角色名称。

当然，这个角色管理除了规定了该角色的人平时可对哪些功能进行查看操作，还需规定这个角色，能看到哪些范围内的数据。也就是前面提到的，权限实际上包含的是菜单权限和数据权限两部分。

系统内功能控制的颗粒度越细，对使用者来说配置角色便越灵活，但对系统的设计者来说，系统的复杂度自然也会上升，成本也会增加。

因此，到底控制到哪一层级，就要视具体业务场景来定，比如：有些行业的系统，可能控制到一级菜单就可以（某些SAAS工具），但有些系统，不仅需要控制所有的子级菜单，每一个按钮操作，甚至还会需要控制到不同的字段（比如Salesforce的权限控制系统）。

不过，我们抽象出了基本的模型，根据实际业务再去发散，就不是最困难的事了。

至此，我们可以了解到：RBAC模型实际上能解决大部分的权限设计问题了。

那么，ABAC到底是什么呢？它存在的意义在哪里？关于未来的权限设计趋势，它能带给我们什么启发呢？

带着这些问题，我们先来看看到底什么是ABAC模型。

ABAC，Attribute-based Access Control. 基于属性的访问控制。而属性，总的来说有三类：用户属性、系统或应用被访问属性（数据和操作）、环境属性。

也就是说，系统根据一组或多组属性是否满足预设规则来动态的控制，谁可以访问哪些功能数据和操作。RBAC模型，其实可以看成是静态的、单组属性的ABAC模型。

用例子来理解这个模型就是：只有当用户角色为Admin，在工作时间内，且处在C栋大楼B实验室，才可以访问D文件。

实际上，ABAC是个可以以最细颗粒度来管理权限的模型。它可以让设计者，利用任何一个用户属性、环境属性，或者多个属性之间的交集、并集等来组合出动态的权限判断逻辑。

它是这么强大，既可以有效的帮助信息辨别能力差的用户过滤垃圾信息。也可以让商家用到营销广告填满你生活的每个角落却不自知。

但我一直坚信， 科技 绝对是让生活更美好。

权限管理，可能是每个2B产品经理需要面对的问题。但无论C端还是B端的产品，了解权限管理的设计法则，让自己更好的理解产品的架构，让产品的每次迭代都心里有数。

题图来自Unspalsh, 基于CC0协议。

一种是修改最终编译的文件加上一个manifest文件,这样操作系统启动程序的时候就会自动请求管理员权限

二个就是检测到当前没有管理员权限时,重新启动当前进程,启动的动词加上runas,这样操作系统就会请求以管理员模式启动它了.

如果数组越界是否破坏了原来的函数调用栈，或者访问到了不可访问的地址，或者写了只有读权限的地址，那肯定会出错了。

但是如果你的数组的越界只是访问到了原本就没有被分配的内存，那么就不会出错，但是不能保证这么下去一直不会错。

给一个从CSDN找到的代码

#include windows.h//这里自己加上括号

VOID ManagerRun(LPCSTR exe,LPCSTR param,INT nShow=SW_SHOW)

{ //注意：会跳出提示。

SHELLEXECUTEINFO ShExecInfo

ShExecInfo.cbSize = sizeof(SHELLEXECUTEINFO)

ShExecInfo.fMask = SEE_MASK_NOCLOSEPROCESS

ShExecInfo.hwnd = NULL

ShExecInfo.lpVerb = "runas"

ShExecInfo.lpFile = exe

ShExecInfo.lpParameters = param

ShExecInfo.lpDirectory = NULL

ShExecInfo.nShow = nShow

ShExecInfo.hInstApp = NULL

BOOL ret = ShellExecuteEx(&ShExecInfo)

//等不及了，不等了。

CloseHandle(ShExecInfo.hProcess)

return

}

int main(int argc,char *argv[])

{

if(argc == 1) //初次运行，即双击EXE

{

ShowWindow(GetConsoleWindow(),SW_HIDE)

ManagerRun(argv[0],"2")

return 1

}else if(argc == 2) //再次运行,即上面那个ManagerRun

{

}

return 0

}

通常比较简单的权限设置中，比如servlet或者struct中，我们可以通过filter或者拦截器来控制某些文件的访问来实现。

但是根据你的要求，需要对功能列表和按钮都实现控制，那么需要的考虑的更多一点。

你的权限不能建立在控制url连接上，而是要转向对 一个方法的控制：

一般的权限控制，控制方法有四种 C(reate) R(etrieve) U(pdate) D(elete)

也就是说，一般你的Action种有 创建、查询、更新、删除几种精元操作。最后你的控制都总结为这几点，你在数据库中增加一个表，来对某一个Action的CRUD的操作权限。

1. 在控制按钮的时候，你可以通过css来控制显示。

2. 功能列表不建议通过js或者css，而是通过后台json来创建树最好。