芝加哥消防车出警:用户和角色权限的设计

来源:百度文库 编辑:偶看新闻 时间:2024/04/29 14:16:01

[Title ] 关于用户角色权限管理一点想法
[Author] Pizer.Chen
[Email ] Iceant@21cn.com | iceant@vip.163.com
[Date ] 2002-11-3

----------------------------------------------------------------------------
我以前设计过一个权限系统的模型,但是我没有实现,
可以说出来,大家讨论一下。

我认为一个系统的权限部分应该由以下四个部分组成:

[*] Resource
[*] Privilege
[*] Role
[*] User

另外,一个系统中最少有这么几个角色:
[*] Creator, 也可以称做 Programmer.
[*] Administrator, 超级用户
[*] General User

----------------------
权限各部分之间的关系:
----------------------
1. Resource 就是系统的资源,比如部门新闻,文档等各种可以被提供给用户访问的对象.

2. Privilege 是 Resource Related 的权限。
什么意思?就是指,这个权限是绑定在特定的资源实例上的。
比如说部门新闻的发布权限,叫做"部门新闻发布权限".
这就表明,该 Privilege 是一个发布权限,而且是针对部门新闻这种资源的一种发布权限。
我认为,Privilege 是由 Creator 在做开发时就确定的。

3. Role, 是角色,拥有一定数量的权限。

4. User, 与 Role 相关。在我设计的系统里,User是不能与 Privilege 直接相关的,
User 要拥有对某种资源的权限,必须通过Role去关联.

----------------------
系统大串联:(^_^)
----------------------
下面简单介绍一下,一个权限从开发到使用的过程.

1. Creator 创造 Privilege, Creator 在设计和实现系统时会划分,一个子系统或称为模块,
应该有哪些权限. 拿新闻这一块来说,可能应该有:
[*] 发布权限(publish)
[*] 修改权限(modify)
[*] 审核权限(review)
[*] 浏览权限(visit)
.......
这里完成的是 Privilege 与 Resource 的对象申明,并没有真正将 Privilege 与具体
Resource 实例联系在一起.

2. Administrator 指定 Privilege 与 Resource Instance 的关联.
在这一步, 权限真正与资源实例联系到了一起, 产生了 Privilege Instance。
比如,Administrator 创建了一个叫做 "部门新闻" 的Resource Instance.
然后将发布权限与这个资源相关联,产生出 "部门新闻发布权限" 这个 Privilege Instance.

3. Administrator 创建一个角色,称做 "部门新闻发布者".

4. Administrator 将 "部门新闻发布权限" 赋予 "部门新闻发布者".

5. Administrator 从用户列表中选取一个或多个用户,
然后给这些用户赋予 "部门新闻发布者" 的角色

6. User 进到系统,在它的可访问资源列表上,会出现"部门新闻发布"的链接.

7. User 点击 "部门新闻发布"的链接, 根据 Creator 的实现,系统会检查
[1] 当前用户是否拥有发布权限
[2] 当前用户的发布权限是否与能操作正在访问的资源.

----------------------
结束语
----------------------
这是我一次在飞机场等飞机时突然设计出来的东西。因为没有具体实现,
而且也可能因为时间仓促,没有想得很透彻,希望写出来大家讨论一下。
具体实现上的技术问题,我也想过,我觉得应该已经想通,但是介于时间关系,
这里写不了啦,大家可以谈谈看法 .

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
你的方案应该行得通,但是我觉得可以再简化精练一点。
我的思路是这样。

用户角色权限,就设定用户user和角色role的对应关系,user还包括用户组group, user和group的关系树形结构的关系。

所以,在系统权限这里,我们就可以围绕角色开始定义,抛开user或组的纠缠。如你所说resource 和function(Privilege)组合成一个角色。

提供一个强大的用户权限定制系统,就要在上面两个方面提供定制:
1.可以自行增加 删除 管理resource和function之间关系。
2.可以自行设定用户user和角色role的对应关系。

以你的部门新闻发布为例:
1.某一个新闻为resource . 发布权限(publish) 修改权限(modify)等为function(Privilege),先设定好这两者关系,比如新闻+发布权限 作为一条记录存入数据库,ID就是roleID,这条记录其实就是一个角色。

2.设定user和roleID角色之间的关系,哪些user包含这个角色role。

通过上面两步设置,权限系统框架基本设定,一个用户登陆进来,可以按上面规则检查一下。

我这里与你的区别就是,权限部分应该由以下部分组成:

Role--|-Resource
|_Privilege
User

大家可以讨论一下。