该帖已经被评为精华帖
|
|
---|---|
作者 | 正文 |
发表时间:2012-04-21
好帖,关于数据权限这块是个难点。
|
|
返回顶楼 | |
发表时间:2012-06-16
最后修改:2012-06-16
你一直在反驳别人有关RBAC的观点,我是初学者,在我看来RBAC是一种权限控制的思想。 我也不知道什么标准,大神,你给我们普及下呗 |
|
返回顶楼 | |
发表时间:2012-06-16
最后修改:2012-06-16
ltian 写道 liyi830813 写道 其实我觉得角色需要重新定义一下内涵,他到底指代的是一种身份,还是权限的容器,这是值得探讨的。在RBAC中,我们经常会面对如下的困境,一个用户面对多个角色,一个角色对应多个权限描述,而角色与角色间可能出现权限重叠、矛盾的情况,在设计和代码处理不好的情况下,系统权限设计往往陷入设计之初目标非常远大,实际实现往往不尽人意,所以权限开发也成为了重复开发最多的部分。
我认为这正是角色在充当权限容器时的问题,由于角色间接的将一个实际用户分为了不同的人格,举个例子说如果我要求某功能在某角色下可以操作某界面元素,而在某角色下不能操作这个界面元素,而这两个角色用户都要拥有,请问你该怎么设计?在进入这个功能时,你对权限的判断如何? 所以我认为角色其实充当的是用户的业务身份,而不是权限容器,用户才是权限的容器,我们可以对承担某个业务角色的用户进行权限复用。比如我要复用我上一位领导的权限,那么我直接找这个领导的角色比如部门经理,然后列出部门经理所对应的具体用户,用户可以根据自己的认识直接选人复用权限就行了 兄弟你看过RBAC了吗? 你一直在反驳别人有关RBAC的观点,我是初学者,在我看来RBAC是一种权限控制的思想。 我也不知道什么标准,大神,你给我们普及下呗 |
|
返回顶楼 | |
发表时间:2012-06-19
看半天没看明白, 给给例子,能跑起来的, 咱看看呗
|
|
返回顶楼 | |
发表时间:2012-06-19
/** * 校验资源能否被指定的角色列表访问(只需满足某一个角色能够访问就行) * * @param string $uuid 资源标识 * @param array $role_ids * * @return boolean */ function aclVerify($uuid ,array $role_ids = null){ if (empty($uuid)) return false; $resource = $this->aclGetResource($uuid); // 未定义资源的缺省访问策略 if (!$resource) return false; // Core_App::writeLog($resource,'当前访问资源','debug'); /* * 校验步骤如下: * * 1. 先校验 资源本身 access 属性 * EVERYONE => true,NOBODY => false * 其它的属性在下面继续校验 * 2. 使用传入的角色id集合 * 3. 如果 角色集合不为null 则 HAS_ROLE => true , NO_ROLE => false;反之亦然 * 4. 如果资源 access == ALLOCATE_ROLES * 1. 从{ROLES_HAS_RESOURCES}表中获取 资源对应的角色id集合 * 2. 将给定的角色id集合 与 资源对应的角色id集合 求交集 * 3. 存在交集 => true;否则 => false */ $resource[App_Table_OrAclActions::$access] = $this->formatAclAccess($resource[App_Table_OrAclActions::$access]); // 允许任何人访问 if (App_Api_Acl::EVERYONE == $resource[App_Table_OrAclActions::$access]) return true; // 不允许任何人访问 if (App_Api_Acl::NOBODY == $resource[App_Table_OrAclActions::$access]) return false; $role_ids = empty($role_ids) ? NULL : array_unique($role_ids); /** * 允许 不带有角色的用户访问 */ if (App_Api_Acl::NO_ROLE == $resource[App_Table_OrAclActions::$access]) return $role_ids ? false : true; /** * 允许 带有角色的用户访问 */ if (App_Api_Acl::HAS_ROLE == $resource[App_Table_OrAclActions::$access]) return $role_ids ? true : false; // --- 对用户进行 资源 <-> 角色 校验 if ($role_ids){ foreach ($role_ids as $role_id){ if ( $this->aclGetRoleHasResource((int) $role_id,$uuid) ) return true; } } return false; } |
|
返回顶楼 | |
发表时间:2012-06-19
观望。。数据级别的还是比较复杂的
|
|
返回顶楼 | |
发表时间:2012-07-04
大家讨论的权限控制,大多数都是基于自己系统对应的业务。现在没有合适的通用各种业务的吗
|
|
返回顶楼 | |
发表时间:2012-07-04
此帖似乎很火热呀,楼主努力吧,让大家共同学习学习,呵呵!
|
|
返回顶楼 | |
发表时间:2012-07-09
数据级的权限,确实是比较复杂的,而且与系统的具体逻辑是紧密关联的,不同的系统的逻辑是不一样的,所以个人觉得完全做出一个通用的数据权限控制功能是不可能的,最简单而且最安全有效的办法就是在业务逻辑中进行判断,如果你自己的系统非常的规范,url命名、参数传递都很有规则,那么通过使用AOP或者是拦截器或者是过滤器之类的都可以实现一个在你的系统中好的权限控制功能,但是刚才说的是前提了
|
|
返回顶楼 | |
发表时间:2012-07-26
其实,我们公司大概是这样设计的:
用户 菜单 URI (ID, 优先级, 正规, W/R) 用户-菜单-URI URI: Filter 分那么多表, 虽然扩展性好点, 但你确定用户体验好? |
|
返回顶楼 | |