如坐春风
人生苦短,要紧跟自己的梦想,爱你所做的事业。
posts - 160,  comments - 284,  trackbacks - 0

权限设计是很多系统重要的组成部分,主要用于控制功能和流程,本文将几种常见的权限设计方案(权限系统的名都是自己起的)的基本设计写出来,其中不恰当处还请大家指出,我们来讨论一下.

1.等级权限系统

    这种权限系统在论坛中很常见,在这种系统中,权限级别如同官阶从低到高排列,每个用户拥有一个权限,其中设定了这个用户的权限等级,在用户需要执行操作前先查看其权限等级是否大于执行操作所需要的权限等级,是则进行操作。

在等级权限系统中领域对象用户类User的基本属性如下:
    id       // 用户ID
    name     // 用户名

领域对象权限类Privilege的基本属性如下:
    id       // 权限ID
    userid   // 持有此权限的用户id
    level    // 用户的权限等级

level的设置示例
level 对应可执行的功能
0 访问
1 可跟帖
2 可创建主贴
3 可删除主贴
4 可创建频道
5 可删除频道
6 可查看用户
7 可分配用户权限
8 可修改用户密码
9 可删除用户
...

使用中,执行一个操作比如创建主贴时,先从Session中取出用户,然后按其id查出其对应的权限等级,拿它和执行创建主贴所需要的等级(3)进行比较,高于则可进行创建主贴操作,否则报告权限不够.

等级权限系统简单易用,在如论坛等刚性控制系统中使用很好,但不适用于需要限制权限的范围的场合。

2.范围限制权限系统

    等级权限系统系统的缺点是控制范围过广,比如一个论坛中有很多子论坛,一个子论坛的分版主同时也能对另一个同等级分论坛的帖子进行控制,这在一定程度不合理,有越界的嫌疑,更好的做法是将版主权限控制在一版之内,这时我们可以采用范围限制权限系统. 这种权限系统在项目管理系统中很常见.

在等级权限系统中领域对象用户类User的基本属性如下:
    id       // 用户ID
    name     // 用户名

领域对象项目类Project的基本属性如下:
    id       // 项目ID
    name     // 项目名

领域对象权限类Privilege的基本属性如下:
    id       // 权限ID
    userid   // 持有此权限的用户id
    projectid // 此权限对应的项目
    level     // 用户的权限等级

其中,通过引入了新属性projectid,我们对权限的范围进行了有效限制,项目不同则权限等级再高也是无效,这样就起到了限制权限能力范围的作用.

3.范围限制单项权限系统

在上面两个权限系统中,权限高的自然能执行权限要求低的操作,这样做权力没有细分,在有些场合并不合理,比如即使是董事长不可直接操作人事部的招聘任务,他只对雇员去留有建议权.对于这样的场合我们需要使用范围限制单项权限系统.它的典型应用如工作流和OA系统。

在范围限制单项权限系统中领域对象用户类User的基本属性如下:
    id        // 用户ID
    name      // 用户名

领域对象项目类Project的基本属性如下:
    id        // 项目ID
    name      // 项目名

领域对象权限类Privilege的基本属性如下:
    id         // 权限ID
    userid     // 持有此权限的用户id
    projectid  // 此权限对应的项目
    abilityid  // 权限控制能力id

领域对象权限控制能力类ability的基本属性如下:
    id         // 控制能力ID
    item       // 控制能力子项

item的设置示例
item 对应可执行的功能
0 读
1 写
2 查
3 删

...

通过对权限能力的细分,用户权限的控制粒度更细了,对功能和流程就能有更精确的把握,适用于复杂的场合.

以上三种权限系统没有优劣之分只有适用场合的区别,前面的粗略但易于操作,后面的精确但失之烦琐,在现实使用中我们应该根据场合选择合适的权限系统.

 

posted on 2008-04-10 10:20 如坐春风 阅读(2082) 评论(10)  编辑  收藏 所属分类: Object Orient Programming

FeedBack:
# re: 三种权限设计方案的归纳和比较
2008-04-10 15:39 | Eric.Zhou
写的不错,应该研究一下RBAC  回复  更多评论
  
# re: 三种权限设计方案的归纳和比较
2008-04-11 23:22 | aier
受教了.受教了.如果这篇文章是作者的原创,我只能说你能把权限比较高深的东西用如此通俗易懂的方式表达出来,非人类也。感谢感谢。  回复  更多评论
  
# re: 三种权限设计方案的归纳和比较
2008-04-12 12:39 | 一农
建议大家还是深入了解一下Acegi,Acegi设计的思路和楼主有所不同。在Acegi里有用户,授权,资源,以及在资源被访问前进行权限的检查。一个用户可以有多个授权,一个授权可以对应多种资源,而资源可以多种多样。在Acegi的默认实现了有url,方法,领域对象。而用户和授权的关系,并不只是直接把授权交给用户,还可以把授权分配给角色,给用户组,给部门等,然后用户和角色,用户组,部门关联起来,几种分配方式可以配合使用。
按照这种思路,采用不同的授权方式,应该是可以用一套类似的程序,实现楼主所说的三种方式。  回复  更多评论
  
# re: 三种权限设计方案的归纳和比较
2008-04-12 13:13 | 如坐春风
@一农

你说的用户组,部门等组权限确实没有纳入考虑范围内,这方面确实忽略了。  回复  更多评论
  
# re: 三种权限设计方案的归纳和比较
2008-04-13 14:22 | 一手的小窝窝
呵呵,我自己实现的话就用到了
角色列表 N
角色拥有权限 (这算是 N对M关系)
权限列表 M ( 这里面指定访问资源就比较明确)..

最后用户 指定其 角色即可..

我的思路就是这样..也是这样做的.  回复  更多评论
  
# re: 三种权限设计方案的归纳和比较
2008-04-13 21:06 | beyond
不错,公司现在实习的项目就用到了上面讲的三种权限.
经典,收藏.  回复  更多评论
  
# re: 三种权限设计方案的归纳和比较
2008-04-14 13:29 | think.gs
^_^,角色继承一下会省去很多的麻烦哦!  回复  更多评论
  
# re: 三种权限设计方案的归纳和比较
2008-04-14 14:59 | lizhiyang
权限控制中最基础的就是操作,即web应用中的url。
可以给某个用户直接赋予一些操作,让他拥有这些动作的权限。这样权限的配置会比较麻烦。于是就有了角色,让不同的角色拥有不同操作,然后再给用户赋予一个或多个角色,使其能拥有多个操作。这样简单的权限设计就出来了。
如果要让部门的管理员能修改本部门员工的权限,能在本部门内增加、删除员工,能在本部门下增加子部门。那就要增加一个域(其实就是范围的集合)的概念了,将域赋予某个角色。比如:部门A的管理员a属于角色AA,角色AA有增加、删除员工的权限。为了让管理员a不能在部门B下增加、删除员工。于是就给管理员a所属的角色AA赋予一个域。让a只能在部门A下进行操作。
说的比较粗浅,希望大家指教。“一农”说的还比较好,大家可以借鉴下他的想法。  回复  更多评论
  
# re: 三种权限设计方案的归纳和比较
2008-04-16 11:09 | yjx
用户表 user
角色表 role
权限表 resource
角色-权限 role_resource  回复  更多评论
  
# re: 三种权限设计方案的归纳和比较
2008-04-16 11:12 | yjx
以上没说完
在resource 给url 比如:/new/*.do
通过 过滤器 控制。

还可以把 角色表做成 2级(3级)表(给父role id)  回复  更多评论
  

标题  
姓名  
主页
验证码 *  
内容(请不要发表任何与政治相关的内容)  
  登录  使用高级评论  新用户注册  返回页首  恢复上次提交      
该文被作者在 2008-04-12 09:04 编辑过
 



mail:junglesong@gmail.com
msn:junglesong_5@hotmail.com

Locations of visitors to this page

<2008年4月>
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

常用链接

留言簿(2)

随笔分类(178)

随笔档案(122)

个人软件下载

我的其它博客

我的邻居们

最新随笔

搜索

  •  

积分与排名

  • 积分 - 108288
  • 排名 - 66

最新评论

阅读排行榜

评论排行榜

60天内阅读排行

如坐春风(http://www.blogjava.net)原创,转载请注明出处.