关于用户权限的数据库设计.docx

最近项目的项目很奇怪，一个大项目(系统)里包含了很多小的子系统，而这些子系统中都有权限控制的部分，这件事情挺让我头痛的，记得一年前在沈阳，我曾经有一段时间也因因这个问题而疲于奔命，为什么说疲于奔命呢？由于当时项目进度不允许，导致最终系统权限模块草草了事，每个模块都是由读权限字符串来控制用户ACL，当用户无法访问时，提示权限不够。这么做对用户是很不负责任的，既然让用户看到了操作的方式和界面，为什么又告诉用户没有权限呢？我开始怀疑我们是否应该在底层就封杀用户的访问权限。 现在项目开展起来了，虽然目前我已经有了对权限控制的一套方案，并且实施成了我的可重用框架代码，虽然目前的权限也是基于众星捧月的AOP思想，但我至今对权限设计仍有两个疑惑： 疑惑一：很多同行提出方案，想要在底层就截取用户权限，控制用户对方法或者类的访问。这样做的好处在于可以将系统功能与业务逻辑松散耦合，并且实现简单，结构清晰，三两个advisor、filter，或者acegi就能搞定，但在web程序中体现出了他的劣势，当我们将用户的访问拒绝在业务逻辑之外的时候，我们此时是否应该抛出异常提示用户？一旦提示用户没有相应的权限，我认为对于用户来说，这就不是一个perfect practice。由此得出，我们根本就不应该让用户做此次操作，而控制用户操作的源头就是界面，也就是说，在界面上我们就应该对用户的权限元素(如添加按钮、功能菜单等)进行控制。此时，一对矛盾出现了，要控制界面上形形色色的元素只有两种办法，一，将权限与你的界面结合起来设计，这将违背AOP的思想，也使得系统控制模块的重用性大大下降，二，我们借鉴primeton的想法，将权限控制的理念抽取出来，单独做成一套权限系统，解决你所有的需要权限控制的系统需求，这样也有令人头痛的问题，你的所有想用它来控制权限的系统，必须界面上统一风格。或许这样的方式对商业web系统是合适的，毕竟需要你大刀阔斧个性化的地方不多，但我们却很难保证在未来几年内商业web系统的风格不改变。再者，开发这么一个系统也不是一蹴而就的事，在这个问题上一直让我困惑不已。疑惑二：大多应用的权限判定是基于权限字符串的，但存储在数据库中的权限字符串能够判定的权限并不多，在我们这次项目中，我引用了基于二进制的8421权限判定法则，我深深的感觉到权限字符串的弱势，这使我想起了中国古老一套数学理论-“盈不足术”，超递增序列的魅力在我眼前滑过， 首先我来解释一下盈余不足理论：有十只盒子，第一个盒子里放一个盘子，第二个盒子里放两只，第三个盒子里放四只，第四个盒子里放八只第九个盒子里放256只，第十个盒子放512只，即第N只箱子里放2(N-1)只盘子，一共1023只。那么命题如下：在1023这个数字之内，任何一个数目都可以由这十只盒子里的几只组合相加而成。那么1、2、4、8、16、32、64、128、256、512这个序列为什么有这么个魔力？这个数列的特点：1、每项是后一项的二倍，2、每项都比前面所有项的和大，而且大1。这个1就是关键，就因为这个1，它才可以按 1递增，拼出总和之内任意一个整数。这个序列叫做超递增序列，它是解决背包问题的基础。3、拼出总和之内任意一个整数可以由这个序列中的一些数构成，且构成方法唯一，据说是密码学中的NP定理。譬如说这个数列总合中20这个数，只能由16+4一种方法构成，由此延伸出来，如果综合中这个数据代表一个权值，我们可以解出它的所有构成参数（操作），如20这个数据，我们可以挨个和序列中每一项按位与，得出来如果不等于0，就说明他是由这个数构成的。 保存权值到int还是varchar对于我们来说是个问题，当然，保存字符串的好处是运算压力小。我们可能听过一个故事，就是把这个超递增序列延伸到第64 项，就是那个术士和皇帝在国际象棋棋盘上要米粒的传说。64项的和是一个天文数字！但计算机本身就是一个只认识二进制的机器！很多程序员整天只关心架构，甚至不知道或者不关心位操作是什么玩意，当然我们有朋友担心数据库的int不够长，那么既然可以保存一个只有0、1组成的varchar字符串，为什么不能保存一个十六进制的字符串，有人规定varchar只能保存01吗？十六进制串的长度正好是二进制的四分之一。 由此我们可以无限制的扩展权值操作。 在最近的项目里，我对权限的控制分成两个部分，第一就是用户体验上，我设置了一个权限标签，从数据库中抽取权限信息，然后做到标签里，也凑或算成是界面 AOP了，第二就是底层的拦截，用了Spring 的AOP，为的是防止权限冲突，双管齐下。暂时解决权限所需，另外在算法上我用了16进制的权限判别代码，虽然配置较麻烦，写完代码还要写文档说明，不过也解决了权限繁杂又多的问题，暂时就这样了，嘿嘿，以后有空再研究。用户认证管理设计方案 1 设计思路为了设计一套具有较强可扩展性的用户认证管理，需要建立用户、角色和权限等数据库表，并且建立之间的关系，具体实现如下。1.1 用户用户仅仅是纯粹的用户，用来记录用户相关信息，如用户名、密码等，权限是被分离出去了的。用户（User）要拥有对某种资源的权限，必须通过角色（Role）去关联。用户通常具有以下属性： 编号，在系统中唯一。 名称，在系统中唯一。 用户口令。 注释，描述用户或角色的信息。1.2 角色角色是使用权限的基本单位，拥有一定数量的权限，通过角色赋予用户权限，通常具有以下属性： 编号，在系统中唯一。 名称，在系统中唯一。 注释，描述角色信息1.3 权限 权限指用户根据角色获得对程序某些功能的操作，例如对文件的读、写、修改和删除功能，通常具有以下属性： 编号，在系统中唯一。 名称，在系统中唯一。 注释，描述权限信息1.4 用户与角色的关系一个用户（User）可以隶属于多个角色（Role），一个角色组也可拥有多个用户，用户角色就是用来描述他们之间隶属关系的对象。用户（User）通过角色（Role）关联所拥有对某种资源的权限，例如l 用户（User）：UserID UserName UserPwd1 张三 xxxxxx2 李四 xxxxxx l 角色（Role）：RoleID RoleName RoleNote 01 系统管理员 监控系统维护管理员 02 监控人员 在线监控人员 03 调度人员 调度工作人员 04 一般工作人员 工作人员 l 用户角色（User_Role）：UserRoleID UserID RoleID UserRoleNote1 1 01 用户“张三”被分配到角色“系统管理员”2 2 02 用户“李四”被分配到角色“监控人员”3 2 03 用户“李四”被分配到角色“调度人员” 从该关系表可以看出，用户所拥有的特定资源可以通过用户角色来关联。1.5 权限与角色的关系一个角色（Role）可以拥有多个权限（Permission），同样一个权限可分配给多个角色。例如：l 角色（Role）：RoleID RoleName RoleNote 01 系统管理员 监控系统维护管理员 02 监控人员 在线监控人员 03 调度人员 调度工作人员 04 一般工作人员 工作人员 l 权限（Permission）：PermissionID PermissionName PermissionNote0001 增加监控 允许增加监控对象0002 修改监控 允许修改监控对象0003 删除监控 允许删除监控对象0004 察看监控信息 允许察看监控对象l 角色权限（Role_Permission）：RolePermissionID RoleIDPermissionIDRolePermissionNote1 01 0001 角色“系统管理员”具有权限“增加监控”2 01 0002 角色“系统管理员”具有权限“修改监控”3 01 0003 角色“系统管理员”具有权限“删除监控”4 01 0004 角色“系统管理员”具有权限“察看监控”5 02 0001 角色“监控人员”具有权限“增加监控”6 02 0004 角色“监控人员”具有权限“察看监控” 由以上例子中的角色权限关系可以看出，角色权限可以建立角色和权限之间的对应关系。1.6 建立用户权限用户权限系统的核心由以下三部分构成：创造权限、分配权限和使用权限。第一步由Creator创造权限（Permission），Creator在设计和实现系统时会划分。利用存储过程CreatePermissionInfo（PermissionName,PermissionNote）创建权限信息，指定系统模块具有哪些权限。第二步由系统管理员（Administrator）创建用户和角色，并且指定用户角色（UserRole）和角色权限（RolePermission）的关联关系。1) 具有创建用户、修改用户和删除用户的功能： Administratorl 存储过程CreateUserInfo（UserName,UserPwd）创建用户信息；l 存储过程ModifyUserInfo（UserName,UserPwd）修改用户信息；l 存储过程DeleteUserInfo（UserID）删除用户信息；2) 具有创建角色和删除角色的功能： Administratorl 存储过程CreateRoleInfo（RoleName,RoleNote）创建角色信息；l 存储过程DeleteRoleInfo(RoleID)删除角色信息；3）Administrator具有建立用户和角色、角色和权限的关联关系功能：l 存储过程GrantUserRole（UserID,RoleID,UserRoleNote）建立用户和角色的关联关系；l 存储过程DeleteUserRole(UserRoleID)删除用户和角色的关联关系；l 存储过程GrantRolePermission(RoleID,PermissionID,RolePermissionNote)建立角色和权限的关联关系；l 存储过程DeleteRolePermission(RolePermissionID)删除角色和权限的关联关系；第三步用户（User）使用Administrator分配给的权限去使用各个系统模块。利用存储过程GetUserRole（UserID, UserRoleID output）,GetRolePermission（RoleID,Role-PermissinID output）获得用户对模块的使用权限。1.7 用户认证实现当用户通过验证后，由系统自动生成一个128位的TicketID保存到用户数据库表中，建立存储过程Login（UserID,UserPwd, TicketID output）进行用户认证，认证通过得到一个TicketID，否则TicketID为null。其流程图如下：图1 Login流程图得到TicketID后，客户端在调用服务端方法时传递TicketID，通过存储过程JudgeTicketPermission（TicketID,PermissionID）判断TicketID对应的用户所具有的权限，并根据其权限进行方法调用。当用户退出系统时，建立存储过程Logout（UserID）来退出系统。当用户异常退出系统时，根据最后的登陆时间（LastSignTime）确定用户的TickeID，建立存储过程ExceptionLogout（UserID,LastSignTime）处理用户的异常退出。图2 Logout流程图WebService可以采用SoapHeader中写入TicketID来使得TicketID从客户端传递给服务端。.Net Remoting可以采用CallContext类来实现TicketID从客户端传递给服务端。2 数据库设计2.1 数据库表图3 数据库关系图2.2 数据库表说明2.2.1 用户表（Static_User）Static_UserStatic_User字段名 详细解释 类型 备注 UserID 路线编号 varchar(20) PK UserName 用户名称 varchar(20) UserPwd 用户密码 varchar(20) LastSignTime 最后登陆时间 datatime SignState 用户登陆状态标记 int TickeID 验证票记录编号 varchar(128) 2.2.2 角色表（Static_Role）Static_RoleStatic_User字段名 详细解释 类型 备注 RoleID 角色编号 varchar(20) PK RoleName 角色名称 varchar(20) RoleNote 角色信息描述 varchar(20) 2.2.3 用户角色表（Static_User_Role）Static_User_RoleStatic_User字段名 详细解释 类型 备注 UserRoleID 用户角色编号 varchar(20) PK UserID 用户编号 varchar(20) FK RoleID 角色编号 varchar(20) FK UserRoleNote 用户角色信息描述 varchar(20) 2.2.4 权限表（Static_Permission）Static_PermissionStatic_User字段名 详细解释 类型 备注 PermissionID 编号 varchar(20) PK PermissionName 权限名称 varchar(20) PermissionNote 全息信息描述 varchar(20) 2.2.5 角色权限表（Static_Role_Permission）Static_Role_PermissionStatic_User字段名 详细解释 类型 备注 RolePermissionID 角色权限编号 varchar(20) PK RoleID 角色编号 varchar(20) FK PermissionID 权限编号 varchar(20) FK RolePermissionNote 角色权限信息描述 varchar(20) 用“位”来存储、修改用户权限的方法以前我用记录方式，如A用户有3个模块权限，则A有三条记录看到别人的程序里有这种方法，感觉不错，给大家看看有没有优点可取。用户权限用一个int字段表示，可以放32位,如果有第1,3,4模块的权限则，值为1 4 8=13_userId_userQx_A? |? 13_|_增加权限具体实现如增加第四个模块的权限,4的二进制值8update qxUser set userQx = userQx|8 where userId=A删除第四个模块的权限update qxUser set userQx = userQx&8 where userId=A如果删除第四个模块，则不加条件就可以了update qxUser set userQx = userQx&8 以上在SqlServer2000企业版通过。欢迎大家讨论，有更好的方法大家共享呀在Java 里34&2 !=0就行了。通过二，三两步的理解，相信这篇文章就不会生涩了！ 首先上文权限设计拙见(1)中只是想记录下自己权限设计上的一点看法，以及将自己日常最常用的权限解决方案记录下来以供日后回顾，没想到有朋友关注此类的设计，那就只能先把代码拿出来献丑了，抛砖引玉，大家共同探讨学习接着上文来说，上文所讨论的权限设计是一条思路，但既然是web应用，少不了数据库的支持，本文我们来讨论一下数据库的设计。（以下想法及思路仅仅代表本人拙见） 说到权限的数据库设计，必先理清权限中几种实体及其关系，此部分想必有过设计权限经验的同仁都知道怎么设计了，网上摆渡一下也是一裤衩子一裤衩子的，我们就在最平凡直观的数据库关系的基础上来建立权限。下面是我的几个表（所有的表都带有一个pk_id,作为表的自动生成的唯一主键）：用户表(T_UserInfo)：1/*/*=*/2/*/*Table:T_UserInfo*/3/*/*=*/4createtableT_UserInfo5(6pk_idNUMBERnotnull,7nameVARCHAR2(20),8sexBOOLEAN,9ageint,10emp_numNUMBER,11polityint,12unitVARCHAR2(50),13departmentVARCHAR2(20),14specialtyint,15positionVARCHAR2(10),16offtelVARCHAR2(20),17famtelVARCHAR2(20),18post_stateVARCHAR2(10),19remarkVARCHAR2(100),20constraintPK_T_USERINFOprimarykey(pk_id)21);实战经验：用户表就不多说了，都是一些常用字段，年龄、电话、职位等，建议大家建立一个通用一些，字段多一些的一个用户表，便于以后扩展，以后如果有特殊需求，不用扩这个基本表，可以通过主外键关系来新建一个表，用于扩充字段角色表(T_RoleInfo)：1/*/*=*/2/*/*Table:T_RoleInfo*/3/*/*=*/4createtableT_RoleInfo5(6pk_idnumbernotnull,7role_nameVARCHAR2(20),8role_descVARCHAR2(100),9parent_role_idNUMBER,10constraintPK_T_ROLEINFOprimarykey(pk_id)11);角色表中需要说明的就一个parent_role_id父角色id，此字段用来扩展角色的继承关系。资源表(T_ResourceInfo)：1/*/*=*/2/*/*Table:T_ResourceInfo*/3/*/*=*/4createtableT_ResourceInfo5(6pk_idNUMBERnotnull,7module_nameVARCHAR2(20),8module_codeVARCHAR2(10),9module_descVARCHAR2(100),10privilege_nameVARCHAR2(10),11privilege_codeCHAR,12privilege_descVARCHAR2(100),13constraintPK_T_RESOURCEINFOprimarykey(pk_id)14);15这个表需要说明的就比较多了，首先该表用来记录资源与资源权限，我这边所谓的资源就是实体，就是数据库表，角色需要对应到资源，有些角色对该资源有权限，有些角色则对该资源无权限，角色可对此资源操作的权限也不同。说白了，就是不同的角色对不同的数据库表的操作权限不同。因此我们这里的资源就是数据库表。module_name：资源名；module_code：资源代码（存放数据库表名）；privilege_name：权限名；privilege_code：权限代码（代表权限的code,也就是我们上文所说的权值）例如角色a对数据库表T_UserInfo有添加与删除的权限则该表应该按照如下配置：module_name：人员信息；modul