我在设计新的和相当大/复杂的网站时潜入RBAC。 我正在尝试使用biz规则来确定是创建任务还是仅创建操作。
现在，我已经阅读了大多数（如果不是全部）现有文档。当前的文档说“任务包括操作”。 This wiki文章说，不同的术语只是命名约定，唯一存在的限制是结构性 - 角色必须包括任务（或其他角色）;任务应包括操作（或其他任务），操作是不由其他实体进一步组成的原子术语。 我还阅读了“Agile web dev ...”和“Yii cookbook”书中的相关章节 - 两者都没有进一步阐述这个问题（至少从我的眼镜中可以看出）。
让我来看看我提出问题的例子。实际上，让我们使用类似于上面提到的大多数文档资源中演示的示例：假设我有一篇博文，我希望/需要让其作者能够“更新自己的帖子”。现在，为什么这应该是文档资源中常见的任务，而不是具有商业规则的操作？
我认为上面的问题揭示了“任务”的明确定义（当然在RBAC背景下）。
请帮我提炼出更好的RBAC任务定义。
编辑： 我被建议对上述术语的以下定义有助于以有用的方式概念化它们。简而言之，最简单的形式是： operations 是基本的构建块。它们是开发人员使用的材料，只有它们。开发人员组成操作的任务。 角色由任务组成，例如一组任务。角色和任务是网站管理员应该使用的 - 分配和撤销用户而不是操作。 这是查看和掌握这些实体（角色，任务和操作）的好方法。 您是否有另一种选择来进行不同的概念化？任何意见将不胜感激。
TIA！ 波阿斯。
答案 0 :(得分：3)
我说的与您在编辑问题时所做的相同。任务只是用户可以做的具有共同点的操作组合。所以你有例如操作oList，oView，oCreate和oUpdate这些是操作开发人员分配给访问控制的控制器操作，其中前两个只读取 - 而后两个人对数据有写访问权（这就是他们的共同点）。因此，您现在希望将这些任务组合到任务tInspect和tManage，这两个任务都包含2个操作，第一个可以列出和查看，第二个可以创建和更新。或者，您可以将tInspect作为tManage的子任务，以便拥有tManage的用户可以列出，查看，更新和创建，但通常您只需将其作为两个任务。
答案 1 :(得分：2)
关于角色的分类 - ＆gt;任务 - ＆gt;操作，它们本质上是一样的，你可以在代码中看到它们是CAuthItem类。我们主要从用户的角度对它们进行不同的命名。
操作仅供开发人员使用，并且代表最高级别的权限。
任务建立在开发人员的操作之上。它们代表RBAC管理员使用的基本构建单元。
角色由管理员构建在任务之上，可以分配给用户或用户组。
以上是推荐，不是要求。通常，管理员只能看到任务和角色，而开发人员只关心操作和任务。
检查出来：http://www.yiiframework.com/forum/index.php/topic/2313-rbac-confusion/page_p_16035#entry16035
答案 2 :(得分：1)
如果有两个用户 1）管理 2）用户
所以我们为更新页面设置了角色updatePost 和admin是updatePost的父级，因此管理员可以更新。 user具有updateOwnPost权限.updateOwnPost是具有bizrule.so的updatePost的父级，如果bizrule满足他可以更新