在各种各样的系统中,权限设计是必不可少的,现在基本基于角色的思想,即一个用户属于某个角色当然也可能属于多个角色,然后根据角色来确实相应的权限,以进一步验证其合法性,最后才执行操作.很多人可能在用户进入系统的某模块之前就进行权限验证,后来知道,微软的sps并不是这样的,所有的用户都可进行操作,比如你提交一个审批的时候才去验证,来告诉你,你是否成功提交,我觉得这样做有优势,一速度快,用户一进入系统不需要验证,当然给用户的体验不太好.下面参考了一个文篇,自己的再整理一下,主要是数据库的设计,下面就是数据库图,用PD设计的
其实我把图贴出来后,大家一看就非常清楚了,为了简要说明,我并没有给表加多余的字段,比如用户表中的什么地址,Email之类的字段
用户角色表来确实用户对应的角色,而角色表中的角色值来对应功能表的功能编号字段,来确定某角色是否具有此功能(操作)的权限,关键的问题就是在这里,而上面的模块表,来确定一个模块间的功能集合,比如文档管理模块中上传文档功能,修改文档属性功能.下面我举例来说明一下他们之间的关系,就拿文档管理来说明吧,正好最近也在开发J
模块表(0,0,文档管理,DocLibManage,3);//请对应数据库,注意首个是自动生成id
功能表(0,0,新建目录,CreateFloder,0);//同上
功能表(0,1,上传文件,UpLoadFile,0);//同上
功能表(0,2,修改属性,ModiAttr,0);//同上
再来看看,角色来对应功能的原理
角色表(0,操作员,010,日常维护)
关键是角色表里的角色值010,它代表如下含义
|
角色值 |
010 |
含义 |
说明 |
|
|
第0位 |
0 |
对应功能表中的功能编号0,即新建目录 |
0代表没有权限 |
此角色不可以新建目录 |
|
第1位 |
1 |
对应功能表中的功能编号1,即上传文件 |
1代表有权限 |
此角色可以上传文件 |
|
第2位 |
0 |
对应功能表中的功能编号2,即修改属性 |
0代表没有权限 |
此角色不可以修改属性 |
用这种方式,控制的粒度比较细