大恶人吉日嘎拉之走火入魔闭门造车之.NET疯狂架构经验分享系列之（四）高效的后台权限判断处理

一般一个用户都有个默认的岗位，例如我是项目经理，那项目经理应该
有啥权限等。我们设计时考虑到了复杂情况，一般会设计为一对多关系，
但是日常生活中，大部分情况下，导入导出数据时，都希望获得一个单
一的关系，例如这个人默认的角色是啥？当然为了满足复杂情况，还有
一对多的的关系。所以我们设计权限时，一般在用户表里加一个默认角
色字段。





虽然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

#1楼 　回复　引用　查看　 主键是nvarchar的，不建议

2009-06-22 18:40 | 罗里罗嗦夫斯基

#2楼 　回复　引用　查看　

大恶人?
占个位看看高手
2009-06-22 18:40 | hicode

#3楼 　回复　引用　查看　

逻辑删字段enabled是number，我建议为bit
2009-06-22 18:41 | 罗里罗嗦夫斯基

#4楼 　回复　引用　查看　

文中提到的岗位是那张表？

岗位与权限关系在那？

RBAC_Binding里的clientID是？？？？
2009-06-22 18:47 | 罗里罗嗦夫斯基

#5楼 　回复　引用　查看　

通篇看完，没有看出“高效”在哪。
2009-06-22 18:49 | 罗里罗嗦夫斯基

#6楼 　回复　引用　查看　

以上几点，个人看法而已，仅限交流，无他。
2009-06-22 18:55 | 罗里罗嗦夫斯基

#7楼 　回复　引用　

使用RBAC，一般情况下，用户、角色表的数据量都不小。不知作者在其中使用了缓存了吗？
2009-06-22 18:57 | testkk[未注册用户]

#8楼 　回复　引用　查看　

up
2009-06-22 19:09 | 温景良(Jason)

#9楼 　回复　引用　查看　

organization...
2009-06-22 19:26 | Clingingboy

#10楼 　回复　引用　查看　

楼主：

有打擂之嫌哦！

在大的企业，一般一个人只负责一个职能；但在小公司会出现一个人承担多个职能的情况。

在大的系统中，账号是针对职能设计的，控制数据层面；在小的系统中，账号是针对人设计的，控制程序层面。

我认为一个职能对应一个子系统，设置对应账号；如这个人承担多个职能，可以给他配置多个账号。这样在开发中负担小、弹性好。这是因为，如果老板将来进行职能调整时，也不用调整程序，可维护性好。

一般的明细表里，我们都设置了有效标识字段。这是因为，大型数据库忌讳物理删除，利用这个字段可以做逻辑删除。这样做的目的，是有可能在日后进行数据跟踪用。

除了系统管理员之外，任何人都不能具有Administrator 或 Administrators 的权限，否则是非常不安全的事情。

2009-06-22 19:51 | hxmhj

#11楼 　回复　引用　查看　

楼主：

在你的一篇文章中，看到一个题目：架构超级的简单。

不知你指的是什么架构？

2009-06-22 20:12 | hxmhj

#12楼 　回复　引用　查看　

这个排版看起来真的有点累...
:-)
2009-06-22 20:24 | Old

#13楼 　回复　引用　

主键是nvarchar? ---习惯不好
2009-06-22 20:51 | 主键是nvarchar?[未注册用户]

#14楼 　回复　引用　查看　

看了你的文章标题，我直想踹你……
2009-06-22 21:28 | pythonic

#15楼[楼主] 　回复　引用　查看　

认真答复：罗里罗嗦夫斯基的问题，因为您仔细看了设计，也发现了问题

#1楼
主键是nvarchar的，不建议
【我们单个系统里一般是用int类型的，性能高，
这个是为了按最强的分布式部署，同一个系统分
布在多个地方，网络又不连通，或者独立运行】

#3楼
逻辑删字段enabled是number，我建议为bit
【主要是为了适应多种数据库，我们也用bit的】

#4楼
文中提到的岗位是那张表？
【我们把岗位是放在角色表里，可以通过一个视
图产生一个岗位视图】

#7楼
使用RBAC，一般情况下，用户、角色表的数据量都不小。不知作者在其中使用了缓存了吗？
【在C/S系统里进行缓存的，我们有单个的bool的权限
判断函数及一次性获得某个用户的所有权限的2个函数，
B/S系统里按需要缓存也可以不缓存也可以】

当然按需要，灵活修改修正才是硬道理。

2009-06-22 21:34 | 吉日嘎拉

#16楼[楼主] 　回复　引用　查看　

接收 #14楼 的直踹，请把理由也踹出来一下呢。

2009-06-22 21:36 | 吉日嘎拉

#17楼[楼主] 　回复　引用　查看　

非常认真的接纳 #10楼 的建议。
目前系统里，基本上没违反您的提醒，英雄所见略同哦，哈哈。
2009-06-22 21:37 | 吉日嘎拉

#18楼 　回复　引用　

罗里罗嗦夫斯基的建议很好，楼主能采纳也很好。
2009-06-22 21:39 | 未登录的包包[未注册用户]

#19楼[楼主] 　回复　引用　查看　

再倔强，也要能听得进去人家的建议， 听不进建议，特别是好的建议，
那就是老顽固啦，有错就改，是好孩子哈哈。

有错就改，进步就快。

2009-06-22 21:45 | 吉日嘎拉

#20楼 　回复　引用　

楼主就是比JSHY大度!

2009-06-22 21:47 | slfafasfjal;j;[未注册用户]

#21楼 　回复　引用　查看　

楼主先别夸奖。

你是否检查一下第一张图中的关联箭头是否正确。

我总是觉得应当是从一指向多，也就是从PK指向FK。

也许是自己理解有误，还是请你核实一下。

2009-06-22 22:03 | hxmhj

#22楼[楼主] 　回复　引用　查看　

好像是没错哦，一直是这么用的，是不是你看错了呢？

以前我就以为天下就我最厉害，哈哈，
遇到了无数次挫折后，我才发现，我连普通人都不如，哈哈。

2009-06-22 22:18 | 吉日嘎拉

#23楼 　回复　引用　查看　

楼主这图不是抓下来的吧？

是自己画的对不对？

2009-06-22 22:20 | hxmhj

#24楼 　回复　引用　

一个复杂的系统可能还需要一个完整的组织机构，单位、部门、岗位、职工等。用户和职工相对应。控制起来更复杂。
2009-06-22 22:29 | testkk[未注册用户]

#25楼 　回复　引用　查看　

如果 主键参与运算的，我好像一般也是nvarchar的！
2009-06-22 22:30 | 千里走单骑

#26楼 　回复　引用　查看　

主键是聚集索引，是记录的物理排序方式。不要说是用nvarchar了，就是用char都是极大的不合理。这将大大地损害数据库的性能！

2009-06-22 22:35 | hxmhj

#27楼[楼主] 　回复　引用　查看　

答复 #24楼， 组织机构，单位、部门、岗位、职工等。用户和职工相对应
这些都已经弄好，甚至一个职工可以有多个帐号，不同权限的帐号。

其实这些就是架构里的内容，我的架构为什么不是空架子，很大程度上
把这些都弄好了，还有模块菜单管理，内部短信管理，简单的及时通讯
等。这些对架构来说，也算是一个沉重的包袱，因为架构一有新思想，
这些积累都跟着要改进，真不是一个人可以干的事情啊。

2009-06-22 22:37 | 吉日嘎拉

#28楼[楼主] 　回复　引用　查看　

答复 #26楼，不是迫不得已，我们一般不用这个主键。
您说得有道理，但是我们用Oracle做测试，主键用 nvarchar， 速度也奇快，
差别不是大。

2009-06-22 22:38 | 吉日嘎拉

#29楼 　回复　引用　查看　

关于主键的问题，我明白楼主的想法了。

你的第一张图中，Base_Role、 Base_UserRole两表的关联前头画反了。

其实，我不用看字段，只看表名就知道谁是主，谁是从了。再说你这不写着了吗：FK_UserRole_RoleID

2009-06-22 22:50 | hxmhj

#30楼 　回复　引用　查看　

顶一个,期待楼主继续.
2009-06-22 23:36 | trenhui

#31楼 　回复　引用　查看　

期待你把权限、工作流结合起来讲讲。
2009-06-22 23:38 | trenhui

#32楼 　回复　引用　查看　

--引用--------------------------------------------------
slfafasfjal;j;: 楼主就是比JSHY大度!

--------------------------------------------------------

多谢提醒，我也确实应该改一改这个毛病了，应该大度大度，哈哈。

谢谢哦。
2009-06-23 07:13 | 金色海洋（jyk）

#33楼 　回复　引用　查看　

我对角色与权限的看法。

一个账号最好对应一个角色，尽量避免使用多重角色，如果确实需要，不如重新创建一个新角色。这样，后期的业务变更，或升级就不会成为负担了。

角色是权限的一个集合，如果使用了角色，那只对角色审核就可以了，实在没有必要再是去审核权限。

角色的设置与业务相关，系统完成后，角色基本也就定型了，不会象超市买东西一样，想要什么管理员就给你什么！你看银行一排排的储蓄员，她们的账号虽然不同，但角色或权限全都是一样的。

用户可以申请权限，现实中不是这样的。

举个大家都可以见到的例子：

在超市的收费口，收费员一上班开机，用自己的身份卡刷一下，系统进行确认后，允许使用。

可是，这收费员只能往里刷商品，不能取消。如果，有客户在刷过后不想要了，这时收费员就会招来她们的组长。这组长会用他自己的卡刷一下，然后取消不想要的商品。

这组长的卡，就具备删除这个记录的权限。但这并不是随便审请来的，而是系统开发时就这样设计的。

同样，在银行我们也经常见到，储蓄员在操作过程中，经常召过他们的负责人，用卡刷一下，还敲入密码进行确认。这都是系统在做某些重要操作时，从安全角度进行设计的。

所以，权限设计是非常严肃、严谨的，不可能是通用与万能的！

如果有人非要咬文嚼字，那就只能给他Administrator权限。可这和没有权限有什么区别呢？

2009-06-23 07:40 | hxmhj

#34楼 　回复　引用　

有些入门级
2009-06-23 08:06 | Dominic[未注册用户]

#35楼 　回复　引用　查看　

@hxmhj
用户可以申请权限，现实中不是这样的
-----------------------------
我們公司就是可以申請權限的。我們是for企業服務，有很多系統，有很多不同廠的user，上線時是一塊一塊上線的，職位也是可以調動的，因此權限也是不斷地在申請和取消的~~

所以做管理軟件不要輕易下結論，很多時候，大家的知識隻局限於自己所知的那一塊，殊不知以經驗設計通用軟件最易失敗。

我的建議是，如果想做通用的東東，首先應做到最底層的抽象，然後在此抽象的基礎上，定義一個規則，並且在這個規則上建立起一套程式。

而在使用時，首先應評估當前的業務需求是否符合你的規則，如果不符合，就不能簡單的套用，或修改你的抽象，或修改你的程式（當然代價可能非常大），這也就是常說的做技術的，如果十分熟悉業務流程，將能最大程度地保証軟件的成功。

像權限設計，最忌就是user表的設計，你隻不過是做權限而已，管我user表如果設計呢？
user到時我會給你（當然在aspx或asmx中如果取得，會給你適當的API），然後你要做的就是給你user後，你按你的權限規則管控我的登錄用戶的權限即可。

至於user與角色的對應，那是抽象上的一套規則而已。如果我的系統足夠簡單，我就是有一個user表，了了的幾個用戶，你還要我建立角色表，角色用戶關聯表，我想真得懶得理你~~

現在很多企業都有自己的user表或權限表，以及以前的系統，在推通用權限時，最簡單的方式，就是無縫接入當前系統，想完全按照你的設計，推翻重來，想想成本吧

sorry,一大堆，樓主看看即好，不用太介意。。。

2009-06-23 08:16 | Kevin Zou

#36楼 　回复　引用　查看　

up
2009-06-23 08:30 | 风枫峰

#37楼 　回复　引用　查看　

申请权限这个想法不错，下次写系统的时候考虑。要不然权限都要管理员来开很确实很麻烦
2009-06-23 08:30 | san.

#38楼 　回复　引用　

楼主老了，过时了。
嘎嘎~
2009-06-23 08:43 | 孤狼/(^o^)/~ [未注册用户]

#39楼 　回复　引用　查看　

To Kevin Zou

朋友：

我是非常不愿意卷入口水战中的，所以我的第一句就是：我对角色与权限的看法。

仔细读了你的帖子，说的也很有道理。可是，也象你说的，我们都有自己的不同经历，认识也不会相同。就此一点，大家才有交流的必要！

就我自己的经历，非要说权限的申请，不如说权限的变更。这是因为权限的变更不是经常发生的！

譬如：某个人原先在仓库工作，他的账号被赋于仓库管理角色。后来，领导将他调到后勤工作。系统管理员在接到领导通知后，就将这个人的账号，从仓库管理角色中删除，然后，加入到后勤管理角色中。其它就什么也不用做了。

如果你认为这就叫申请权限，那我们也没有什么不一致的。

看你写的帖子，感到你也是一个高手。请你也帮着看一看，楼主的第一张图是不是有错误！

2009-06-23 09:07 | hxmhj

#40楼 　回复　引用　查看　

喜欢楼主的这篇文章，也喜欢hxmhj和Kevin Zou的讨论。这样才能共同提高 :)
2009-06-23 09:33 | 阿鹏

#41楼 　回复　引用　查看　

--引用--------------------------------------------------
吉日嘎拉: 接收 #14楼 的直踹，请把理由也踹出来一下呢。

--------------------------------------------------------
呵呵，内容不错，就是标题有点那啥……
2009-06-23 09:39 | pythonic

#42楼 　回复　引用　查看　

权限是非常重要的一个部分，但是更重要的是业务逻辑，也就是直接关系到价值的部分。
2009-06-23 16:47 | hoodlum1980

#43楼 　回复　引用　

楼主的第一张图的箭头方向确实是有问题的。
个人认为在权限控制这一块要想真正做到通用，是比较困难的，特别是要无缝接入另一个系统。权限控制开发中的一个难题是当涉及到具体的业务后，就会慢慢发现，需要特殊处理的代码太多，这样导致的一个问题是配置文件中的参数巨多无比。
不知道各位所使用权限控制系统是使用在何种场合的？就我所认知的而言，我们只是针对一群特定的用户。开发完一个系统后第一件事就是建组织机构、用户、角色、资源、菜单，再设置其相互之间的关系。
在我们这边，用户不能申请权限。更为严格的是，用户因为某种原因，账号被锁定了只能求助于管理员进行解锁。
2009-06-23 20:17 | testkk[未注册用户]

#44楼 　回复　引用　查看　

To testkk

第一感觉，您是一个富有实际经验的人！

权限是建立在具体应用上的，而不是什么人、人、人的。没有实际经验的人，才老会这么想人、人、人的。

没有具体的应用，或具体的应用还没有成型，就奢谈什么权限，甚至通用之类的话题......

2009-06-23 21:21 | hxmhj

#45楼 　回复　引用　

--引用--------------------------------------------------
hxmhj: 主键是聚集索引，是记录的物理排序方式。不要说是用nvarchar了，就是用char都是极大的不合理。这将大大地损害数据库的性能！

--------------------------------------------------------
这个要看具体情况，如果char字节比较大，确实不太适合，但是你的表中用到最多的就是那个char字段，你不大可能固执的使用int吧
聚集索引用在有用的字段上，这个最重要
2009-06-26 11:31 | elevenbus[未注册用户]

#46楼 　回复　引用　

说不定是自己骂自己，赚了人气，否则你可以谢谢骂你的人，哈哈
2009-09-10 13:07 | 说不定是自己骂自己[未注册用户]

#47楼 　回复　引用　查看　

删除权限使用无效标记应该是比较通用的做法。
2009-10-15 16:44 | 迭戈_Forever

#48楼 　回复　引用　查看　

我觉得你的思路不错。和我想的很像。
2010-01-04 13:03 | Harold Shen

#49楼 　回复　引用　查看　

该篇未找到错别字