本文将对这种设计思想作进一步的扩展，介绍数据权限的设计方案。
权限控制可以理解，分为这几种 ：
【功能权限】：能做什么的问题，如增加产品。【数据权限】：能看到哪些数据的问题，如查看本人的所有订单。【字段权限】：能看到哪些信息的问题，如供应商账户，看不到角色、 部门等信息。
本文将对这种设计思想作进一步的扩展，介绍数据权限的设计方案。
权限控制可以理解，分为这几种 ：
【功能权限】：能做什么的问题，如增加产品。【数据权限】：能看到哪些数据的问题，如查看本人的所有订单。【字段权限】：能看到哪些信息的问题，如供应商账户，看不到角色、 部门等信息。
上面提到的那种设计就是【功能权限】，这种设计有一定的局限性，对于主体，只能明确地指定。对于不明确的，在这里可能就没办法处理。比如下面这几种情况：
数据仅当前部门及上级可见
数据仅当前用户(本人)可见
类似这样的就需要用到上面提的数据权限。
上一篇文章我用一个表五个字段完成了【功能权限】的设计思路本文我将介绍如何利用一个表两个字段完成这个【数据权限】的设计思路
【数据权限】是在【功能权限】的基础上面进一步的扩展，比如可以查看订单属于【功能权限】的范围，但是可以查看哪些订单就是【数据权限】的工作了。
在设计中，我们规定好如果没有设置了数据权限规则，那么视为允许查看全部的数据。
【资源】：数据权限的控制对象，业务系统中的各种资源。比如订单单据、销售单等。属于上面提到的【领域】中的一种
【主体】：用户、部门、角色等。
【条件规则】：用于检索数据的条件定义
【数据规则】：用于【数据权限】的条件规则
应用场景1，订单，可以由本人查看 2，销售单，可以由本人或上级领导查看 3，销售单，销售人员可以查看自己的，销售经理只查看 销售金额大于100,000的。
我们能想到直接的方法，在访问数据的入口加入SQL Where条件来实现，组织sql语句：
where UserID = {CurrentUserID}
where UserID = {CurrentUserID}
or {CurrentUserID} in (领导)
where UserID = {CurrentUserID}
or ({CurrentUserID} in (销售经理)
and 销售金额 & 100000）
这些一个一个的"条件"，本文简单理解为一个【数据规则】，通常会与原来我们前台的业务过滤条件合并再检索出数据。
这是一种最直接的实现方式，在【资源】上面加一个【数据规则】（比如上面的三点）。这样设计就是
　　【资源】 - 【数据规则】
我又觉得不同的人应该对应不同的规则，那么也可以理解为，一个用户对应不同的角色，每一个角色有不一样的【数据规则】，那么设计就变成
　　【资源】 - 【主体】 - 【数据规则】
根据提供者的不同，准备不同的权限应对策略。
这里可以简单地介绍一下，这个方案至少需要2张表，一个是
【资源，主体，规则关系表】、一个是【数据规则表】
关系表不能直接保存角色，因为你不确定什么时候业务需要按照【部门】或者【分公司】来定义数据规则
于是可以用
Master、MasterKey
类似这样的两个字段来确定一个【主体】
当然，上面是用SQL的方式来确定条件规则的，我们当然不会这么做。SQL虽然灵活，但是我们很难去维护，也不知道SQL在我们的界面UI上面如何体现。难不成直接用一个文本框来显示。这样对应一个开发人员来说不是问题，可是对应系统管理员，很容易出问题。所以我们需要有另一方式来确定这一规则，并最终可以转换成我们的SQL语句。
我们的设计关键在于如何规范好这些【数据规则】 ，这个规则必须是对前端友好的，而且是对后台友好的，JSON显然是很好的方式。
规则说明：
1，数据权限规则总是：｛属性 条件 允许值｝
2，数据权限规则可以合并。比如 （ {当前用户 属于 销售人员} and {订单销售员 等于
当前用户} )
Or {当前用户
属于 销售经理}
3，最终我们会用JSON格式
在检索数据时会先判断有没有注册了某某【资源】的【条件规则】，如果有，那么加载这个【条件规则】并合并到我们前台的【搜索条件】（你的业务界面应该有一个搜索框吧） 如下图定义了客户信息的搜索框，我们搜索客户ID包括AN，我们组织成的规则将会是：
{"rules":[{"field":"CustomerID","op":"like","value":"AN","type":"string"}],"op":"and"}
为了更好地理解【数据规则】，这里介绍一下【通用查询机制】
【通用查询机制】
权限控制总离不开一些条件的限制(比如查看当前部门的单据)，如果没有完善的通用查询规则机制，那么在做权限条件过滤的时候你会觉得很别扭。这里介绍一个通用查询方案，然后再介绍如何实现【数据规则】。
{"field":"OrderDate","op":"less","value":""},
{"field":"CustomerID","op":"equal","value":"VINET"}
,"op":"and"}
规则描述：
查找顾客VINET所有订单时间小于2011-01-01的单据
这样的数据是安全的，而且是通用的(你甚至可以再加一个OR子查询)。无论是在前端还是后台，无论你使用什么样的组件，都可以很好地利用。
通用后台的翻译，就可以生成这样SQL的参数：
([OrderDate] & @p1 and [CustomerID] = @p2)
Parameters:
p1:2012-01-01
下面来点复杂的：查找 顾客VINET或者TOMSP，所有订单时间小于的单据
"rules":[{"field":"OrderDate","op":"less","value":""}],
"groups":[
{"rules":[{"field":"CustomerID","op":"equal","value":"VINET"}, {"field":"CustomerID","op":"equal","value":"TOMSP"}],"op":"or"}
"op":"and"
翻译结果：
Text:([OrderDate] & @p1 and ([CustomerID] = @p2 or [CustomerID] = @p3))
Parameters:
p1:2012-01-01
这个过滤规则分为三个部分：【分组】、【规则】(字段、值、操作符)、【操作符】(and or)，而自身就是一个分组。这种简单的结构就可以满足全部的情况。
当然，上面提到的这些条件都是在前台定义(可能是用户在搜索框自己输入的)的，而 在后台，我们可能会定义一下【隐藏条件】，比如说 【员工只能查看自己的】，要怎么做呢，其实很简单，只需要在后台接收到这个过滤条件(前台toJSON，后台解析JSON)以后，再加上一个过滤规则(隐藏条件)：
{field:'EmployeeID',op:'equal',value:5}
可以将原来的过滤规则当做一个分组加入进行：
{op:'and',groups:[
{"rules":[{"field":"OrderDate","op":"less","value":""}],
"groups":[
{"rules":[{"field":"CustomerID","op":"equal","value":"VINET"},{"field":"CustomerID","op":"equal","value":"TOMSP"}],"op":"or"}
],"op":"and"}
],rules:[{field:'EmployeeID',op:'equal',value:5}]
翻译如下：
([EmployeeID] = @p1 and ([OrderDate] & @p2 and ([CustomerID] = @p3 or [CustomerID] = @p4)))
Parameters:
p2:2012-01-01
这样的【条件规则】才是我们想要的，不仅在前端可以很好地解析，也可以在后台进行处理。在后台我们会定义跟这种对应的类，那么再定义一个翻译成SQL的类：
数据权限规则
说了这些，可以开始介绍如何实现【数据规则】了：
上面提到的【隐藏条件】，就是我介绍的【数据规则】试想一些，这样 前台的过滤规则，再加上我们之间定义好的 【数据权限】控制 过滤条件。不就达到目的了吗。先看看我们在里保存的这些【数据规则】：
看不明白？那来个清楚一点的：
下图是我们设计【数据权限】的界面，可以选择所有的字段，包括几个用户信息：
如果说数据权限是对功能权限在纵向的扩展，那么字段权限就是在横向的扩展。可以禁止指定用户/角色 对某些字段的访问
举个例子：我有个员工表，B用户能查询5条记录，但看不见记录中工资字段里的数据，C用户也能查询5条记录，但能看到记录中工资字段里的数据，因为C用户是财务部门的人。本文提出了数据权限的一种实现思路，只是本人在做一个web应用时构思的方案，谈不上规范，欢迎提出你的建议意见。
可以在体验实际的应用效果。
用云栖社区APP，舒服~
【云栖快讯】支撑千亿营收，阿里如何做研发？淘宝如何做敏捷实践？如何面对开发中的“黑天鹅”事件？6月29日首届阿里研发效能嘉年华，独家直播，赶紧预约吧！&&
学习了，谢谢
支持MySQL、SQL Server、PostgreSQL、MongoDB、Redis等关系型数据库和NoSQL...
一个稳定可靠的集中式访问控制服务。您可以通过访问控制将阿里云资源的访问及管理权限分配给您的企业成员或合作伙伴。
一款安全易用的管理类服务。您无需花费大量成本来保护密钥的保密性、完整性和可用性，借助密钥管理服务，您可以安全、便...
为您提供简单高效、处理能力可弹性伸缩的计算服务，帮助您快速构建更稳定、安全的应用，提升运维效率，降低 IT 成本...
安全技术百问
Loading...数据库 架构设计
权限设计（初稿）&&&
& 1. 前言：&&&
& 权限管理往往是一个极其复杂的问题，但也可简单表述为这样的逻辑表达式：判断“Who对What(Which)进行How的操作”的逻辑表达式是否为真。针对不同的应用，需要根据项目的实际情况和具体架构，在维护性、灵活性、完整性等N多个方案之间比较权衡，选择符合的方案。&&&
& 2. 目标：&&&
& 直观，因为系统最终会由最终用户来维护，权限分配的直观和容易理解，显得比较重要简单，包括概念数量上的简单和意义上的简单还有功能上的简单。想用一个权限系统解决所有的权限问题是不现实的。设计中将常常变化的“定制”特点比较强的部分判断为业务逻辑，而将常常相同的“通用”特点比较强的部分判断为权限逻辑就是基于这样的思路。&&&
& 3. 现状：&&&
& 对于在企业环境中的访问控制方法，一般有三种：&&&
& 1.自主型访问控制方法：目前在我国的大多数的信息系统中的访问控制模块中基本是借助于自主型访问控制方法中的访问控制列表(ACLs)。&&&
& 2.强制型访问控制方法：用于多层次安全级别的军事应用。&&&
& 3.基于角色的访问控制方法（RBAC）：是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是：1.减小授权管理的复杂性，降低管理开销。2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。&&&
& 4. 名词：&&&
& 粗粒度：表示类别级，即仅考虑对象的类别(the&& type&& of&& object)，不考虑对象的某个特定实例。比如，用户管理中，创建、删除，对所有的用户都一视同仁，并不区分操作的具体对象实例。&&&
& 细粒度：表示实例级，即需要考虑具体对象的实例(the&& instance&& of&& object)，当然，细粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。比如，合同管理中，列表、删除，需要区分该合同实例是否为当前用户所创建。&&&
& 5. 原则：&&&
& 权限逻辑配合业务逻辑。即权限系统以为业务逻辑提供服务为目标。相当多细粒度的权限问题因其极其独特而不具通用意义，它们也能被理解为是“业务逻辑”的一部分。比如，要求：“合同资源只能被它的创建者删除，与创建者同组的用户可以修改，所有的用户能够浏览”。这既可以认为是一个细粒度的权限问题，也可以认为是一个业务逻辑问题。在这里它是业务逻辑问题，在整个权限系统的架构设计之中不予过多考虑。当然，权限系统的架构也必须要能支持这样的控制判断。或者说，系统提供足够多但不是完全的控制能力。即，设计原则归结为：“系统只提供粗粒度的权限，细粒度的权限被认为是业务逻辑的职责”。&&&
& 权限公式：Who+What(Which)+How&& 的问题，在这里我们实现What和部分Which的权限问题(粗粒度和细粒度相合，到一定的程度)，其他的权限问题留给业务逻辑解决&&&
& 6. 概念：&&&
& Who：权限的拥用者或主体（Principal(负责人)、User、Group、Role、Actor等等）&&&
& What：权限针对的对象或资源（Resource、Class）。&&&
& How：具体的权限（Privilege,&& 正向授权与负向授权）。&&&
& Role：是角色，拥有一定数量的权限。&&&
& Operator：操作。表明对What的How&& 操作。&&&
& 7. 解释：&&&
& User：与&& Role&& 相关，用户仅仅是纯粹的用户，权限是被分离出去了的。User是不能与&& Privilege&& 直接相关的，User&& 要拥有对某种资源的权限，必须通过Role去关联。解决&& Who&& 的问题。&&&
& Resource：就是系统的资源，比如部门新闻，文档等各种可以被提供给用户访问的对象。&&&
& Privilege：是Resource&& Related的权限。就是指，这个权限是绑定在特定的资源实例上的。比如说部门新闻的发布权限，叫做&部门新闻发布权限&。这就表明，该Privilege是一个发布权限，而且是针对部门新闻这种资源的一种发布权限。Privilege是由Creator在做开发时就确定的。Privilege&& 如&删除&&& 是一个抽象的名词，当它不与任何具体的&& Object&& 或&& Resource&& 绑定在一起时是没有任何意义的。拿新闻发布来说，发布是一种权限，但是只说发布它是毫无意义的。因为不知道发布可以操作的对象是什么。只有当发布与新闻结合在一起时，才会产生真正的&&
Privilege。这就是&& Privilege&& Instance。&&&
& Role：是粗粒度和细粒度(业务逻辑)的接口，一个基于粗粒度控制的权限框架软件，对外的接口应该是Role，具体业务实现可以直接继承或拓展丰富Role的内容，Role不是如同User或Group的具体实体，它是接口概念，抽象的通称。&&&
& Operator的定义包括了Resource&& Type和Method概念。即，What和How的概念。之所以将What和How绑定在一起作为一个Operator概念而不是分开建模再建立关联，这是因为很多的How对于某What才有意义。比如，发布操作对新闻对象才有意义，对用户对象则没有意义。&&&
& 8. 思想：&&&
& 权限系统的核心由以下三部分构成：1.创造权限，2.分配权限，3.使用权限，然后，系统各部分的主要参与者对照如下：1.创造权限&& -&& Creator创造，2.分配权限&& -&& Administrator&& 分配，3.使用权限&& -&& User：&&&
& 1.&& Creator&& 创造&& Privilege，&& Creator&& 在设计和实现系统时会划分，一个子系统或称为模块，应该有哪些权限。这里完成的是&& Privilege&& 与&& Resource&& 的对象声明，并没有真正将&& Privilege&& 与具体Resource&& 实例联系在一起，形成Operator。&&&
& 2.&& Administrator&& 指定&& Privilege&& 与&& Resource&& Instance&& 的关联。在这一步，&& 权限真正与资源实例联系到了一起，&& 产生了Operator（Privilege&& Instance）。Administrator利用Operator这个基本元素，来创造他理想中的权限模型。如，创建角色，创建用户组，给用户组分配用户，将用户组与角色关联等等...这些操作都是由&& Administrator&& 来完成的。&&&
& 3.&& User&& 使用&& Administrator&& 分配给的权限去使用各个子系统。Administrator&& 是用户，在他的心目中有一个比较适合他管理和维护的权限模型。于是，程序员只要回答一个问题，就是什么权限可以访问什么资源，也就是前面说的&& Operator。程序员提供&& Operator&& 就意味着给系统穿上了盔甲。Administrator&& 就可以按照他的意愿来建立他所希望的权限框架可以自行增加，删除，管理Resource和Privilege之间关系。可以自行设定用户User和角色Role的对应关系。(如果将&&
Creator看作是&& Basic&& 的发明者，&& Administrator&& 就是&& Basic&& 的使用者，他可以做一些脚本式的编程)&& Operator是这个系统中最关键的部分，它是一个纽带，一个系在Programmer，Administrator，User之间的纽带。
但凡涉及多用户不同权限的网络或者单机程序，都会有权限管理的问题，比较突出的是MIS系统。 & &&
& 下面我要说的是MIS系统权限管理的数据库设计及实现，当然，这些思路也可以推广开来应用，比如说在BBS中用来管理不同级别的用户权限。 & &&
& 权限设计通常包括数据库设计、应用程序接口(API)设计、程序实现三个部分。 & &&
& 这三个部分相互依存，密不可分，要实现完善的权限管理体系，必须考虑到每一个环节可行性与复杂程度甚至执行效率。 & &&
& 我们将权限分类，首先是针对数据存取的权限，通常有录入、浏览、修改、删除四种，其次是功能，它可以包括例如统计等所有非直接数据存取操作，另外，我们还可能对一些关键数据表某些字段的存取进行限制。除此，我想不出还有另外种类的权限类别。 & &&
& 完善的权限设计应该具有充分的可扩展性，也就是说，系统增加了新的其它功能不应该对整个权限管理体系带来较大的变化，要达到这个目的，首先是数据库设计合理，其次是应用程序接口规范。 & &&
& 我们先讨论数据库设计。通常我们使用关系数据库，这里不讨论基于Lotus产品的权限管理。 & &&
& 权限表及相关内容大体可以用六个表来描述，如下： & &&
& 1 & 角色（即用户组）表：包括三个字段，ID，角色名，对该角色的描述； & &&
& 2 & 用户表：包括三个或以上字段，ID，用户名，对该用户的描述，其它（如地址、电话等信息）； & &&
& 3 & 角色-用户对应表：该表记录用户与角色之间的对应关系，一个用户可以隶属于多个角色，一个角色组也可拥有多个用户。包括三个字段，ID，角色ID，用户ID； & &&
& 4 & 限制内容列表：该表记录所有需要加以权限区分限制的数据表、功能和字段等内容及其描述，包括三个字段，ID，名称，描述； & &&
& 5 & 权限列表：该表记录所有要加以控制的权限，如录入、修改、删除、执行等，也包括三个字段，ID，名称，描述； & &&
& 6 & 权限-角色-用户对应表：一般情况下，我们对角色/用户所拥有的权限做如下规定，角色拥有明令允许的权限，其它一律禁止，用户继承所属角色的全部权限，在此范围内的权限除明令禁止外全部允许，范围外权限除明令允许外全部禁止。该表的设计是权限管理的重点，设计的思路也很多，可以说各有千秋，不能生搬硬套说某种方法好。对此，我的看法是就个人情况，找自己觉得合适能解决问题的用。 & &&
& 先说第一种也是最容易理解的方法，设计五个字段：ID，限制内容ID，权限ID，角色/用户类型（布尔型字段，用来描述一条记录记录的是角色权限还是用户权限），角色/用户ID，权限类型（布尔型字段，用来描述一条记录表示允许还是禁止） & &&
& 好了，有这六个表，根据表六，我们就可以知道某个角色/用户到底拥有/禁止某种权限。 & &&
& 或者说，这么设计已经足够了，我们完全实现了所需要的功能：可以对角色和用户分别进行权限定制，也具有相当的可扩展性，比如说增加了新功能，我们只需要添加一条或者几条记录就可以，同时应用程序接口也无须改动，具有相当的可行性。但是，在程序实现的过程中，我们发现，使用这种方法并不是十分科学，例如浏览某个用户所拥有的权限时，需要对数据库进行多次（甚至是递归）查询，极不方便。于是我们需要想其它的办法。使用过Unix系统的人们都知道，Unix文件系统将对文件的操作权限分为三种：读、写和执行，分别用1、2、4三个代码标识，对用户同时具有读写权限的文件被记录为3，即1+2。我们也可以用类似的办法来解决这个问题。初步的想法是修改权限列表，加入一个字段：标识码，例如，我们可以将录入权限标识为1，浏览权限标识为2，修改权限标识为4，删除权限标识为8，执行权限标识为16，这样，我们通过权限累加的办法就可以轻易的将原本要分为几条记录描述的权限放在一起了，例如，假定某用户ID为1，库存表对应的限制内容ID为2，同时规定角色类型为0、用户类型为1，我们就可以将该用户具有录入、浏览、修改、删除库存表的权限描述为：2,15,1,1。
& 确实很简单，不是吗？甚至还有更过激的办法，将限制内容列表也加上一列，定义好标识码，这样，我们甚至可以用简单的一条记录描述某个用户具有的对全部内容所具有的全部权限了。当然，这样做的前提是限制内容数量比较小，不然，呵呵，2的n次方递增起来可是数量惊人，不容易解析的。 & &&
& 从表面上看，上述方法足以达到实现功能、简化数据库设计及实现的复杂度这个目的，但这样做有个弊端，我们所涉及的权限列表不是相互独立而是互相依赖的，比如说修改权限，其实是包含浏览权限的，例如，我们可能只是简单的设置用户对库存表存取的权限值为录入+修改+删除（1+4+8=13),但事实上，该用户具有(1+2+4+8=15）的权限，也就是说，在这种方案中，13=15。于是当我们调用API询问某用户是否具有浏览权限时，就必须判断该用户是否具有对该数据表的修改权限，因此，如果不能在程序中固化权限之间的包含关系，就不能利用应用程序接口简单的做出判断。但这与我们的目的“充分的可扩展性”矛盾。
& 这个问题如何解决？我想到了另外一种设置标识码的方法，那就是利用素数。我们不妨将录入、浏览、修改、删除、执行的基本标志码定为2,3,5,7,11，当遇到权限互相包含的时候，我们将它的标识码设定为两个（或多个）基本标志码的乘积，例如，可以将“修改”功能的标志码定为3*5=15，然后将所有的权限相乘，就得到了我们需要的最终权限标识值。这样，我们在询问用户是否具有某项权限的时候，只需要将最终的值分解成质因子，例如，我们可以定义一个用户具有录入+修改+删除库存表的权限为 & 2*15*7=2*3*5*7，即表示，该用户具有了对库存表录入+浏览+修改+删除权限。
& 当然，对权限列表我们使用上述方法的前提是权限列表记录条数不会太多并且关系不是十分复杂，否则，光是解析权限代码就要机器忽悠半宿：） &
通用权限管理设计篇&&
&&&&&& 因为做过的一些系统的权限管理的功能虽然在逐步完善，但总有些不尽人意的地方，总想抽个时间来更好的思考一下权限系统的设计。
&&&&&& 权限系统一直以来是我们应用系统不可缺少的一个部分，若每个应用系统都重新对系统的权限进行设计，以满足不同系统用户的需求，将会浪费我们不少宝贵时间，所以花时间来设计一个相对通用的权限系统是很有意义的。
二．设计目标
&&&&&& 设计一个灵活、通用、方便的权限管理系统。
&&&&&& 在这个系统中，我们需要对系统的所有资源进行权限控制，那么系统中的资源包括哪些呢？我们可以把这些资源简单概括为静态资源（功能操作、数据列）和动态资源（数据），也分别称为对象资源和数据资源，后者是我们在系统设计与实现中的叫法。
系统的目标就是对应用系统的所有对象资源和数据资源进行权限控制，比如应用系统的功能菜单、各个界面的按钮、数据显示的列以及各种行级数据进行权限的操控。
三．相关对象及其关系
&&&&&& 大概理清了一下权限系统的相关概念，如下所示：
1.&&&&&& 权限
系统的所有权限信息。权限具有上下级关系，是一个树状的结构。下面来看一个例子
&&&&&&& 用户管理
&&&&&&& &&&&&& 查看用户
&&&&&&&&&&&&&&& 新增用户
&&&&&&&&&&&&&&&&&&&& 修改用户
&&&&&&&&&&&&&&&&&&&& 删除用户
&&&&&& 对于上面的每个权限，又存在两种情况，一个是只是可访问，另一种是可授权，例如对于“查看用户”这个权限，如果用户只被授予“可访问”，那么他就不能将他所具有的这个权限分配给其他人。
2.&&&&&& 用户
应用系统的具体操作者，用户可以自己拥有权限信息，可以归属于0～n个角色，可属于0～n个组。他的权限集是自身具有的权限、所属的各角色具有的权限、所属的各组具有的权限的合集。它与权限、角色、组之间的关系都是n对n的关系。
3.&&&&&& 角色
为了对许多拥有相似权限的用户进行分类管理，定义了角色的概念，例如系统管理员、管理员、用户、访客等角色。角色具有上下级关系，可以形成树状视图，父级角色的权限是自身及它的所有子角色的权限的综合。父级角色的用户、父级角色的组同理可推。
4.&&&&&& 组
为了更好地管理用户，对用户进行分组归类，简称为用户分组。组也具有上下级关系，可以形成树状视图。在实际情况中，我们知道，组也可以具有自己的角色信息、权限信息。这让我想到我们的QQ用户群，一个群可以有多个用户，一个用户也可以加入多个群。每个群具有自己的权限信息。例如查看群共享。QQ群也可以具有自己的角色信息，例如普通群、高级群等。
针对上面提出的四种类型的对象，让我们通过图来看看他们之间的关系。
&&&&有上图中可以看出，这四者的关系很复杂，而实际的情况比这个图还要复杂，权限、角色、组都具有上下级关系，权限管理是应用系统中比较棘手的问题，要设计一个通用的权限管理系统，工作量也着实不小。
当然对于有些项目，权限问题并不是那么复杂。有的只需要牵涉到权限和用户两种类型的对象，只需要给用户分配权限即可。
在另一些情况中，引入了角色对象，例如基于角色的权限系统， 只需要给角色分配权限，用户都隶属于角色，不需要单独为用户分配角色信息。
通用权限管理设计篇（二）——数据库设计
&& 国庆前整的通用权限设计的数据库初步设计部分，现在贴上来。
理清了对象关系之后，让我们接着来进行数据库的设计。在数据库建模时，对于N对N的
关系，一般需要加入一个关联表来表示关联的两者的关系。初步估计一下，本系统至少需要十张表，分别为：权限表、用户表、角色表、组表、用户权限关联表、用
户角色关联表、角色权限关联表、组权限关联表、组角色关联表、用户属组关联表。当然还可能引出一些相关的表。下面让我们在PowerDesigner中画出各表吧。
&&&&&& 各表及其关系如下：
1.&&&&&& 用户表
用户表（TUser）
pk, not null
fk, not null
login_name
varchar(64)
varchar(64)
varchar(64)
varchar(20)
varchar(64)
login_time
上次登录时间
last_login_time
2.&&&&&& 角色表
角色表（TRole）
pk, not null
父级角色ID
parent_tr_id
varchar(64)
description
varchar(200)
3.&&&&&& 权限表
权限表（TRight）
pk, not null
parent_tr_id
right_name
varchar(64)
description
varchar(200)
4.&&&&&& 组表
组表（TGroup）
pk, not null
group_name
varchar(64)
parent_tg_id
description
varchar(200)
5.&&&&&& 角色权限表
角色权限表（TRoleRightRelation）
pk, not null
fk, not null
fk, not null
right_type
not null（0:可访问，1:可授权）
6.&&&&&& 组权限表
组权限表（TGroupRightRelation）
pk, not null
fk, not null
fk, not null
right_type
not null（0:可访问，1:可授权）
7.&&&&&& 组角色表
组角色表（TGroupRoleRelation）
pk, not null
fk, not null
pk, not null
8.&&&&&& 用户权限表
用户权限表（TUserRightRelation）
pk, not null
fk, not null
fk, not null
right_type
not null（0:可访问，1:可授权）
9.&&&&&& 用户角色表
用户角色表（TUserRoleRelation）
pk, not null
fk, not null
fk, not null
10.&& 用户组表
用户组表（TUserGroupRelation）
pk, not null
fk, not null
fk, not null
11.&& 组织表
组织表（TOrganization）
pk, not null
parent_to_id
varchar(64)
description
varchar(200)
12.&& 操作日志表
操作日志表（TLog）
pk, not null
varchar(200)
fk, not null
通用权限管理系统设计篇（三）——概要设计说明书
&在前两篇文章中，不少朋友对我的设计提出了异议，认为过于复杂，当然在实际的各种系统的权限管理模块中，并不像这里设计得那么复杂，我以前所做的系统中，
由只有用户和权限的，有只有用户、权限和角色的，还有一个系统用到了用户、权限、角色、组概念，这个系统是我在思考以前所做系统的权限管理部分中找到的一
些共性而想到的一个设计方案，当然还会有不少设计不到位的地方，在设计开发过程中会慢慢改进，这个系统权当学习只用，各位朋友的好的建议我都会考虑到设计
中，感谢各位朋友的支持。
&&& 今天抽时间整了一份概念设计出来，还有一些地方尚未考虑清楚，贴出1.0版，希望各位朋友提出宝贵建议。
&&& 大家也可以点击此处自行下载，这是1.0版本，有些地方可能还会进行部分修改，有兴趣的朋友请关注我的blog。
1.&&&&& 引言
1.1 编写目的
本文档对通用权限管理系统的总体设计、接口设计、界面总体设计、数据结构设计、系统出错处理设计以及系统安全数据进行了说明。
a、&软件系统的名称：通用权限管理系统；
b、&任务提出者、开发者：谢星星；
c、&在J2EE的web系统中需要使用权限管理的系统。
本系统：通用权限管理系统；
SSH：英文全称是Secure Shell。
1.4 预期读者与阅读建议
总体设计、接口设计、数据结构设计、界面总体设计、系统出错处理设计
总体设计、接口设计、数据结构设计、系统安全设计
1.5 参考资料
《通用权限管理系统需求规格说明书》
《通用权限管理系统数据库设计说明书》
2.&&&&& 总体设计
2.1 设计目标
权限系统一直以来是我们应用系统不可缺少的一个部分，若每个应用系统都重新对系统的权限进行设计，以满足不同系统用户的需求，将会浪费我们不少宝贵时间，所以花时间来设计一个相对通用的权限系统是很有意义的。
本系统的设计目标是对应用系统的所有资源进行权限控制，比如应用系统的功能菜单、各个界面的按钮控件等进行权限的操控。
2.2 运行环境
操作系统：Windows系统操作系统和Linux系列操作系统。
2.3 网络结构
&通用权限管理系统可采用Java Swing实现，可以在桌面应用和Web应用系统中进行调用。如果需要要适应所有开发语言，可以将其API发布到WEB Service上。暂时用Java Swing实现。
2.4 总体设计思路和处理流程
在说明总体设计思路前，我们先说明本系统的相关概念：
1. 权限资源
系统的所有权限信息。权限具有上下级关系，是一个树状的结构。下面来看一个例子
&&&&&&& 用户管理
&&&&&&& &&&&&& 查看用户
&&&&&&&&&&&&&&&新增用户
&&&&&&&&&&&&&&&修改用户
&&&&&&&&&&&&&&&删除用户
对于上面的每个权限，又存在两种情况，一个是只是可访问，另一种是可授权，例如对于“查看用户”这个权限，如果用户只被授予“可访问”，那么他就不能将他所具有的这个权限分配给其他人。
应用系统的具体操作者，用户可以自己拥有权限信息，可以归属于0～n个角色，可属于0～n个组。他的权限集是自身具有的权限、所属的各角色具有的权限、所属的各组具有的权限的合集。它与权限、角色、组之间的关系都是n对n的关系。
为了对许多拥有相似权限的用户进行分类管理，定义了角色的概念，例如系统管理员、管理员、用户、访客等角色。角色具有上下级关系，可以形成树状视图，父级角色的权限是自身及它的所有子角色的权限的综合。父级角色的用户、父级角色的组同理可推。
了更好地管理用户，对用户进行分组归类，简称为用户分组。组也具有上下级关系，可以形成树状视图。在实际情况中，我们知道，组也可以具有自己的角色信息、
权限信息。这让我想到我们的QQ用户群，一个群可以有多个用户，一个用户也可以加入多个群。每个群具有自己的权限信息。例如查看群共享。QQ群也可以具有
自己的角色信息，例如普通群、高级群等。
针对如上提出的四种对象，我们可以整理得出它们之间的关系图，如下所示：
总体设计思路是将系统分为组权限管理、角色权限管理、用户权限管理、组织管理和操作日志管理五部分。
其中组权限管理包括包含用户、所属角色、组权限资源和组总权限资源四部分，某个组的权限信息可用公式表示：组权限 = 所属角色的权限合集 + 组自身的权限。
角色权限管理包括包含用户、包含组和角色权限三部分，某个角色的权限的计算公式为：角色权限 = 角色自身权限。
用户权限管理包括所属角色、所属组、用户权限、用户总权限资源和组织管理五部分。某个用户总的权限信息存在如下计算公式：用户权限 = 所属角色权限合集 + 所属组权限合集 + 用户自身权限。
组织管理即对用户所属的组织进行管理，组织以树形结构展示，组织管理具有组织的增、删、改、查功能。
操作日志管理用于管理本系统的操作日志。
注意：因为组和角色都具有上下级关系，所以下级的组或角色的权限只能在自己的直属上级的权限中选择，下级的组或者角色的总的权限都不能大于直属上级的总权限。
2.5 模块结构设计
本系统的具有的功能模块结构如下图所示：
2.6 尚未解决的问题
3.&&&&& 接口设计（暂略）
3.1 用户接口（暂略）
3.2 外部接口（暂略）
3.3 内部接口（暂略）
4.&&&&& 界面总体设计
本节将阐述用户界面的实现，在此之前对页面元素做如下约定：
未选中时：[按钮名称]
选中时：[按钮名称]
&[选项,…,] ▽
&|________|
&|…………|
未选中时：选项名称
&选中时：选项名称
未选中链接
4.1 组权限管理
4.1.1包含用户
&&&&&& 组11
&&&&&& 组12
&&&&&& 组…
&&&&&& 组21
&&&&&& 组22
&&&&&& 组…
所选择组：组1
[包含用户] [所属角色] [组权限] [总权限]
用户名&& 姓名&&&& 手机号&& 最近登录时间&登录次数
阿蜜果&谢星星&&&&& 66
sterning xxx&&& &&&& 10&
当用户选择“修改”按钮时，弹出用户列表，操作人可以通过勾选或取消勾选来修改该组所包含的用户。
4.1.2所属角色
&&&&&& 组11
&&&&&& 组12
&&&&&& 组…
&&&&&& 组21
&&&&&& 组22
&&&&&& 组…
所选择组：组1
[包含用户] [所属角色] [组权限] [总权限]
角色ID&& 角色名称&& 角色描述
1&&&&&&&&& 访客&&&&&& --
&& 2&&&&&&&& 初级用户&&& --
当用户选择“修改”按钮时，弹出角色树形结构，操作人可以通过勾选或取消勾选来修改该组所属的角色。
4.1.3组权限
&&&&&& 组11
&&&&&& 组12
&&&&&& 组…
&&&&&& 组21
&&&&&& 组22
&&&&&& 组…
所选择组：组1
[包含用户] [所属角色] [组权限] [总权限]
&&&&&&&&&&&&&&& [保存] [取消]
4.1.4总权限
&&&&&& 组11
&&&&&& 组12
&&&&&& 组…
&&&&&& 组21
&&&&&& 组22
&&&&&& 组…
所选择组：组1
[包含用户] [所属角色] [组权限] [总权限]
&&&&&&&&&&&&&&& [保存] [取消]
通过对已具有的权限取消勾选，或为某权限添加勾选，来修改组的权限信息，点击“保存”按钮保存修改信息。
4.1.5组管理
&&&&&& 在下图中，选中组1的时候，右键点击可弹出组的操作列表，包括添加、删除和修改按钮，从而完成在该组下添加子组，删除该组以及修改该组的功能。
&&&&&& 组11
&&&&&& 组12
&&&&&& 组…
&&&&&& 组21
&&&&&& 组22
&&&&&& 组…
所选择组：组1
[包含用户] [所属角色] [组权限] [总权限]
用户名&& 姓名&&&& 手机号&& 最近登录时间&登录次数
阿蜜果&谢星星&&&&& 66
sterning xxx&&& &&&& 10&
4.2 角色权限管理
4.2.1包含用户
&&&&&& 角色11
&&&&&& 角色12
&&&&&& 角色…
&&&&&& 角色21
&&&&&& 角色22
&&&&&& 角色…
所选择角色：角色1
[包含用户] [包含组] [角色权限]
用户名&& 姓名&&&& 手机号&& 最近登录时间&登录次数
阿蜜果&谢星星&&&&& 66
sterning xxx&&& &&&& 10&
当用户选择“修改”按钮时，弹出用户列表，操作人可以通过勾选或取消勾选来修改该角色所包含的用户。
4.2.2包含组
&&&&&& 角色11
&&&&&& 角色12
&&&&&& 角色…
&&&&&& 角色21
&&&&&& 角色22
&&&&&& 角色…
所选择角色：角色1
[包含用户] [包含组] [角色权限]
组ID&& 组名称&&&& 组描述
1&&&&&&xxx1&&&&&&&--
2 &&&&&&xxx2&&& &&&&--&
当用户选择“修改”按钮时，弹出用户列表，操作人可以通过勾选或取消勾选来修改该角色所包含的组。
4.2.3角色权限
&&&&&& 角色11
&&&&&& 角色12
&&&&&& 角色…
&&&&&& 角色21
&&&&&& 角色22
&&&&&& 角色…
所选择角色：角色1
[包含用户] [包含组] [角色权限]
&&&&&&&&&&&&&&&&&
&&&&&&&&&&&&&&&[保存] [取消]
通过对已具有的权限取消勾选，或为某权限添加勾选，来修改角色的权限信息，点击“保存”按钮保存修改信息。
4.2.4管理角色
&&&&&& 在下图中，选中组1的时候，右键点击可弹出组的操作列表，包括添加、删除和修改按钮，从而完成在该组下添加子组，删除该组以及修改该组的功能。
&&&&&& 角色11
&&&&&& 角色12
&&&&&& 角色…
&&&&&& 角色21
&&&&&& 角色22
&&&&&& 角色…
所选择角色：角色1
[包含用户] [包含组] [角色权限]
用户名&& 姓名&&&& 手机号&& 最近登录时间&登录次数
阿蜜果&谢星星&&&&& 66
sterning xxx&&& &&&& 10&
4.3 用户权限管理
4.3.1所属角色
用户权限信息
&& 广州分公司
&&&&&& 阿蜜果
&&&&&& 肖xx
&&&&&& yy…
&& 北京分公司
&&&&&& zz1
&&&&&& zz2
&&&&&& zz3…
所选择用户：阿蜜果
[所属角色] [所属组] [用户权限] [总权限]
角色ID&& 角色名称&& 角色描述
1&&&&&&&&& 访客&&&&&& --
&& 2&&&&&&&& 初级用户&&& --
当用户选择“修改”按钮时，弹出角色树形结构，操作人可以通过勾选或取消勾选来修改该用户所属的角色。
4.3.2所属组
&& 广州分公司
&&&&&& 阿蜜果
&&&&&& 肖xx
&&&&&& yy…
&& 北京分公司
&&&&&& zz1
&&&&&& zz2
&&&&&& zz3…
所选择用户：阿蜜果
[所属角色] [所属组] [用户权限] [总权限]
组ID&& 组名称&&&& 组描述
1&&&&&& 组1&&&&&&&& --
&& 2&&&&&& 组2&&&&&&&& --
当用户选择“修改”按钮时，弹出组的树形结构，操作人可以通过勾选或取消勾选来修改该用户所属的组。
4.3.3用户权限
&& 广州分公司
&&&&&& 阿蜜果
&&&&&& 肖xx
&&&&&& yy…
&& 北京分公司
&&&&&& zz1
&&&&&& zz2
&&&&&& zz3…
所选择用户：阿蜜果
[所属角色] [所属组] [用户权限] [总权限]
&&&&&&&&&&&&&&&&&
&&&&&&&&&&&&&&&&[保存] [取消]
通过对已具有的权限取消勾选，或为某权限添加勾选，来修改用户的权限信息，点击“保存”按钮保存修改信息。
4.3.4总权限
&& 广州分公司
&&&&&& 阿蜜果
&&&&&& 肖xx
&&&&&& yy…
&& 北京分公司
&&&&&& zz1
&&&&&& zz2
&&&&&& zz3…
所选择用户：阿蜜果
[所属角色] [所属组] [用户权限] [总权限]
&&&&&&&&&&&&&&&&&
&&&&&&&&&&&&&&&&[保存] [取消]
通过对已具有的权限取消勾选，或为某权限添加勾选，来修改用户的权限信息，点击“保存”按钮保存修改信息。
4.3.5用户管理
&&&&&& 当选择了某用户时，点击右键，弹出菜单列表：修改、删除、取消，点击修改和删除按钮可以实现用户的删除和修改功能。
&&&&&& 选择某个组织，例如下表中的“广州分公司”，弹出菜单列表：添加子组织、删除组织、修改组织、添加用户、取消，点击添加用户按钮可以实现用户的添加功能。
用户权限信息
&& 广州分公司
&&&&&& 阿蜜果
&&&&&& 肖xx
&&&&& &yy…
&& 北京分公司
&&&&&& zz1
&&&&&& zz2
&&&&&& zz3…
所选择用户：阿蜜果
[所属角色] [所属组] [用户权限] [总权限]
角色ID&& 角色名称&& 角色描述
1&&&&&&&&& 访客&&&&&& --
&& 2&&&&&&&& 初级用户&&& --
4.3.6组织管理
&&&&&& 选择某个组织，例如下表中的“广州分公司”，弹出菜单列表：添加子组织、删除组织、修改组织、添加用户、取消，点击添加子组织、删除组织、修改组织按钮可以实现组织的添加、删除和修改功能。
用户权限信息
&& 广州分公司
&&&&&& 阿蜜果
&&&&&& 肖xx
&&&&&& yy…
&& 北京分公司
&&&&&& zz1
&&&&&& zz2
&&&&&& zz3…
所选择用户：阿蜜果
[所属角色] [所属组] [用户权限] [总权限]
角色ID&& 角色名称&& 角色描述
1&&&&&&&&& 访客&&&&&& --
&& 2&&&&&&&& 初级用户&&& --
4.4 操作日志管理
4.4.1查询操作日志
操作名称：|________| &操作人：|________|
操作时间从&|________| 到 |________|&[查询] [重置] [删除]
编号&& &操作名称&& &操作内容&& &操作人&& &操作时间
1&&&&&&& xx1&&&&&& &&--&&&&&&& Amigo&& &
2&&&&&&& xx2&&& &&&&&--&&&&&&& xxyy&& &&
输入上图表单中的查询信息后，点击“查询”按钮，可查询出符合条件的信息。
4.4.2删除操作日志
操作名称：|________|&操作人：|________|
操作时间从&|________| 到 |________|&[查询] [重置] [删除]
编号&& &操作名称&&& 操作内容&&& 操作人&&& 操作时间
1&&&&&&& xx1&&&&&& --&&&&&&&&&& Amigo&&&&&
2&&&&&&& xx2&&&&&& --&&&&&&&&&& xxyy&&&&&&
输入上图表单中的查询信息后，点击“查询”按钮，可查询出符合条件的信息。而后点击“删除”按钮，可删除符合查询条件的操作日志。
5.&&&&& 数据结构设计
数据库设计的模型请参见《通用权限管理系统_数据库模型.pdm》。表的说明请参见《通用权限管理系统数据库设计说明书》。
5.1 设计原则
5.1.1命名的规范
数据库中表、主键、外键、索引的命名都以统一的规则，采用大小写敏感的形式，各种对象命名长度不要超过30个字符，这样便于应用系统适应不同的数据库平台。
5.1.2数据的一致性和完整性
为了保证数据库的一致性和完整性，往往通过表间关联的方式来尽可能的降低数据的冗余。表间关联是一种强制性措施，建立后，对父表（Parent Table）和子表(Child Table)的插入、更新、删除操作均要占用系统的开销。如果数据冗余低，数据的完整性容易得到保证，但增加了表间连接查询的操作，为了提高系统的响应时间，合理的数据冗余也是必要的。使用规则（Rule）和约束（Check）来防止系统操作人员误输入造成数据的错误是设计人员的另一种常用手段，但是，不必要的规则和约束也会占用系统的不必要开销，需要注意的是，约束对数据的有效性验证要比规则快。所有这些，需要在设计阶段应根据系统操作的类型、频度加以均衡考虑。
5.2 数据库环境说明
数据库：MySql5.0
设计库建模工具：PowerDesigner12.0
5.3 数据库命名规则
表名以T开头，外键以FK开头，索引以INDEX开头。
5.4 逻辑结构
pdm文件的名称为：《通用权限管理系统_数据库模型》。
5.5 物理存储
通过数据库建模工具PowerDesigner12可以将pdm导出为文本文件，将数据库脚本放入文本文件中保存。
5.6 数据备份和恢复
数据库需定期备份（每天备份一次），备份文件格式为backup_yyyyMMdd，数据库被破坏时，利用最新的备份文件进行恢复。
6.&&&&& 系统出错处理设计
6.1 出错信息
子项及其编码
数据库错误
数据库本身错误代码
数据库本身错误代码
;数据库错误代码
TCP连接错误
其它TCP连接错误(socket自身错误代码)
; socket错误代码
配置信息错误
未配置输入参数
未配置输出参数
组管理部分自定义错误
103001——103999
角色管理部分自定义错误
104001——104999
用户管理部分自定义错误
105001——105999
操作日志管理
106001——106999
6.2 补救措施
为了当某些故障发生时，对系统进行及时的补救，提供如下补救措施：
a．后备技术&& 定期对数据库信息进行备份（每天一次），当数据库因某种原因被破坏时，以最新的数据库脚本进行恢复；。
7.&&&&& 系统安全设计
7.1 数据传输安全性设计
SSH可以通过将联机的封包加密的技术进行资料的传递; 使用SSH可以把传输的所有数据进行加密，即使有人截获到数据也无法得到有用的信息。同时数据经过压缩，大大地加快了传输的速度。通过SSH的使用，可以确保资料传输比较安全并且传输效率较高。
7.2 应用系统安全性设计
操作人的操作信息需要提供操作记录。对系统的异常信息需进行记录，已备以后查看。只有授权用户才能登录系统，对于某个操作，需要具有相应权限才能进行操作。
7.3 数据存储安全性设计&&&&&&&&&&&
对于用户的密码等敏感信息采用MD5进行加密。
OA之权限管理
权限管理自己做完了，但是很多的研究和总结，现在就来总结一下权限管理。
第一、数据库中主要类：
主要负责类：用户（User），角色（Role）、资源（module）和操作（Permission）
衍生类：用户角色（UserRole）和对某个资源的某个操作（ACL）
第二、ACL的具体理解：
一条acl授权记录中主要记录了以下信息:&角色、资源和授权&
授权作为一个int, 每一位是一个操作的权限.&
假设从右向左, 分别代表CRUD&
那么, 我们CRUD的代码就应该是0123(也就是移位时要移的位数), 因为我们要进行移位进行认证。
先看授权与取消授权的代码：
首先, 一个int temp = 1的临时变量, aclState为原始授权状态
tmp的二进制表示是: 00 &
U对应的代码是U, 对应的是2.&
将tmp左移2位, temp = tmp & & 2; temp变成:00 &
假设原始授权是aclState=00 &
当变量yes=true时，为授权，将temp与aclState求|运算，因为temp现在只有他要授权的位为1，求或运算后，
aclState=00 ，这样就授权成功
当变量yes=false时，为取消授权，先将temp取反，即为11 ，
现在只有要取消权限的位为0，其余全为1，然后与aclState求&运算，则除了要取消权限的位变0，其余的都不变，
即aclState=00
再来看认证：
认证更简单，直接将temp变量与aclState求&，temp为1的位为要验证的权限，其余全为0，如果aclState的这一位为1，则结果不为零，即有该权限；若aclState这一位为0，即没权限，则结果为0，没有该操作权限
总结：权限管理最难理解的就是CRUD中的数据得来，至于别的我们可以关系，我们还是可以清晰的理解，还有一个概念就是集成的概念：
a)&&&&&&&&针对某个资源的所有操作，我们可以设置这些权限对用户来说是“继承”或“不继承”
&&&&&&&&&&&&&&&&&&&&&&&&i.&&&&&&&&&&&&&继承：意思是这些权限将使用其（即用户）所拥有的角色的权限，而不使用其（即用户）单独设置的权限
&&&&&&&&&&&&&&&&&&&&&&ii.&&&&&&&&&&&&&不继承：意思是这些权限将使用其单独设置的权限，而不使用其所拥有的角色的权限
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1693次
排名：千里之外}