使用父/子关系构建 Zend_Acl 和 CRUD

发布于 2024-10-13 13:09:59 字数 976 浏览 3 评论 0原文

我想知道我应该如何构建具有父/子关系的 CRUD 的 ACL。

例如。项目有 TodoLists。 TodoLists 有 Todos

项目有各种控制器操作

  • /projects/add
  • /projects/edit/{projId}
  • /projects/delete/{projId}
  • /todo-lists/add/{projId}
  • /todo-lists/edit/{todoListId}
  • ...

正如您所看到的,沿着层次结构向下,某些操作的 id 不引用自身(例如,todo-lists 控制器 -> todo-list 资源),而是引用其父级

因此,我已经进行了设置(通常),它看起来像这个

  • ACL 控制器插件 (preDispatch)
    • 将角色设置为已登录用户或“未经身份验证”
    • 将资源设置为控制器名称
    • 为操作名称设置权限
    • 如果设置了请求参数“id”,则获取实现 Zend_Acl_Resource_Interface 的实际实体(我正在使用 Doctrine ORM)。这就是复杂性出现的地方。我通常会从控制器名称获取资源,但是例如。对于 /todo-lists/add 我必须知道要获取父实体(项目)。通过此设置,我将不得不将权限更改为“addTodoList”之类的内容。这样,项目 acl 断言类将拥有 TodoLists 的东西。控制器操作和控制器操作之间也会存在脱节。 ACL 逻辑。这样可以吗?

也许我应该在 ProjectsController 而不是 TodoListsController 中添加 addTodoListAction ?这将简化我的 ACL 代码,我不需要检查和修改资源/权限?我可以直接从请求参数(控制器和操作名称)中获取这些。

你如何设置这样的 ACL?

I am wondering how should I structure my ACL for CRUD with Parent/Child Relations.

Eg. Projects have TodoLists. TodoLists have Todos

There are various controller actions for project

  • /projects/add
  • /projects/edit/{projId}
  • /projects/delete/{projId}
  • /todo-lists/add/{projId}
  • /todo-lists/edit/{todoListId}
  • ...

As you can see going down the hierarchy, some actions have ids that refer not to themselves (eg. todo-lists controller -> todo-list resource) but to their parent

So with with I have setup (generally), it looks like this

  • ACL Controller Plugin (preDispatch)
    • Set role to loggedin user or 'unauthenticated'
    • Set resource to controller name
    • Set privilege to action name
    • if request param 'id' is set, get the actual entity (I am using Doctrine ORM) that implements Zend_Acl_Resource_Interface. Here is where the complication arises. I will usually get the resource from the controller name, but for eg. with /todo-lists/add I must know to get the parent entity instead (Project). With this setup, I will have to chage the privilege to to something like 'addTodoList'. This way, the project acl assertion class will have to TodoLists stuff. There will also be a disconnect between Controller Actions & ACL Logic. Is that ok?

Maybe I should have addTodoListAction in ProjectsController instead of TodoListsController? This will simplify my ACL code, I won't need to check and modify resource/privileges? I can just take these directly from the request params (Controller & Action names).

How do you setup ACL's like this?

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

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

发布评论

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

评论(1

枫以 2024-10-20 13:09:59

使用 Zend_Acl_Assertion ,为projectid和todoId创建断言。在授予权限时

$myAcl->allow($role,'projects','edits',new My_Project_Assertion());

,您不能使用操作“addTodoListAction”,因为大写字母(或定义您自己的调度程序)addtodolistAction wd 工作;

use Zend_Acl_Assertion , create your assertion for projectid and todoId. At the time of giving permission do

$myAcl->allow($role,'projects','edits',new My_Project_Assertion());

and you cannot use action "addTodoListAction" because of captial letters (or define your own dispatcher) addtodolistAction wd work;

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