Dojo
最新
最佳
搜索
订阅
解道Jdon
架构设计
领域驱动
DDD介绍
DDD专辑
战略建模
领域语言UL
领域事件
商业分析
工作流BPM
规则引擎
架构师观点
数据工程
产品经理
系统思维
微服务
微服务介绍
微服务专辑
模块化设计
SOA
API设计
clean架构
SpringBoot
分布式事务
事件溯源
Kafka消息
Kubernetes
DevOps
编程设计
GoF设计模式
模式专辑
面向对象
函数式编程
编程语言比较
编程工具比较
形式逻辑
前端编程
Reactive编程
Jdon框架
Rust语言
人工智能
Web3
模因梗
幽默梗
程序员吐槽
面试技巧
Java入门
数字化转型
认知偏差
道德经
更多话题
本人在项目中关于用户角色权限的经验
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
>你说的职务应该是职位吧。
差不多这个意思
如果供应商用户登录,没关系就多建几个角色,例如供应商经理,供应商。。。
他们是通过组织机构来实现数据过滤的
我认为大多是
角色 控制 功能
架构 控制 数据
有时候更复杂的,会用角色来控制数据
程序系统权限