本人在项目中关于用户角色权限的经验

09-10-28 crycz
》banq 我目前是把职务看成就是角色。
非常赞同职务就是角色这个说法
举个现实中的例子:

一般公司:有总经理,部门经理,部门主管等等,这些是职务,对应角色。
总经理有炒人,签合同职责,部门主管有审查签到,这些是职责,对应权限,职务包含很多职责,是职责的集合。
你进了一个公司,老板说你是部门主管,你就知道你有哪些职责,能否炒人就看公司制度里规定的部门主管有没有炒人职责。
哪一天总经理出差,他出门说了一句:我出差这段时间你暂替一下我的工作。这句话的含义是他将总经理这个角色赋于你,
这段时间你可以炒人,签项目合同,因为你有总经理角色,你是老大。他总不会说这段时间你可以炒人,签合同,招人。。。

小公司:创业时就三个人,制度不完善,没有这些职务,小张负责招人,小刘负责弄钱,小王负责项目。
这就将每一个用户具体到职责了,就不存在职务(角色)的概念,所以小项目不需要角色。


我在这一口气看了五个角色权限的主题,从02,03年的文章看到09年
权限角色的粗细真的是对不能系统而言,没有通用的法则
我理解的概念是:(我在现有项目也是这样做的)
用户USER,是唯一的,体现在系统中登录id。
权限privilege,是系统中定义好的function,固定有什么,如:增,删,改,查,审核等
角色是权限的集合,类似于公司的职务,如总经理
角色概念的使用不是必须的,但是经常会要有,
因为操作很多,不能直接将用户和权限关联的。
用户可以有组,角色可以有组
一个用户可以有多个角色,但一次登录只有一个角色
开发部,市场部,是属于组织结构范畴,通常表现为树状,有时也会网状(网状会比较复杂)

项目应用或举例:
1:mysql的权限控制,直接将用户和权限挂钩,没有角色的概念,因为他的权限不多,只有增,删,查,创建,drop。。。
表如下:
用户 权限 资源
user privilege table
2.oracle中是有角色概念的
3.角色的概念不是必须的,但为了方便赋于权限,通常会有
举例:总经理出差的举例,他不会将他的职责全部列给你听。
4.还有一点不知道哪一个贴子了,有人将功能和资源分开,说重用性比较大,如下:权限(功能资源表)(多对多关联表)
id 功能 资源
1 增 新闻
2 改 新闻
3 驳回 简历

角色权限表
角色 功能权限id
编辑 1
编辑 2
经理 1
经理 2
经理 3

但是这样太细,用户极有可能增加了一条 “4. 驳回 新闻”的权限,显然是错误的,你又是如何控制这条非法权限的呢。
事实上,权限就一列即可,系统定制的。
权限表
id 功能权限
1 增新闻
2 改新闻
3 驳回简历

角色权限表同上(不用改),用户需自定义角色时,只需将角色和权限加到角色权限表中即可。
这样再将用户和角色多对多关联起来。

4. 至于开篇说的问题,市场部经理不能查看和修改技术部的人员,这是属于组织架构的问题,是数据过滤的权限,也跟业务有关系了。
跟角色没有必然联系。采用树形过滤,就可以很好解决。

5. 至于还有人提出的包含排除的问题,角色权限表设计成头和明细的方式,更好,头有角色,包含排除,明细有具体权限。这样可以减少大量数据和操作
例如:表头
表Access
表头id 角色 其他是否包含
1 总经理 是
2 编辑 否
表AccessLine
表头id 功能权限id 允许
1 1 否
2 1 是

这样总经理只有all-1即除了“增新闻”的全部权限。
编辑只具有0+1即只有“增新闻”的权限


总之,用户没有直接跟权限关联(当然不是必须这样设计),用户与角色关联,通过角色可以知道权限。这样角色可以复用,可以扩展,
操作简易,至于角色的继承是后一步具体实现的问题,还有用户的组,角色的组,都是同理的。这样才是一个比较好的解决方案。
我现在的项目就这样做的,希望同道之人指出不妥之处。谢谢

本论坛中相关主题
http://www.jdon.com/jivejdon/thread/2897
http://www.jdon.com/jivejdon/thread/7309
http://www.jdon.com/jivejdon/thread/10122
http://www.jdon.com/jivejdon/thread/17652
http://www.jdon.com/jivejdon/thread/13450

[该贴被crycz于2009-10-28 13:33修改过]

IceQi
2009-10-28 19:42
我的理解中在程序的角度上:权限 -> 角色,这是一个“组成”的关系。角色是“权限”组合成的。

在用户的角度上:角色 -> 职务 -> 人员,职务是“角色”组合成的,人员是“职务”组合成的。

snow0613
2009-10-29 11:32
>我目前是把职务看成就是角色。

你说的职务应该是职位吧。

我也认为应该把职位当成角色来处理。但是,假如这套系统并不是只有本公司体系的人才能登陆呢?比方说用供应商的用户及客户类型的用户呢?

这种问题你如何解决?

crycz
2009-10-29 12:52
>你说的职务应该是职位吧。
差不多这个意思

如果供应商用户登录,没关系就多建几个角色,例如供应商经理,供应商。。。
他们是通过组织机构来实现数据过滤的
我认为大多是
角色 控制 功能
架构 控制 数据
有时候更复杂的,会用角色来控制数据