大恶人吉日嘎拉之走火入魔闭门造车之.NET疯狂架构经验分享系列之(四)高效的后台权限判断处理
2009-06-22 18:04 通用C#系统架构 阅读(7398) 评论(49) 编辑 收藏 举报
一般一个用户都有个默认的岗位,例如我是项目经理,那项目经理应该
有啥权限等。我们设计时考虑到了复杂情况,一般会设计为一对多关系,
但是日常生活中,大部分情况下,导入导出数据时,都希望获得一个单
一的关系,例如这个人默认的角色是啥?当然为了满足复杂情况,还有
一对多的的关系。所以我们设计权限时,一般在用户表里加一个默认角
色字段。
虽然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