在线293人
首页
主题表
培训咨询
标签
精华
查搜
注册
登陆
用户
自动登陆
密码
新用户注册
忘记密码?
首页
»
论坛
»
项目工程开发经验谈
上一主题
今天特地看了国内的几个门户网站,发现几乎都是cgi或者php的,几乎没有看到基于java的大型案例。可真的有点奇怪呀,不是听说sina、netease都用java吗,怎么就没有看到一个jsp的链接呢?..
返回本主题
返回主题列表
下一主题
系统设计中遇到如下问题,公司技术人员争论得十分激烈,各执一词,十分希望高手裁决之。我们公司技术人员都十分关注这个贴子: 1、采用代理主键作外键,还是代码code作外键 表1:代理主键——id,..
1
2
3
4
...
5
►
Go
总共有
74
回复 /
5
页
前往下页:
iceant
悄悄话
发表文章: 459
注册时间: 2002年10月13日 22:32
关于用户角色权限管理一点想法
2002年11月03日 11:24
标签列表
权限
(95)
[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] 当前用户的发布权限是否与能操作正在访问的资源.
----------------------
结束语
----------------------
这是我一次在飞机场等飞机时突然设计出来的东西。因为没有具体实现,
而且也可能因为时间仓促,没有想得很透彻,希望写出来大家讨论一下。
具体实现上的技术问题,我也想过,我觉得应该已经想通,但是介于时间关系,
这里写不了啦,大家可以谈谈看法 .
banq
悄悄话
发表文章: 9528
注册时间: 2002年08月03日 17:08
Re: 关于用户角色权限管理一点想法
2002年11月03日 21:27
你的方案应该行得通,但是我觉得可以再简化精练一点。
我的思路是这样。
用户角色权限,就设定用户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
大家可以讨论一下。
banq
悄悄话
发表文章: 9528
注册时间: 2002年08月03日 17:08
Re: 关于用户角色权限管理一点想法
2002年11月03日 21:28
上文权限系统应该为:
Role--|-Resource
|_Privilege
User
cc
悄悄话
发表文章: 275
注册时间: 2002年08月07日 23:47
Re: 关于用户角色权限管理一点想法
2002年11月04日 18:43
banq你的意思是每个用户可以有多个角色,而我觉得每个用户就应该有一个角色,而角色可以有多种组合,这样合不合适?
iceant
悄悄话
发表文章: 459
注册时间: 2002年10月13日 22:32
Re: 关于用户角色权限管理一点想法
2002年11月04日 19:07
我认为角色不易套角色,用户当然可以是多角色
我们每天不都在扮演不同的角色嘛
iceant
悄悄话
发表文章: 459
注册时间: 2002年10月13日 22:32
Re: 关于用户角色权限管理一点想法
2002年11月04日 19:10
请教一下,你觉得怎么简化比较好?
banq
悄悄话
发表文章: 9528
注册时间: 2002年08月03日 17:08
Re: 关于用户角色权限管理一点想法
2002年11月04日 20:50
我上面写了 实际将你4个元素简化成3个,角色不是独立的了。
blues
悄悄话
发表文章: 74
注册时间: 2002年09月23日 17:07
Re: 关于用户角色权限管理一点想法
2002年11月06日 16:57
我在上一个项目中曾经按照beng的提法做,发现和实际项目环境可能会有很大冲突。比如说,论坛权限--用户的需求是:按照不同部门来划分权限,技术部的论坛对于市场部来说是只读的。
后来采取的是一个折中的方案:其它模块按照角色设置权限,论坛模块则按照userId和departId(部门)来设置。
当然也可以想想办法把部门映射到角色上,但那样做的结果只会让原本简单的东西复杂化。
因此我觉得按照这个思想做出一个理想的模型很有好处,(至少可以归结一类问题的解决方案),但在真正的项目中,还是要具体问题具体解决。模型不是万金油。
iceant
悄悄话
发表文章: 459
注册时间: 2002年10月13日 22:32
Re: 关于用户角色权限管理一点想法
2002年11月06日 17:58
按照不同部门来划分权限,技术部的论坛对于市场部来说是只读的。
这就是我说的要产生资源+Privilege 的实例.
技术部论坛和市场部论坛都是论坛(Resource)的实例(Instance)
对于 Creator 来说,它们都有共同的Privilege set.
visit privilege, post privilege, reply privilege.....
所以,Creator 在开发时,就应该实现这些权限的控制.
对于管理员来说,他要做的就是
[1] 创建两个论坛实例:技术部论坛(TechForum)和市场部论坛(MarkForum).
[2] 创建角色: TechForumUser, BlockedTechForumUser 和 MarkForumUser
[3] 给角色分配权限:
TechForumUser[(visit,post,reply) on TechForum]
MarkForumUser[(visit,post,reply) on MarkForum]
[4] 将市场部的人都加入 MarkForumUser角色中
将技术部的人加入 TechForumUser + MarkForumUser 中
这样,市场部的人就不能访问 TechForum 上资源了
iceant
悄悄话
发表文章: 459
注册时间: 2002年10月13日 22:32
Re: 关于用户角色权限管理一点想法
2002年11月06日 17:59
sorry,BlockedTechForumUser should be delete
blues
悄悄话
发表文章: 74
注册时间: 2002年09月23日 17:07
Re: 关于用户角色权限管理一点想法
2002年11月06日 18:07
ok,thanks.
确实可以这样实现。
实际应用环境中没有这么做,是因为对于系统管理员来讲需要将所有的技术部员工加入到一个角色中,觉得麻烦。而用departId来做权限验证就很方便了。
iceant
悄悄话
发表文章: 459
注册时间: 2002年10月13日 22:32
Re: 关于用户角色权限管理一点想法
2002年11月06日 18:10
你说的没错,模型只是模型,不可能是万金油,
所以对不同的应用还是要做相应的修改。
你说的将整个部门一起加进去的问题,在现实确实不能一个个加。
应该做相应的改进,加入对整个部门操作的功能
欢迎讨论 ^_^ and 很高兴认识你
banq
悄悄话
发表文章: 9528
注册时间: 2002年08月03日 17:08
Re: 关于用户角色权限管理一点想法
2002年11月06日 22:41
其实blues例子中,部门也是用户,是属于用户组的概念,部门和用户之间是树形支节点的关系。
部门也可以和角色确立对应关系,首先你建立这样的角色:对自己是创建者的资源(论坛)拥有一切权利,如果否,就只有读权限。
然后再将部门和这个角色对上号。
我觉得这样思路清晰。
浆糊
悄悄话
发表文章: 244
注册时间: 2002年08月06日 19:20
Re: 关于用户角色权限管理一点想法
2002年11月07日 11:39
如果user不与Privilege直接相关的是不是会有些问题?
例如一个amdinistrator地role有删除,修改,发布,浏览的权限,现在有一个用户需要具有发布赫浏览的权限,那么就需要重新建立一个role。这样的话,如果功能很多的话,那role地数量不可想象。
我觉得可以有 user,userGroup来规划用户,userGroup可以嵌套userGroup。user,userGroup与role建立关系,但是user,userGroup也可以单独分配Privilege。role存在地意义仅仅是Privilege的一个集合,方便分配合修改。
iceant
悄悄话
发表文章: 459
注册时间: 2002年10月13日 22:32
Re: 关于用户角色权限管理一点想法
2002年11月07日 13:33
问得好,你说的增加用户组,我赞同!!!
Group 是 User 的集合.
Role 是 Privilege 的集合
从
OO
的角度来看,非常清楚。(I like it ^_^)
对于用户直接拥有权限,我还是不建议让用户直接与权限关联。
从实现的角度来看,权限的判断最后都是在检查当前用户是否拥有
需要的权限。也就是 [user,privilege] 这样的 pair 是否存在.
所以,给用户直接赋权是可以的。
但是我觉得这样使用,重用性不好,如果是通过 Role 来关联的话,
因为多了一层,所以灵活性更大,偶合性更小。出于这样的角度,我不建议那样用.
这个主题有
74
回复 /
5
页
Go
1
2
3
4
...
5
►
上一主题
返回本主题
返回主题列表
返回页首
下一主题
热点TAG:
AOP
cache
缓存
DDD
EJB
集群
设计模式
Hibernate
IOC
JiveJdon
OO
RBAC
Seam
Spring
Struts
正在读取,请等待...
Wowzio
grab this
·
technology
blog
查询本论坛内
近一天
近三天
近一周
近一月
近三月
近半年
近一年
所有
回复超过
的热门帖子
标题
内容
每2分种自动备份发贴内容Ctrl-V粘贴取出,提问题前先查询
标签列表
解惑之道在
J道
,打造中国最具影响力的的企业软件社区
OpenSource
JIVEJDON
v3.0
Powered by
JdonFramework
Code © 2002-08
jdon.com
anti spam