三种权限设计方案的归纳和比较

本文介绍了三种权限设计方案:等级权限系统、范围限制权限系统及范围限制单项权限系统,并对比了它们的特点和适用场景。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

 

三种权限设计方案的归纳和比较

 

播者注:权限设计有很多方案,本文作者从宏观绝对分析了三种普遍使用的权限设计的特点,相信读者读完本文后,会对权限设计拥有更进一步的认识。

 

正文:


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

 

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 删

...

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

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

 

 

原文链接:http://www.blogjava.net/sitinspring/archive/2008/04/10/191768.html

针对 OA 系统的特点,权限说明: 权限 在系统中,权限通过模块 +动作来产生,模块就是整个系统中的一个子模块,可能对应一个 菜单,动作也就是整个模块中(在B/S 系统中也就是一个页面的所有操作,比如“ 浏览、添 加、修改、删除” 等)。将模块与之组合可以产生此模块下的所有权限权限组 为了更方便的权限的管理,另将一个模块下的所有权限组合一起,组成一个“ 权限组” ,也就 是一个模块管理权限,包括所有基本权限操作。比如一个权限组(用户管理),包括用户的 浏览、添加、删除、修改、审核等操作权限,一个权限组也是一个权限。 角色 权限的集合,角色与角色之间属于平级关系,可以将基本权限权限组添加到一个角色中, 用于方便权限的分配。 用户组 将某一类型的人、具有相同特征人组合一起的集合体。通过对组授予权限(角色),快速使 一类人具有相同的权限,来简化对用户授予权限的繁琐性、耗时性。用户组的划分,可以按 职位、项目或其它来实现。用户可以属于某一个组或多个组。 通过给某个人赋予权限,有4 种方式( 参考飞思办公系统) A . 通过职位 a) 在职位中,职位成员的权限继承当前所在职位的权限,对于下级职位拥有的权限不可继 承。 b) 实例中:如前台这个职位,对于考勤查询有权限,则可以通过对前台这个职位设置考勤 查询的浏览权,使他们有使用这个对象的权限,然后再设置个,考勤查询权(当然也可以不 设置,默认能进此模块的就能查询),则所有前台人员都拥有考勤查询的权利。 B. 通过项目 a) 在项目中,项目成员的权限来自于所在项目的权限,他们同样不能继承下级项目的权限, 而对于项目组长,他对项目有全权,对下级项目也一样。 b) 实例中:在项目中,项目成员可以对项目中上传文档,查看本项目的文档,可以通过对项 目设置一个对于本项目的浏览权来实现进口,这样每个成员能访问这个项目了,再加上项目 文档的上传权查看文档权即可。 c) 对于组长,因为可以赋予组长一个组长权(组长权是个特殊的权限,它包含其他各种权 限的一个权限包),所有组长对于本项目有全权,则项目组长可以对于项目文档查看,审批, 删除,恢复等,这些权限对于本项目的下级项目依然有效。 C. 通过角色 a) 角色中的成员继承角色的权限,角色与角色没有上下级关系,他们是平行的。通过角色 赋予权限,是指没办法按职位或项目的分类来赋予权限的另一种方式,如:系统管理员,资 料备份员… b) 实例中:对于本系统中,全体人员应该默认都有的模块,如我的邮件,我的文档,我的 日志,我的考勤……,这些模块系统成员都应该有的,我们建立一个角色为系统默认角色, 把所有默认访问的模块的浏览权加入到里面去,则系统成员都能访问这些模块。 D. 直接指定 a) 直接指定是通过对某个人具体指定一项权限,使其有使用这个权限的能力。直接指定是 角色指定的一个简化版,为了是在建立像某个项目的组长这种角色时,省略创建角色这一个 步骤,使角色不至于过多。 b) 实例中:指定某个项目的组长,把组长权指定给某个人。 针对职位、项目组: 如果用添加新员工,员工调换职位、项目组,满足了员工会自动继承所在职位、项目组的权 限,不需要重新分配权限的功能。 用户管理 用户可以属于某一个或多个用户组,可以通过对用户组授权,来对组中的所有用户进行权限 的授予。一个用户可以属于多个项目组,或担任多个职位。 授权管理 将一个基本权限或角色授予用户或用户组,使用户或用户组拥有授予权限的字符串,如果角 色、职位、项目中存在相同的基本权限,则取其中的一 个;如脱离角色、职位、项目组, 只是取消用户或用户组的中此角色、职位、项目组所授予的权限。用户所拥有的权限是所有 途径授予权限的集合。管理员用户可以 查看每个用户的最终权限列表。
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值