一个大项目(系统)里包含了不少小的子系统,而这些子系统中都有权限控制的部分,这件事情挺让我头痛的,记得一年前在沈阳,我曾经有一段时间也因因这个问题而疲于奔命,为何说疲于奔命呢?因为当时项目进度不容许,致使最终系统权限模块草草了事,每一个模块都是由读权限字符串来控制用户ACL,当用户没法访问时,提示权限不够。这么作对用户是很不负责任的,既然让用户看到了操做的方式和界面,为何又告诉用户没有权限呢?我开始怀疑咱们是否应该在底层就封杀用户的访问权限。 程序员
如今项目开展起来了,虽然目前我已经有了对权限控制的一套方案,而且实施成了个人可重用框架代码,虽然目前的权限也是基于众星捧月的AOP思想,但我至今对权限设计仍有两个疑惑: web
疑惑一:不少同行提出方案,想要在底层就截取用户权限,控制用户对方法或者类的访问。这样作的好处在于能够将系统功能与业务逻辑松散耦合,而且实现简单,结构清晰,三两个advisor、filter,或者acegi就能搞定,但在web程序中体现出了他的劣势,当咱们将用户的访问拒绝在业务逻辑以外的时候,咱们此时是否应该抛出异常提示用户?一旦提示用户没有相应的权限,我认为对于用户来讲,这就不是一个perfect practice。由此得出,咱们根本就不该该让用户作这次操做,而控制用户操做的源头就是界面,也就是说,在界面上咱们就应该对用户的权限元素(如添加按钮、功能菜单等)进行控制。此时,一对矛盾出现了,要控制界面上形形色色的元素只有两种办法,一,将权限与你的界面结合起来设计,这将违背AOP的思想,也使得系统控制模块的重用性大大降低,二,咱们借鉴primeton的想法,将权限控制的理念抽取出来,单独作成一套权限系统,解决你全部的须要权限控制的系统需求,这样也有使人头痛的问题,你的全部想用它来控制权限的系统,必须界面上统一风格。或许这样的方式对商业web系统是合适的,毕竟须要你大刀阔斧个性化的地方很少,但咱们却很难保证在将来几年内商业web系统的风格不改变。再者,开发这么一个系统也不是一蹴而就的事,在这个问题上一直让我困惑不已。算法
疑惑二:大多应用的权限断定是基于权限字符串的,但存储在数据库中的权限字符串可以断定的权限并很少,在咱们此次项目中,我引用了基于二进制的8421权限断定法则,我深深的感受到权限字符串的弱势,这使我想起了中国古老一套数学理论-“盈不足术”,超递增序列的魅力在我眼前滑过, 数据库
首先我来解释一下盈余不足理论:有十只盒子,第一个盒子里放一个盘子,第二个盒子里放两只,第三个盒子里放四只,第四个盒子里放八只……第九个盒子里放256只,第十个盒子放512只,即第N只箱子里放2^(N-1)只盘子,一共1023只。那么命题以下:在1023这个数字以内,任何一个数目均可以由这十只盒子里的几只组合相加而成。那么一、二、四、八、1六、3二、6四、12八、25六、512这个序列为何有这么个魔力?这个数列的特色:1、每项是后一项的二倍,2、每项都比前面全部项的和大,并且大1。这个1就是关键,就由于这个1,它才能够按 1递增,拼出总和以内任意一个整数。这个序列叫作超递增序列,它是解决背包问题的基础。三、拼出总和以内任意一个整数能够由这个序列中的一些数构成,且构成方法惟一,听说是密码学中的NP定理。譬如说这个数列总合中20这个数,只能由16+4一种方法构成,由此延伸出来,若是综合中这个数据表明一个权值,咱们能够解出它的全部构成参数(操做),如20这个数据,咱们能够挨个和序列中每一项按位与,得出来若是不等于0,就说明他是由这个数构成的。 架构
保存权值到int仍是varchar对于咱们来讲是个问题,固然,保存字符串的好处是运算压力小。咱们可能听过一个故事,就是把这个超递增序列延伸到第64 项,就是那个术士和皇帝在国际象棋棋盘上要米粒的传说。64项的和是一个天文数字!但计算机自己就是一个只认识二进制的机器!不少程序员成天只关心架构,甚至不知道或者不关心位操做是什么玩意,固然咱们有朋友担忧数据库的int不够长,那么既然能够保存一个只有0、1组成的varchar字符串,为何不能保存一个十六进制的字符串,有人规定varchar只能保存01吗?十六进制串的长度正好是二进制的四分之一。 框架
由此咱们能够无限制的扩展权值操做。 数据库设计
在最近的项目里,我对权限的控制分红两个部分,第一就是用户体验上,我设置了一个权限标签,从数据库中抽取权限信息,而后作到标签里,也凑或算成是界面 AOP了,第二就是底层的拦截,用了Spring 的AOP,为的是防止权限冲突,左右开弓。暂时解决权限所需,另外在算法上我用了16进制的权限判别代码,虽然配置较麻烦,写完代码还要写文档说明,不过也解决了权限繁杂又多的问题,暂时就这样了,嘿嘿,之后有空再研究。post
用户认证管理设计方案 学习
1 设计思路spa
为了设计一套具备较强可扩展性的用户认证管理,须要创建用户、角色和权限等数据库表,而且创建之间的关系,具体实现以下。
1.1 用户
用户仅仅是纯粹的用户,用来记录用户相关信息,如用户名、密码等,权限是被分离出去了的。用户(User)要拥有对某种资源的权限,必须经过角色(Role)去关联。
用户一般具备如下属性:
ü 编号,在系统中惟一。
ü 名称,在系统中惟一。
ü 用户口令。
ü 注释,描述用户或角色的信息。
1.2 角色
角色是使用权限的基本单位,拥有必定数量的权限,经过角色赋予用户权限,一般具备如下属性:
ü 编号,在系统中惟一。
ü 名称,在系统中惟一。
ü 注释,描述角色信息
1.3 权限
权限指用户根据角色得到对程序某些功能的操做,例如对文件的读、写、修改和删除功能,一般具备如下属性:
ü 编号,在系统中惟一。
ü 名称,在系统中惟一。
ü 注释,描述权限信息
1.4 用户与角色的关系
一个用户(User)能够隶属于多个角色(Role),一个角色组也可拥有多个用户,用户角色就是用来描述他们之间隶属关系的对象。用户(User)经过角色(Role)关联所拥有对某种资源的权限,例如
l 用户(User):
UserID UserName UserPwd
1 张三 xxxxxx
2 李四 xxxxxx
……
l 角色(Role):
RoleID RoleName RoleNote
01 系统管理员 监控系统维护管理员
02 监控人员 在线监控人员
03 调度人员 调度工做人员
04 通常工做人员 工做人员
……
l 用户角色(User_Role):
UserRoleID UserID RoleID UserRoleNote
1 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 PermissionNote
0001 增长监控 容许增长监控对象
0002 修改监控 容许修改监控对象
0003 删除监控 容许删除监控对象
0004 察看监控信息 容许察看监控对象
……
l 角色权限(Role_Permission):
RolePermissionID RoleID PermissionID RolePermissionNote
1 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)建立用户和角色,而且指定用户角色(User-Role)和角色权限(Role-Permission)的关联关系。
1) 具备建立用户、修改用户和删除用户的功能: Administrator
l 存储过程CreateUserInfo(@UserName,@UserPwd)建立用户信息;
l 存储过程ModifyUserInfo(@UserName,@UserPwd)修改用户信息;
l 存储过程DeleteUserInfo(@UserID)删除用户信息;
2) 具备建立角色和删除角色的功能: Administrator
l 存储过程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, @TicketIDoutput)进行用户认证,认证经过获得一个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_User
Static_User字段名 |
详细解释 |
类型 |
备注 |
UserID |
路线编号 |
varchar(20) |
PK |
UserName |
用户名称 |
varchar(20) |
|
UserPwd |
用户密码 |
varchar(20) |
|
LastSignTime |
最后登录时间 |
datatime |
|
SignState |
用户登录状态标记 |
int |
|
TickeID |
验证票记录编号 |
varchar(128) |
|
|
|
|
|
2.2.2 角色表(Static_Role)
Static_Role
Static_User字段名 |
详细解释 |
类型 |
备注 |
RoleID |
角色编号 |
varchar(20) |
PK |
RoleName |
角色名称 |
varchar(20) |
|
RoleNote |
角色信息描述 |
varchar(20) |
|
|
|
|
|
2.2.3 用户-角色表(Static_User_Role)
Static_User_Role
Static_User字段名 |
详细解释 |
类型 |
备注 |
UserRoleID |
用户角色编号 |
varchar(20) |
PK |
UserID |
用户编号 |
varchar(20) |
FK |
RoleID |
角色编号 |
varchar(20) |
FK |
UserRoleNote |
用户角色信息描述 |
varchar(20) |
|
|
|
|
|
2.2.4 权限表(Static_Permission)
Static_Permission
Static_User字段名 |
详细解释 |
类型 |
备注 |
PermissionID |
编号 |
varchar(20) |
PK |
PermissionName |
权限名称 |
varchar(20) |
|
PermissionNote |
全息信息描述 |
varchar(20) |
|
|
|
|
|
2.2.5 角色-权限表(Static_Role_Permission)
Static_Role_Permission
Static_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的二进制值8
update qxUser setuserQx = userQx|8 where userId='A'
删除第四个模块的权限
update qxUser setuserQx = userQx&~8 where userId='A'
若是删除第四个模块,则不加条件就能够了
update qxUser setuserQx = userQx&~8
以上在SqlServer2000企业版经过。
欢迎你们讨论,有更好的方法你们共享呀~~~
在Java 里
34&2 !=0就好了。
经过二,三两步的理解,相信这篇文章就不会生涩了!~
首先上文权限设计拙见(1)中只是想记录下本身权限设计上的一点见解,以及将本身平常最经常使用的权限解决方案记录下来以供往后回顾,没想到有朋友关注此类的设计,那就只能先把代码拿出来献丑了,抛砖引玉,你们共同探讨学习
接着上文来讲,上文所讨论的权限设计是一条思路,但既然是web应用,少不了数据库的支持,本文咱们来讨论一下数据库的设计。(如下想法及思路仅仅表明本人拙见)
说到权限的数据库设计,必先理清权限中几种实体及其关系,此部分想必有过设计权限经验的同仁都知道怎么设计了,网上摆渡一下也是一裤衩子一裤衩子的,咱们就在最平凡直观的数据库关系的基础上来创建权限。下面是个人几个表(全部的表都带有一个pk_id,做为表的自动生成的惟一主键):
用户表(T_UserInfo):
1 /**//*==============================================================*/
2/**//* Table: T_UserInfo */
3/**//*==============================================================*/
4create table T_UserInfo
5(
6 pk_id NUMBER not null,
7 name VARCHAR2(20),
8 sex BOOLEAN,
9 age int,
10 emp_num NUMBER,
11 polity int,
12 unit VARCHAR2(50),
13 department VARCHAR2(20),
14 specialty int,
15 position VARCHAR2(10),
16 offtel VARCHAR2(20),
17 famtel VARCHAR2(20),
18 post_state VARCHAR2(10),
19 remark VARCHAR2(100),
20 constraint PK_T_USERINFO primary key (pk_id)
21);
实战经验:用户表就很少说了,都是一些经常使用字段,年龄、电话、职位等,建议你们创建一个通用一些,字段多一些的一个用户表,便于之后扩展,之后若是有特殊需求,不用扩这个基本表,能够经过主外键关系来新建一个表,用于扩充字段
角色表(T_RoleInfo):
1 /**//*==============================================================*/
2/**//* Table: T_RoleInfo */
3/**//*==============================================================*/
4create table T_RoleInfo
5(
6 pk_id number not null,
7 role_name VARCHAR2(20),
8 role_desc VARCHAR2(100),
9 parent_role_id NUMBER,
10 constraint PK_T_ROLEINFO primary key (pk_id)
11);
角色表中须要说明的就一个parent_role_id父角色id,此字段用来扩展角色的继承关系。
资源表(T_ResourceInfo):
1 /**//*==============================================================*/
2/**//* Table: T_ResourceInfo */
3/**//*==============================================================*/
4create table T_ResourceInfo
5(
6 pk_id NUMBER not null,
7 module_name VARCHAR2(20),
8 module_code VARCHAR2(10),
9 module_desc VARCHAR2(100),
10 privilege_name VARCHAR2(10),
11 privilege_code CHAR,
12 privilege_desc VARCHAR2(100),
13 constraint PK_T_RESOURCEINFO primary key (pk_id)
14);
15
这个表须要说明的就比较多了,首先该表用来记录资源与资源权限,我这边所谓的资源就是实体,就是数据库表,角色须要对应到资源,有些角色对该资源有权限,有些角色则对该资源无权限,角色可对此资源操做的权限也不一样。说白了,就是不一样的角色对不一样的数据库表的操做权限不一样。所以咱们这里的资源就是数据库表。
module_name:资源名;module_code:资源代码(存放数据库表名);
privilege_name:权限名;privilege_code:权限代码(表明权限的code,也就是咱们上文所说的权值)
例如角色a对数据库表T_UserInfo有添加与删除的权限则该表应该按照以下配置:
module_name:人员信息;
module_code:T_UserInfo
privilege_name:添加与删除
privilege_code:6
这里咱们假设的是2的0次方为添加权限,2的1次方为添加权限,2的2次方为删除权限,2的3次方为更新权限,则拥有添加与删除权限就应该为2的1次方+2的2次方=6,其实2的几回方表明什么含义咱们能够另外开个数据库表来配置(或者xml文件)此处咱们忽略这些步骤。固然若是你的权限较多,譬如你还但愿 a这个角色对人员信息表有上传得权限,咱们能够将将上传权限定义为2的4次方,16,16的16进制数为10,记录在数据库里的形式应该为0x10若是a 角色拥有添加、删除、更新、上传权限,则a的权值应该为2的1次方+2的2次方+2的3次方+2的4次方=30,用16进制来表示就应该为0x1E,记录 16进制数据,你不用担忧位数不够。
剩余的就是几张关系表了:
人员角色关系表(T_R_User_Role):
1 /**//*==============================================================*/
2/**//* Table: T_R_user_role */
3/**//*==============================================================*/
4create table T_R_user_role
5(
6 pk_id NUMBER not null,
7 user_id NUMBER,
8 role_id NUMBER,
9 constraint PK_T_R_USER_ROLE primary key (pk_id)
10);
11
角色资源关系表(T_R_Role_Resource)
1 /**//*==============================================================*/
2/**//* Table: T_R_role_resource */
3/**//*==============================================================*/
4create table T_R_role_resource
5(
6 pk_id NUMBER not null,
7 role_id NUMBER,
8 res_id NUMBER,
9 constraint PK_T_R_ROLE_RESOURCE primary key (pk_id)
10);
11
固然若是你不怕麻烦,能够添加进去组(group)、系统(system)、组织(organization),创建起一套属于你本身的完整的权限解决方案,做为系统无关的模块去套用到每一个你所架构的应用中去,那是一件极爽的事情。