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

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修改过]

    

1
IceQi
2009-10-28 19:42

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

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

snow0613
2009-10-29 11:32

>我目前是把职务看成就是角色。

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

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

这种问题你如何解决?

crycz
2009-10-29 12:52

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

差不多这个意思

如果供应商用户登录,没关系就多建几个角色,例如供应商经理,供应商。。。

他们是通过组织机构来实现数据过滤的

我认为大多是

角色 控制 功能

架构 控制 数据

有时候更复杂的,会用角色来控制数据