“任务”到底是什么?在 Yii 的 RBAC 中?

发布于 2025-01-07 05:03:04 字数 886 浏览 0 评论 0原文

我在设计新的、相当大/复杂的网站时正在深入研究 RBAC。 我试图弄清楚是否要创建一个任务或只是一个带有业务规则的操作

现在,我已经阅读了大部分(如果不是全部)现有文档。当前的文档说“任务由操作组成”。 这篇 wiki 文章指出,不同的术语只是命名约定,唯一存在的限制是结构性限制 - 角色必须包含任务(或其他角色);任务应该包括操作(或其他任务),操作是原子术语,不进一步由其他实体组成。 我还阅读了“Agile web dev...”和“Yii Cookbook”书中的相关章节 - 这两本书都没有进一步阐明这个问题(至少从我的眼镜来看)。

让我们来看我的例子,我将在其中提出问题。实际上,让我们使用与上述大多数文档资源中演示的示例类似的示例:假设我有一篇博客文章,我希望/需要其作者能够“更新自己的帖子”。现在,为什么这应该是文档资源中常见的任务,而不是具有业务规则的操作?

我认为上面的问题揭示了“任务”的不明确定义(当然是在 RBAC 上下文中)。

请帮助我为 RBAC 任务提炼出更好的定义。

编辑: 有人建议我对上述术语进行以下定义,以帮助以有用的方式概念化它们。简而言之,最简单的形式是:操作是基本构建块。他们是开发人员使用的材料,而且只有他们。开发人员在操作之上编写任务角色由任务组成,就像一组任务一样。角色和任务是站点管理员应该扮演的角色 - 分配和撤销给用户,而不是操作。 这是查看和掌握这些实体(角色、任务和操作)的好方法。 您还有其他选择来以不同的方式进行概念化吗?任何意见将不胜感激。

蒂亚! 波阿斯。

I'm diving into RBAC while designing new and rather big/complex site.
I'm trying to figure out if to create a task or simply an operation with biz rule.

Now, I've read most if not all existing documentation. The current documentation says that "a task consists of operations". This wiki article says that the different terms are simply naming conventions and the only limitation that exists is structural one - roles must include tasks (or other roles); tasks should include operations (or other tasks) and operations is the atomic term that is not further composed by other entities.
I've also read the relevant sections in the "Agile web dev..." and "Yii cookbook" books - both do not shed further light on this issue (at least as seen through my glasses).

Lets go to my example where I'll present the question. Actually, lets use an example similar to that demonstrated in most of the documentation resources mentioned above: Lets say I have a blog post and I want/need to have its author be able to "update own post". Now, why should this be a task as commonly demonstrated in the documentation resources and not an operation with a biz rule?

I think that the question above reveals the inclear definition of a "task" (in the RBAC context of course).

Please help me distill a better definition for an RBAC task.

EDIT:
I was suggested the following definitions of the mentioned terms that help conceptualize them in a useful way. In short and in its simplest form: operations are the basic building blocks. They are the material developers work with and only them. Developers compose tasks of and on top of operations. Roles are composed of tasks, like a set of tasks. Roles and tasks are what the site administrators should play with - assign and revoke to users but not operations.
That's a nice way to look and grasp those entities (roles, tasks and operations).
Do you have another option to conceptualize differently? Any comments will be appreciated.

TIA!
Boaz.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

你是我的挚爱i 2025-01-14 05:03:04

我想说的和你在问题编辑中所做的一样。任务只是用户可以执行的具有共同点的操作的组合。例如,您有 oListoViewoCreateoUpdate 操作,这些是开发人员分配给控制器操作的操作对于访问控制,前两个只能读取,后两个可以对数据进行写访问(这是它们的共同点)。因此,您现在想要将它们组合到任务 tInspecttManage 中,它们都包含 2 个操作,第一个可以列出和查看,第二个可以创建和更新。 (可选)您可以将 tInspect 设为 tManage 的子任务,以便拥有 tManage 的用户可以列出、查看、更新和创建,但通常您只需给他的角色分配这两项任务。

I'd say the same as you did in your question edit. A task is simply a composition of operations a user can do that have something in common. So you have for example operations oList, oView, oCreate and oUpdate these are the operation developer assigns to controller actions for access control, where the first two are only read- and the second two have write access to data (that's what they have in common). So you now want to combine those to tasks tInspect and tManage which both hold 2 operations, the first one can list and view and the second one can create and update. Optionally you could make tInspect a sub-task of tManage so a user that has tManage can list, view, update and create but normally you just give his role both tasks.

看春风乍起 2025-01-14 05:03:04

关于角色的分类->任务->操作,它们本质上是相同的,正如您在代码中看到的,它们属于 CAuthItem 类。我们主要从用户的角度对它们进行不同的命名。

  • 操作仅由开发人员使用,它们代表最细级别的权限。

  • 任务是建立在开发人员操作之上的。它们代表 RBAC 管理员使用的基本构建单元。

  • 角色由管理员构建在任务之上,并且可以分配给用户或用户组。

以上是建议,不是要求。一般来说,管理员只能看到任务和角色,而开发人员只关心操作和任务。

看看这个:http://www.yiiframework.com/forum/index.php/topic/2313-rbac-confusion/page_p_16035#entry16035

Regarding the classification of role -> task -> operation, they are essentially the same thing, as you can see in the code they are of class CAuthItem. We name them differently mainly from user point of view.

  • Operations are only used by developers and they represent the finest level of permission.

  • Tasks are built on top of operations by developers. They represent the basic building units to be used by RBAC administrators.

  • Roles are built on top of tasks by administrators and may be assigned to users or user groups.

The above is a recommendation, not requirement. In general, administrators can only see tasks and roles, while developers only care about operations and tasks.

Check this out : http://www.yiiframework.com/forum/index.php/topic/2313-rbac-confusion/page_p_16035#entry16035

我们只是彼此的过ke 2025-01-14 05:03:04

如果有两个用户
1)管理员
2)用户

,所以我们为更新页面设置角色updatePost。
admin 是 updatePost 的父级,因此 admin 可以更新。
用户拥有 updateOwnPost 权限。updateOwnPost 是带有 bizrule 的 updatePost 的父级。因此,如果 bizrule 满足,他可以更新

if there are two user
1)admin
2)user

so we set role updatePost for update page.
and admin is parent of updatePost so admin can update.
user have updateOwnPost permission.updateOwnPost is parent of updatePost with bizrule.so if bizrule satisfy he can update

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文