wemakecustom/symfony-acl-bundle

此包已被废弃,不再维护。未建议替代包。

Symfony ACL Bundle

dev-master 2016-05-13 21:20 UTC

This package is not auto-updated.

Last update: 2022-07-18 08:52:49 UTC


README

Symfony Acl Bundle

本组件旨在提供对 Symfony2 ACL 组件 的替代。

Symfony2 的 ACL 组件目前文档较少,扩展困难,且存在抽象层次不足的问题。

这些问题使得维护变得困难。在这种情况下,我们提供了一个新的替代方案,其抽象层是从头开始重新设计的,并提供了易于扩展的点。

此组件可以直接使用,只需使用 Symfony 核心库。或者与完整的全栈 Symfony2 框架一起使用。

此组件依赖于 5 个概念

  • ACL 和 ACEs,授予权益和目标
  • 权限,权限映射和属性
  • ACL 提供者
  • 投票者和访问授权策略

ACL 和 ACEs,授予权益和目标

ACL(访问控制列表)是一个 ACE(访问控制条目)的列表。

ACE 是一个三元组 [授予权益,目标,权限]。授予权益是权限授予的对象。目标是权限授予的对象。权限显然是授予的内容。

例如,[UserA,Post1,VIEW] 表示 UserA 被允许查看 Post1。

当然,ACL 系统内部使用了一个抽象层来表示授予权益和目标。但您不需要担心自己创建这些,ACL 提供者会为您处理一切。您只需要知道哪些可以作为授予权益或目标。

授予权益

授予权益被抽象为 SecurityIdentities。有三种安全身份

因此,可接受的授予权益包括

  • null,表示一个 匿名 身份。
  • 一个字符串,表示一个 角色 的名称。
  • 一个角色实例,表示一个 角色
  • 一个用户实例,表示一个 用户
  • 一个令牌实例,表示与令牌关联的 用户,如果没有此类用户,则为 匿名 身份。

任何实现了 UserInterface 的实现都将无缝地被 ACL 系统接受。用户通过其类和 ID(或如果不存在 getId() 方法,则为用户名)进行识别。如果您希望使用其他方式来识别您的用户,则应实现 AclSecurityObjectInterface

任何实现了 RoleInterface 的实现都将无缝地被 ACL 系统接受,只要 getRole() 返回一个字符串。如果您希望使用其他方式来识别您的角色,则应实现 AclSecurityObjectInterface

目标

目标被抽象为TargetIdentities。可以在4种目标上授予ACL。

  • 域对象(即你在应用程序中通常操作的对象)。
  • 域类(即一个普通对象的类)。
  • 域对象的字段(即在普通对象上的一个特定字段)。
  • 域类的字段。(即在普通类上的一个特定字段)。

因此,接受的目标包括

  • 一个字符串,表示一个的名称
  • 一个对象,表示一个对象
  • 一个包含两个元素的数组:一个对象和一个字符串,表示对象的字段的名称。
  • 一个包含两个字符串的数组:分别表示一个类及其字段的名称。

为了使对象被接受,它们需要实现AclTargetObjectInterface接口,或者具有一个getId()或一个__toString()方法。

注意:字段不需要是类内的实际属性,但它可以是任何字符串。这可以用来指定对象部分上的权限。

权限、权限映射和属性

Symfony的安全系统基于“属性”,这是传递给isGranted的第一个参数。

但是,授予的权限和属性之间的映射不是1:1。例如,根据Symfony2的ACL内置权限映射,如果你授予某人OPERATOR权限,你的意图是授予VIEWEDITCREATEDELETEUNDELETEOPERATOR属性。

因此,一个权限实际上表示了多个属性。这种对应关系是通过权限映射来处理的。为此,我们提供了一个对Symfony2的ACL内置权限映射的重新实现。

在完整的Symfony2框架中,权限映射可以通过以下方式获得

ACL提供者

ACL提供者是ACL系统中最核心的组件。ACL提供者是负责从后端存储(通常是一个数据库)检索ACE并为其提供便捷访问的对象。基本ACL提供者是只读的,但MutableAclProvider允许轻松修改ACL(即创建和删除ACE)。

投票者和访问授予策略

Symfony的安全系统基于一组投票者:每次调用isGranted时,都会调用一组投票者,直到其中之一决定授予或拒绝访问。

投票者会提供一个令牌(表示用户及其角色)、一个目标和一组属性。

ACL默认投票者检查当前用户或其任何角色是否被授予提供任何请求属性的权限。

然而,ACL的授权决策可能相当复杂。为了使这更容易,投票者不执行整个访问检查过程,而是将最终决策推迟到访问授予策略。

策略负责决定用户或角色是否被授予目标上的任何属性。

我们提供了5个内置策略

Plain

我们只检查目标ACE本身。因此,给定一个类C1和其一个实例O1,如果用户被授予对C1的访问权限,但权限没有明确授予到O1,他将不会获得权限。

元数据

我们检查对象及其类别的权限。如果用户在对象(或对象的字段)上没有任何权限授予,我们将尝试检查他们是否对类(或类的字段)有任何权限。

这是全栈框架中的默认策略。

字段擦除

我们检查字段、对象或类的权限。如果用户在对象的(或类的)字段上没有任何权限授予,我们将尝试检查他们是否对对象(或类)本身有任何权限。

继承

我们检查父类的权限。如果用户在类(或其字段)上没有任何权限授予,我们将尝试在其父类(或其字段)上进行检查。

复杂

此策略是后三个策略的混合。它主要用于作为您自己的策略的代码示例。请阅读源代码以获取更多详细信息。