如何设计一个完美的权限管理模块？

或许最好的人生，不在于诗和远方，而在于平静下来发现，眼前熟悉的一切皆是心之所向。

咱们比较常见的就是基于角色的访问控制，用户经过角色与权限进行关联。简单地说，一个用户拥有多个角色，一个角色拥有多个权限。这样，就构形成“用户-角色-权限”的受权模型。在这种模型中，用户与角色之间、角色与权限之间，一般都是多对多的关系。以下图：

基于这个，得先了解角色究竟是什么？咱们能够理解它为必定数量的权限的集合，是一个权限的载体。

例如：一个论坛的“管理员”、“版主”，它们都是角色。可是所能作的事情是不彻底同样的，版主只能管理版内的贴子，用户等，而这些都是属于权限，若是想要给某个用户授予这些权限，不用直接将权限授予用户，只需将“版主”这个角色赋予该用户便可。

可是经过上面咱们也发现问题了，若是用户的数量很是大的时候，就须要给系统的每个用户逐一受权(分配角色)，这是件很是繁琐的事情，这时就能够增长一个用户组，每一个用户组内有多个用户，除了给单个用户受权外，还能够给用户组受权，这样一来，经过一次受权，就能够同时给多个用户授予相同的权限，而这时用户的全部权限就是用户我的拥有的权限与该用户所在组所拥有的权限之和。用户组、用户与角色三者的关联关系以下图：

一般在应用系统里面的权限咱们把它表现为菜单的访问(页面级)、功能模块的操做(功能级)、文件上传的删改，甚至页面上某个按钮、图片是否可见等等都属于权限的范畴。有些权限设计，会把功能操做做为一类，而把文件、菜单、页面元素等做为另外一类，这样构成“用户-角色-权限-资源”的受权模型。而在作数据表建模时，可把功能操做和资源统一管理，也就是都直接与权限表进行关联，这样可能更具便捷性和易扩展性。以下图：

这里特别须要注意如下权限表中有一列“PowerType(权限类型)”，咱们根据它的取值来区分是哪一类权限，能够把它理解为一个枚举，如“MENU”表示菜单的访问权限、“OPERATION”表示功能模块的操做权限、“FILE”表示文件的修改权限、“ELEMENT”表示页面元素的可见性控制等。

这样设计的好处有两个：

1、不须要区分哪些是权限操做，哪些是资源，（实际上，有时候也很差区分，如菜单，把它理解为资源呢仍是功能模块权限呢？）；

2、方便扩展，当系统要对新的东西进行权限控制时，我只须要创建一个新的关联表“权限XX关联表”，并肯定这类权限的权限类型字符串便可。

须要注意的是，权限表与权限菜单关联表、权限菜单关联表与菜单表都是一对一的关系。（文件、页面权限点、功能操做等同理）。也就是每添加一个菜单，就得同时往这三个表中各插入一条记录。

这样，能够不须要权限菜单关联表，让权限表与菜单表直接关联，此时，须在权限表中新增一列用来保存菜单的ID，权限表经过“权限类型”和这个ID来区分是种类型下的哪条记录。最后扩展出来的模型完整设计以下图：

注意上面额外增长了一个操做日志表；

随着系统的日益庞大，为了方便管理，若是有须要可引入角色组对角色进行分类管理，跟用户组不一样，角色组不参与受权。

例如：当遇到有多个子公司，每一个子公司下有多个部门，这是咱们就能够把部门理解为角色，子公司理解为角色组，角色组不参于权限分配。另外，为方便上面各主表自身的管理与查找，可采用树型结构，如菜单树、功能树等，固然这些可不须要参于权限分配。

数据字典：
1.用户表：

2.角色表：

3.用户与角色关联表

4.用户组表

5.用户组与用户信息关联表

6.用户组与角色关联表

7．菜单表

8.页面元素表

9.文件表

10.权限表

11.权限与菜单关联表

12.权限与页面元素关联表

13.权限与文件关联表

14.功能操做表

15.权限与功能操做关联表

16.角色与权限关联表

17.操做日志表