大家都知道,现在的权限系统设计都是采用基于角色的权限管理设计理念。通过角色管理权限,而不是通过用户!但是现在有一个疑惑;假如一个用户同时拥有两种不同的角色A、B,而这两种角色对某一个模块分别具有不同的权限;比如A对某一个C功能模块具有查看功能,B角色对C模块不具有查看功能,那这样怎么判断当前用户是否对C功能模块具有的权限呢?
楼主要清楚一个概念,通常情况下,权限设计是按照白名单或是黑名单理论进行设计,
而不是同时使用两个概念进行设计。
就是说,权限是指角色A,你拥有ModuleOne的查看权限,角色B,不拥有ModuleOne的查看权限(注意不是禁止)。、
这是白名单设计法。取并集,允许访问。多个角色中有一个为TRUE,则为TRUE。
如果采用黑名单设计法,则是
角色A,没有禁止访问ModuleOne, 角色B,禁止访问ModuleOne,
同样也是取并集,禁止访问。多个角色中有一个为TRUE,则为TRUE。当然这儿TRUE表示禁止访问。
如果要采用黑白名单并用的设计方法,则通常是黑名单优先。(当然,你如果愿意,也可以白名单优先)
就是说上了黑名单,你其他角色有啥权限都没有用了,一概禁止。
1个角色对应多个权限,那判断是否有对应的操作权限,就 判断这个人对应的角色的权限有哪些。。。
假如一个用户同时拥有两种不同的角色A、B,而这两种角色对某一个模块分别具有不同的权限;比如A对某一个C功能模块具有查看功能,B角色对C模块不具有查看功能,那这样怎么判断当前用户是否对C功能模块具有的权限呢?
@422159763:
你要注意一个用词的意思:
B角色对C模块不具有查看功能,
不具有这个词语,在中文中的意思是,没有。而不是禁止。
你明白了这一点,就会知道你所理解的权限体系,他是基于白名单设计理念的。
A ModuleC can access
B ModuleC can not access <> forbid to access (这两个不相等)
A+B can access
你应该问提这个需求的人,他到底是想让该用户查看该功能,还是不想让该用户查看。
用户除了从角色继承权限以外,用户还有自己的专有权限,我们会规定用户的专有权限优先级高于继承的角色的权限。
用户还有自己的专有权限
那还弄个角色干嘛?我觉得是不是有违背当初设计的初衷
@422159763: 错,这恰恰是对基于角色的权限系统的完善。比如你提到的这个需求,就能用此方法来解决。用户的专有权限可以用来解决需求中的特例问题。
@Launcher: 没必要专有权限吧。
@angelshelter: 我很想从几个方面来阐述下,但是我发现 kylin.chen 建议楼主理解下 Windows 的权限系统设计,因此我建议你也这么做。
这个就看你们怎么设计了。两种方式:最小模式和最大模式,最小模式是只要某用户的任意一个角色没有A权限,那么用户就没有A权限;最大模式是只要某用户的任意一个角色具有A权限,那么用户就具有A权限。
------
仅供参考。
一般取并集。(实际看需求方)
A,B中任一角色具有功能C模块的权限,则该用户有C的权限。
就是说用户的所有角色都没有C模块的权限的话,才表示该用户没有C模块的权限
比如有“超人”,“人” 角色, “人”不会飞, “超人”会飞,
superMan 同时具有“超人”和“人” 角色,你说superMan会不会飞,哈哈。
举的例子很入骨!很好,很深刻!
通过用户Id找到用户的角色,通过用户的角色集合遍历用户的权限集合D,然后对C模块所在的权限进行比对,最后整理出一个集合进行,但这个比对后的集合要遍历处理其中比如C模块权限和D权限,最后在权限管理中写个接口传递参数userId,List<D>,如果在list遍历D集合中有何C模块权限一致相等操作,就让用户去查看,如果这个权限结合D中没有,就不让其查看。这只是增加接口的方法来处理,当然也可以改变数据表接口增加字段处理比较好,用用户的专有权限和扩展权限来处理或者用户的最大或最小来进行设计处理这个你可以去网上搜搜。。。
好好理解一下windows的用户权限问题,就明白了,你天天对着windows,这个应该更好理解吧。
如果你只是想实现功能,简单,权限合并呗。把所有角色遍历一遍,看有没有权限,有的话,就给呗。