最近项目的项目很奇怪,一个大项目(系统)里包含了很多小的子系统,而这些子系统中都有权限控制的部分,这件事情挺让我头痛的,记得一年前在沈阳,我曾经有一段时间也因因这个问题而疲于奔命,为什么说疲于奔命呢?由于当时项目进度不允许,导致最终系统权限模块草草了事,每个模块都是由读权限字符串来控制用户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 权限
权限指用户根据角获得对程序某些功能的操作,例如对文件的读、写、修改和删除功能,通常具有以下属性:
养蜂专用车ü 编号,在系统中唯一。
üled防水灯串 名称,在系统中唯一。
ü 注释,描述权限信息
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 cn-m一般工作人员 工作人员
……
l 权限(Permission):
PermissionID PermissionName PermissionNote
0001 增加监控 允许增加监控对象
0002 修改监控 允许修改监控对象
0003 删除监控 允许删除监控对象
0004 转子动平衡察看监控信息 允许察看监控对象
……
l 角权限(Role_Permission):
RolePermissionID RoleID PermissionID RolePermissionNote
1 01 0001 角“系统管理员”具有权限“增加监控”
2 01 0002 角“系统管理员”具有权限“修改监控”usb存储器
3 01 0003 角“系统管理员”具有权限“删除监控”