权限管理

转自：http://www.jdon.com/jivejdon/thread/37375
本人在项目中关于用户角色权限的经验 2009年10月28日 13:29 收藏关注本主题 到本帖网址 加入本帖到收藏夹 请用鼠标选择需要回复的文字再点按本回复键 回复该主题
标签 权限    
1
顶一下
》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