【问题标题】:Module permission vs role permissions in silexsilex中的模块权限与角色权限
【发布时间】:2017-01-21 20:40:42
【问题描述】:

我对 symfony/silex 中的 ACL 以及如何让它们为我工作感到很困惑。

我一直在考虑基于模块 -> 操作的解决方案。但是,阅读 ACL 时,一切似乎都基于角色,这对于我想要实现的实现来说是广泛的。

我将拥有用户,并且所有用户都属于一个角色(管理员、用户等...)。但是,该角色更多地是您可以执行的操作的指南(因为它设置了具有该角色的用户开始使用的默认权限)用户可以执行的一组实际操作。这些操作实际上是基于系统拥有的模块以及实际授予任何用户读取、添加、更新删除以及这些之外的任何其他动词的权限。

例如: 角色 #1:是管理员

  • 可以读取用户
  • 可以发布用户
  • 可以放用户
  • 可以删除用户

角色 #2:管理员

  • 可以读取用户
  • 可以发布用户
  • 不能放用户
  • 无法删除用户

由于我计划拥有多个不同的模块(用户、支付、产品等),并且每个管理员都可以授予或撤销权限,因此它们不适合 ROLE_ADMIN、ROLE_SUPER_ADMIN、ROLE_USER 类型的角色。

我在考虑 ROLE_VIEW_USERS、ROLE_ADD_USERS、ROLE_EDIT_USERS 行,一个用户可能会拥有 100 个这些小角色,并且每个控制器都有投票者来决定您是否可以执行某些操作。

这有意义吗?

【问题讨论】:

    标签: symfony silex


    【解决方案1】:

    您混淆了 ACL 和角色。它们都与权限有关,但它们的处理方式和功能彼此不同。

    角色本身并不与特定资源相关联。另一方面,ACL 是,并且该链接是持久的。用户可以通过使用选民与资源绑定(或看起来如此)。

    https://symfony.com/doc/current/security/voters.html#creating-the-custom-voter

    用户特定的 ACL,例如如果用户具有特定访问权限定义的 PER 资源,您将需要更多的东西。

    看看 SF 食谱:

    https://symfony.com/doc/current/cookbook/security/acl.html https://symfony.com/doc/current/cookbook/security/acl_advanced.html

    所有者/主人/操作者可以

    • 编辑
    • 查看
    • 删除
    • 创建

    所有资源(使用角色完成)


    ROLE_USER 可以

    • 编辑自己的
    • 查看自己的
    • 删除自己的
    • 创建

    OWN RESOURCES(这部分是用 ACL 或 voter 完成的)

    选民实际上是在创建您自己的 ACL,因此除非您明确地创建一个,否则没有永久权限(此时我会使用 ACL)。 ACL 的用例与选民的用例基本相同,选择一个还是另一个是一个复杂的问题。

    内置 ACL 信息来自数据库,但根据 SF 文档:“它可以包含数千万条 [记录] 而不会显着影响性能。”

    非常简单?可以使用选民。

    如果您不想为资源维护自己的规则(投票者)并且不介意 ACL 的复杂性,或者喜欢持久化 + 缓存权限,您可以改用 ACL。

    请注意,创建资源时ACL的复杂度一般如下(虽然这可以放在服务中):

    $aclProvider = $this->get('security.acl.provider');
    $objectIdentity = ObjectIdentity::fromDomainObject($resource);
    $acl = $aclProvider->createAcl($objectIdentity);
    $tokenStorage = $this->get('security.token_storage');
    $user = $tokenStorage->getToken()->getUser();
    $securityIdentity = UserSecurityIdentity::fromAccount($user);
    $acl->insertObjectAce($securityIdentity, MaskBuilder::MASK_OWNER);
    $aclProvider->updateAcl($acl);
    

    对于前面的场景,您可以使用 ROLE_USER 来确保经过身份验证的用户实际上是实际用户,而不是 AUTHENTICATED_ANONYMOUSLY 和投票者或 ACL 来确保他们只能编辑自己的资源,如果他们的 ROLE是 ROLE_ADMIN。 (假设用户在注册后获得 ROLE_USER)

    security.yml 中的示例

    # This could be done via @Secure(roles="ROLE_USER")
    access_control:
        - { path: ^/my/api/endpoint, role: IS_USER, requires_channel: https }
        - { path: ^/my/admin/api/endpoint, role: IS_ADMIN, requires_channel: https }
    

    controller::action 中的示例

    // check for edit access
    if (
        false === $authorizationChecker->isGranted('EDIT', $resource) &&
        false === $this->get('security.context')->isGranted('ROLE_ADMIN')
    ) {
        throw new AccessDeniedException();
    }
    

    这是 StackOverflow 中的另一个 QA,它也提供了一些示例:

    Symfony 2 ACL and Role Hierarchy

    你也可以对这些东西使用注解:

    https://symfony.com/doc/current/best_practices/security.html#authorization-i-e-denying-access(它显示了一个与另一个的工作方式)。

    如果其中任何部分需要进一步解释,请告诉我。

    谢谢。

    【讨论】:

      猜你喜欢
      • 2014-09-15
      • 2016-08-24
      • 1970-01-01
      • 1970-01-01
      • 2014-02-03
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多