Symfony2 - ACL 和角色

Question

我的网站包含 3 种类型的用户，它们可能具有不同的角色。

ROLE_TRAINEE

ROLE_COMPANY_SUPER_ADMIN, ROLE_COMPANY_ADMIN, ROLE_COMPANY_TUTOR, ROLE_COMPANY_GUEST

ROLE_UNIVERSITY_SUPER_ADMIN, ROLE_UNIVERSITY_ADMIN, ROLE_UNIVERSITY_COORDINATOR, ROLE_UNIVERSITY_GUEST

根据角色，我知道他们可以进入哪些页面，哪些页面不能使用security.yml access_control 块。

access_control:
        - { path: ^/$, roles: IS_AUTHENTICATED_ANONYMOUSLY }
        - { path: ^/login, roles: IS_AUTHENTICATED_ANONYMOUSLY }
        - { path: ^/trainee, roles: ROLE_TRAINEE }
        - { path: ^/company, roles: ROLE_COMPANY_GUEST }
        - { path: ^/university, roles: ROLE_UNIVERSITY_GUEST }

现在我要区分每个用户可以执行的操作：EDIT、DELETE 等等。

我检查了 ACL 文档，我完全搞砸了。我看到我可以通过调用isGranted() 来使用 ROLES 完成所有操作。无论如何，我想听听你们对 ACL 的看法？在我的情况下有必要吗？使用 ACL 的主要优势是什么？

Answer 1

这取决于应用程序的类型。

我测试了 ACL，但我个人从未在我的应用程序中使用过，而是使用了 Voters。 ACL 是现成可用的机制，如果你了解它的工作原理，它可以成为强大的工具（非常先进）。

---

角色

要检查一些基本权限，您将使用ROLES - 例如->isGranted('ROLE_ADMIN')

正如您所说，如果您没有任何子资源，这就足够了。如果您创建简单的系统，这种方式很好。排名：GUEST、EDITOR、MODERATOR、ADMIN等。易于阅读、理解和管理。

正如你所说，可以使用ROLES 来检查资源权限，但对我来说（个人）使用ROLES 来保存此类信息，例如“他可以阅读和编辑产品”是脏的。我认为存储ROLES 的“军队”并不是最好的主意。这是一个例子：

因为您不需要声明 ROLES，所以可以创建如下内容：

$resource_type = "PRODUCT";
$id = 3;
$role = "ROLE_".$resource_type."_".$id."_EDIT";
->isGranted($role);

在此示例中，您检查用户是否具有角色 ROLE_PRODUCT_3_EDIT。 当用户创建新产品时，他获得了管理其资源的角色，您可以稍后查看。例如，他可以获得这组角色：

ROLE_PRODUCT_3_EDIT,ROLE_PRODUCT_3_READ,ROLE_PRODUCT_3_DELETE 或 ROLE_PRODUCT_3_OWNER

这只是一个例子，你可以用不同的方式来做，但它显示了 ROLES 的问题。 如果您的用户创建了许多资源，他将获得许多、许多、许多角色...... 另外这个方法有一些缺陷——例如你不能改变资源类型（PRODUCT）或者ID——如果你这样做了，你的整个权限系统就会被破坏。

ACL

在使用它之前，您必须了解它是如何工作的 :) 我认为这个规则应该在任何地方都使用，但对于ACL，这是非常非常重要的。

Symfony ACL 文档很清楚。

在复杂的应用程序中，您经常会面临访问问题 决定不能仅基于请求的人（令牌） 访问，但还涉及访问正在被访问的域对象 要求。这就是 ACL 系统的用武之地。

就是这样。内置ACL，即用型安全系统，功能非常强大，但正如作者所说：

使用 ACL 并非易事，对于更简单的用例，它可能是 矫枉过正。如果您的权限逻辑可以通过编写来描述 一些代码（例如，检查博客是否由当前用户拥有），然后 考虑使用选民。投票者通过了被投票的对象， 您可以使用它来做出复杂的决策并有效地实施 您自己的 ACL。执行授权（例如 isGranted 部分）将 看起来与您在此条目中看到的相似，但您的选民类别将 处理幕后的逻辑，而不是 ACL 系统。

如果您了解如何使用ACL 非常容易使用，您甚至不需要创建任何特殊的数据库表或类。

选民

如果您阅读ACL 代码，您会发现ACL 是基于Voters 构建的。 You can do very complicated permission system with Voters. Voter 是处理资源高级权限的好主意 - 例如，如果您的用户是 OWNER 或站点 ADMIN，则您的用户可以 EDIT 发表评论。

简而言之 - 您的权限取决于许多条件的所有情况。 使用Voters，您可以轻松创建基于等级的权限系统。

• （实体）User 具有（实体）Rank。
• （实体）Rank 具有一组（字符串）ROLES。
• ROLE 给你一组（字符串）PERMISSIONS。

您可以管理用户Rank 并更改等级权限以更改其角色。结果，所有具有此等级的用户都获得了新的权限。

---

简而言之 - 如果您有实体资源（文档系统），Voter 或 ACL 是个好主意。请记住，您可以同时使用 ROLES 和 Voters。 ACL 非常适合实体资源。 Voter 可用于更复杂的情况，其中用户需要基于某些特殊情况（和正常情况）的权限。