一般一个用户都有个默认的岗位,例如我是项目经理,那项目经理应该
有啥权限等。我们设计时考虑到了复杂情况,一般会设计为一对多关系,
但是日常生活中,大部分情况下,导入导出数据时,都希望获得一个单
一的关系,例如这个人默认的角色是啥?当然为了满足复杂情况,还有
一对多的的关系。所以我们设计权限时,一般在用户表里加一个默认角
色字段。
虽然RBAC里,不对用户直接赋予权限,但是我们国内的小公司,特别是
7-8个人的小公司用的软件,基本上都是没严格的岗位之分,领导也只
是很明确的指出,到底谁有什么权限,哪个人可以干啥啥等,一般也急
急忙忙,直接给用户设置权限就可以了,这虽然是错误的做法,但是很
符合国情,不这么做吧,软件还的确有些不好用。我们大部分人开发的
都是底端的小型管理类软件,所以,一般是该用户有什么权限是首先进
行判断的,这样程序的运行效率也会高一些。
接着是传统的,这个用户属于哪几个角色,这些角色是否有相应的权限,
这是符合RBAC的体系,也能适应大型管理类软件的权限设计惯例。
我的权限判断顺序为:
1. 该用户是否有效的?是否已经被锁定了?
2. 该用户是否为 Administrator 特殊用户?
3. 该用户是否在 Administrators 特殊角色里?
4. 此判断权限项是否有效?
5. 该用户的用户权限关系是否有效?该用户是否有这个权限?
6. 角色是否有效?
7. 角色拥有的权限是否有效?
8. 该用户是否在有效的角色里?
当然以上的判断会封装在一个函数里,判断函数越早结束越好,当然不
是非要把这个7个步骤都判断完,那函数的运行效率太差了。
为什么这里都判断个有效呢?
主要是为了采用用户主动可以申请权限的做法,例如权限都管理员配置,
那也是很琐碎的工作,用户自己可以申请拥有哪些权限,这些权限申请
被递交上来后,相应的管理员进行审核,审核通过后所申请的权限就生
效了,当然也可以帮别人申请权限,那就灵活性更强了。
直接删除数据与是否有效的差别为:
例如一个人以前过过某个权限,现在暂时没有这个权限了,你直接删除
了,虽然省事了,但是数据没有了,过了段时间想恢复权限时,还需要
加上去,这时我的做法时,不是非要删除的数据吧,别非得删除,能打
个有效无效的标志就可以了。不知道我这个想法是否正确,若不正确,
请指点批评。
导读:
大恶人吉日嘎拉之走火入魔闭门造车之.NET疯狂架构经验分享系列之(一)后台控制逻辑代码部分
http://www.cnblogs.com/jirigala/archive/2009/06/16/1503913.html
大恶人吉日嘎拉之走火入魔闭门造车之.NET疯狂架构经验分享系列之(二)后台服务代码部分
http://www.cnblogs.com/jirigala/archive/2009/06/16/1504515.html
大恶人吉日嘎拉之走火入魔闭门造车之.NET疯狂架构经验分享系列之(三)商业逻辑代码部分
http://www.cnblogs.com/jirigala/archive/2009/06/17/1505253.html
大恶人吉日嘎拉之走火入魔闭门造车之.NET疯狂架构经验分享系列之(四)高效的后台权限判断处理
http://www.cnblogs.com/jirigala/archive/2009/06/22/1508511.html
posted on 2009-06-22 18:04 不仅仅是通用权限设计 阅读(4110) 评论(49) 编辑 收藏
评论
1772832#2楼 回复 引用 查看
大恶人?占个位看看高手
#3楼 回复 引用 查看
逻辑删字段enabled是number,我建议为bit#4楼 回复 引用 查看
文中提到的岗位是那张表?岗位与权限关系在那?
RBAC_Binding里的clientID是????
#5楼 回复 引用 查看
通篇看完,没有看出“高效”在哪。#6楼 回复 引用 查看
以上几点,个人看法而已,仅限交流,无他。#7楼 回复 引用
使用RBAC,一般情况下,用户、角色表的数据量都不小。不知作者在其中使用了缓存了吗?#8楼 回复 引用 查看
up#9楼 回复 引用 查看
organization...#10楼 回复 引用 查看
楼主:有打擂之嫌哦!
在大的企业,一般一个人只负责一个职能;但在小公司会出现一个人承担多个职能的情况。
在大的系统中,账号是针对职能设计的,控制数据层面;在小的系统中,账号是针对人设计的,控制程序层面。
我认为一个职能对应一个子系统,设置对应账号;如这个人承担多个职能,可以给他配置多个账号。这样在开发中负担小、弹性好。这是因为,如果老板将来进行职能调整时,也不用调整程序,可维护性好。
一般的明细表里,我们都设置了有效标识字段。这是因为,大型数据库忌讳物理删除,利用这个字段可以做逻辑删除。这样做的目的,是有可能在日后进行数据跟踪用。
除了系统管理员之外,任何人都不能具有Administrator 或 Administrators 的权限,否则是非常不安全的事情。
#11楼 回复 引用 查看
楼主:在你的一篇文章中,看到一个题目:架构超级的简单。
不知你指的是什么架构?
#12楼 回复 引用 查看
这个排版看起来真的有点累...:-)
#13楼 回复 引用
主键是nvarchar? ---习惯不好#14楼 回复 引用 查看
看了你的文章标题,我直想踹你……#15楼[楼主] 回复 引用 查看
认真答复:罗里罗嗦夫斯基的问题,因为您仔细看了设计,也发现了问题#1楼
主键是nvarchar的,不建议
【我们单个系统里一般是用int类型的,性能高,
这个是为了按最强的分布式部署,同一个系统分
布在多个地方,网络又不连通,或者独立运行】
#3楼
逻辑删字段enabled是number,我建议为bit
【主要是为了适应多种数据库,我们也用bit的】
#4楼
文中提到的岗位是那张表?
【我们把岗位是放在角色表里,可以通过一个视
图产生一个岗位视图】
#7楼
使用RBAC,一般情况下,用户、角色表的数据量都不小。不知作者在其中使用了缓存了吗?
【在C/S系统里进行缓存的,我们有单个的bool的权限
判断函数及一次性获得某个用户的所有权限的2个函数,
B/S系统里按需要缓存也可以不缓存也可以】
当然按需要,灵活修改修正才是硬道理。
#16楼[楼主] 回复 引用 查看
接收 #14楼 的直踹,请把理由也踹出来一下呢。#17楼[楼主] 回复 引用 查看
非常认真的接纳 #10楼 的建议。目前系统里,基本上没违反您的提醒,英雄所见略同哦,哈哈。
#18楼 回复 引用
罗里罗嗦夫斯基的建议很好,楼主能采纳也很好。#19楼[楼主] 回复 引用 查看
再倔强,也要能听得进去人家的建议, 听不进建议,特别是好的建议,那就是老顽固啦,有错就改,是好孩子哈哈。
有错就改,进步就快。
#20楼 回复 引用
楼主就是比JSHY大度!#21楼 回复 引用 查看
楼主先别夸奖。你是否检查一下第一张图中的关联箭头是否正确。
我总是觉得应当是从一指向多,也就是从PK指向FK。
也许是自己理解有误,还是请你核实一下。
#22楼[楼主] 回复 引用 查看
好像是没错哦,一直是这么用的,是不是你看错了呢?以前我就以为天下就我最厉害,哈哈,
遇到了无数次挫折后,我才发现,我连普通人都不如,哈哈。
#23楼 回复 引用 查看
楼主这图不是抓下来的吧?是自己画的对不对?
#24楼 回复 引用
一个复杂的系统可能还需要一个完整的组织机构,单位、部门、岗位、职工等。用户和职工相对应。控制起来更复杂。#25楼 回复 引用 查看
如果 主键参与运算的,我好像一般也是nvarchar的!#26楼 回复 引用 查看
主键是聚集索引,是记录的物理排序方式。不要说是用nvarchar了,就是用char都是极大的不合理。这将大大地损害数据库的性能!#27楼[楼主] 回复 引用 查看
答复 #24楼, 组织机构,单位、部门、岗位、职工等。用户和职工相对应这些都已经弄好,甚至一个职工可以有多个帐号,不同权限的帐号。
其实这些就是架构里的内容,我的架构为什么不是空架子,很大程度上
把这些都弄好了,还有模块菜单管理,内部短信管理,简单的及时通讯
等。这些对架构来说,也算是一个沉重的包袱,因为架构一有新思想,
这些积累都跟着要改进,真不是一个人可以干的事情啊。
#28楼[楼主] 回复 引用 查看
答复 #26楼,不是迫不得已,我们一般不用这个主键。您说得有道理,但是我们用Oracle做测试,主键用 nvarchar, 速度也奇快,
差别不是大。
#29楼 回复 引用 查看
关于主键的问题,我明白楼主的想法了。你的第一张图中,Base_Role、 Base_UserRole两表的关联前头画反了。
其实,我不用看字段,只看表名就知道谁是主,谁是从了。再说你这不写着了吗:FK_UserRole_RoleID
#30楼 回复 引用 查看
顶一个,期待楼主继续.#31楼 回复 引用 查看
期待你把权限、工作流结合起来讲讲。#32楼 回复 引用 查看
--引用--------------------------------------------------slfafasfjal;j;: 楼主就是比JSHY大度!
--------------------------------------------------------
多谢提醒,我也确实应该改一改这个毛病了,应该大度大度,哈哈。
谢谢哦。
#33楼 回复 引用 查看
我对角色与权限的看法。一个账号最好对应一个角色,尽量避免使用多重角色,如果确实需要,不如重新创建一个新角色。这样,后期的业务变更,或升级就不会成为负担了。
角色是权限的一个集合,如果使用了角色,那只对角色审核就可以了,实在没有必要再是去审核权限。
角色的设置与业务相关,系统完成后,角色基本也就定型了,不会象超市买东西一样,想要什么管理员就给你什么!你看银行一排排的储蓄员,她们的账号虽然不同,但角色或权限全都是一样的。
用户可以申请权限,现实中不是这样的。
举个大家都可以见到的例子:
在超市的收费口,收费员一上班开机,用自己的身份卡刷一下,系统进行确认后,允许使用。
可是,这收费员只能往里刷商品,不能取消。如果,有客户在刷过后不想要了,这时收费员就会招来她们的组长。这组长会用他自己的卡刷一下,然后取消不想要的商品。
这组长的卡,就具备删除这个记录的权限。但这并不是随便审请来的,而是系统开发时就这样设计的。
同样,在银行我们也经常见到,储蓄员在操作过程中,经常召过他们的负责人,用卡刷一下,还敲入密码进行确认。这都是系统在做某些重要操作时,从安全角度进行设计的。
所以,权限设计是非常严肃、严谨的,不可能是通用与万能的!
如果有人非要咬文嚼字,那就只能给他Administrator权限。可这和没有权限有什么区别呢?
#34楼 回复 引用
有些入门级#35楼 回复 引用 查看
@hxmhj用户可以申请权限,现实中不是这样的
-----------------------------
我們公司就是可以申請權限的。我們是for企業服務,有很多系統,有很多不同廠的user,上線時是一塊一塊上線的,職位也是可以調動的,因此權限也是不斷地在申請和取消的~~
所以做管理軟件不要輕易下結論,很多時候,大家的知識隻局限於自己所知的那一塊,殊不知以經驗設計通用軟件最易失敗。
我的建議是,如果想做通用的東東,首先應做到最底層的抽象,然後在此抽象的基礎上,定義一個規則,並且在這個規則上建立起一套程式。
而在使用時,首先應評估當前的業務需求是否符合你的規則,如果不符合,就不能簡單的套用,或修改你的抽象,或修改你的程式(當然代價可能非常大),這也就是常說的做技術的,如果十分熟悉業務流程,將能最大程度地保証軟件的成功。
像權限設計,最忌就是user表的設計,你隻不過是做權限而已,管我user表如果設計呢?
user到時我會給你(當然在aspx或asmx中如果取得,會給你適當的API),然後你要做的就是給你user後,你按你的權限規則管控我的登錄用戶的權限即可。
至於user與角色的對應,那是抽象上的一套規則而已。如果我的系統足夠簡單,我就是有一個user表,了了的幾個用戶,你還要我建立角色表,角色用戶關聯表,我想真得懶得理你~~
現在很多企業都有自己的user表或權限表,以及以前的系統,在推通用權限時,最簡單的方式,就是無縫接入當前系統,想完全按照你的設計,推翻重來,想想成本吧
sorry,一大堆,樓主看看即好,不用太介意。。。
#36楼 回复 引用 查看
up#37楼 回复 引用 查看
申请权限这个想法不错,下次写系统的时候考虑。要不然权限都要管理员来开很确实很麻烦#38楼 回复 引用
楼主老了,过时了。嘎嘎~
#39楼 回复 引用 查看
To Kevin Zou朋友:
我是非常不愿意卷入口水战中的,所以我的第一句就是:我对角色与权限的看法。
仔细读了你的帖子,说的也很有道理。可是,也象你说的,我们都有自己的不同经历,认识也不会相同。就此一点,大家才有交流的必要!
就我自己的经历,非要说权限的申请,不如说权限的变更。这是因为权限的变更不是经常发生的!
譬如:某个人原先在仓库工作,他的账号被赋于仓库管理角色。后来,领导将他调到后勤工作。系统管理员在接到领导通知后,就将这个人的账号,从仓库管理角色中删除,然后,加入到后勤管理角色中。其它就什么也不用做了。
如果你认为这就叫申请权限,那我们也没有什么不一致的。
看你写的帖子,感到你也是一个高手。请你也帮着看一看,楼主的第一张图是不是有错误!
#40楼 回复 引用 查看
喜欢楼主的这篇文章,也喜欢hxmhj和Kevin Zou的讨论。这样才能共同提高 :)#41楼 回复 引用 查看
--引用--------------------------------------------------吉日嘎拉: 接收 #14楼 的直踹,请把理由也踹出来一下呢。
--------------------------------------------------------
呵呵,内容不错,就是标题有点那啥……
#42楼 回复 引用 查看
权限是非常重要的一个部分,但是更重要的是业务逻辑,也就是直接关系到价值的部分。#43楼 回复 引用
楼主的第一张图的箭头方向确实是有问题的。个人认为在权限控制这一块要想真正做到通用,是比较困难的,特别是要无缝接入另一个系统。权限控制开发中的一个难题是当涉及到具体的业务后,就会慢慢发现,需要特殊处理的代码太多,这样导致的一个问题是配置文件中的参数巨多无比。
不知道各位所使用权限控制系统是使用在何种场合的?就我所认知的而言,我们只是针对一群特定的用户。开发完一个系统后第一件事就是建组织机构、用户、角色、资源、菜单,再设置其相互之间的关系。
在我们这边,用户不能申请权限。更为严格的是,用户因为某种原因,账号被锁定了只能求助于管理员进行解锁。
#44楼 回复 引用 查看
To testkk第一感觉,您是一个富有实际经验的人!
权限是建立在具体应用上的,而不是什么人、人、人的。没有实际经验的人,才老会这么想人、人、人的。
没有具体的应用,或具体的应用还没有成型,就奢谈什么权限,甚至通用之类的话题......
#45楼 回复 引用
--引用--------------------------------------------------hxmhj: 主键是聚集索引,是记录的物理排序方式。不要说是用nvarchar了,就是用char都是极大的不合理。这将大大地损害数据库的性能!
--------------------------------------------------------
这个要看具体情况,如果char字节比较大,确实不太适合,但是你的表中用到最多的就是那个char字段,你不大可能固执的使用int吧
聚集索引用在有用的字段上,这个最重要
#46楼 回复 引用
说不定是自己骂自己,赚了人气,否则你可以谢谢骂你的人,哈哈#47楼 回复 引用 查看
删除权限使用无效标记应该是比较通用的做法。#48楼 回复 引用 查看
我觉得你的思路不错。和我想的很像。#49楼 回复 引用 查看
该篇未找到错别字