权限管理,大都离不了这几个概念
用户 user
角色 role
权限 permission
有些还加上了
组 group
这种经典的结构被windows,数据库等大量应用,故很多系统基本也是用这种架构
之前有人写过通用权限管理,上图先
从图可以看出,这种结构一个user的权限来自与
1 该user直接拥有的权限
2 该user所属role拥有的权限
3 该user所属group拥有的权限
表面上看还是很简单的,但如果允许role和group自包含,那就复杂了
其实,如果role能够自包含,也不需要group了
反映到代码上,这种没有限制的包含关系,必将使用递归来遍历到所有的权限
虽然复杂,但是对一个学好了数据结构的人,还是不难的,比汉诺塔简单哈^_^
言归正题,对以一般的MIS系统,正常来说,这样的设计结构是绝对的够用的
我的经验,页面200个左右,用户500~1000,部门20~50个,如果让设计人员来规划权限,绝对能控制到一个很精炼的地步
组的话不会超过10个,角色有30个以内
这样的前提是控制权限的是开发者本人,对整个系统有全局的认识~
但是事实是,权限开放可能是交给非开发者本人,而且已经经过了好几任,权限申请时遇到跨角色的情况不想去查看是否能组合而随便的新建一个角色
时间一长,角色数目剧增,可能几个角色都拥有几乎相似的权限,而且也不敢轻易的删除某一个角色
对自己公司的权限模块,我预计做一些优化,孰优孰劣,使用时间长了才知道
定下的规则如下
1 禁止自包含,很犹豫,自包含功能强大,但是同时也是混乱之源,权衡后,禁用之,至少在界面上看的清晰,而且代码复杂程度大为降低
2 引入部门概念,以取代组,一个用户只有一个部门;引入部门的概念是来源于之前公司的系统,在新增人员信息,指定了部门之后,就自动拥有一些该部门员工固有的权限,省去2次分配
3 权限归属部门,指定部门key user赋权,这有点仿照于oracle的权限管理,部门key user拥有该部门所涉及的所有权限,并可以分配给其他人
这样的好处是把权限的分配切割到部门,一个user的权限可以让不同的部门组合完成,各个key user管理的范围较小,可以把权限管理更"精致"
但是缺点是,如果key user 都不负责,那就是一场大噩梦
总的来说,权限管理的开发是相对简单的,但是后期的使用和管理才是大问题
只有一个目的,就像软件开发一样,让权限管理也能达到某个可控的粒度;先追求可控的基础上,在追求精炼!
