搜索makinacorpus / php-acl
PHP简单的ACL API
Requires (Dev)
- phpunit/phpunit: ^5.1
- symfony/security: ^3.1
This package is auto-updated.
Last update: 2024-09-10 22:06:21 UTC
README
这是一个实验场/沙盒项目。
这个API不是为了存储ACL，而是为了提供一个动态的运行时API，以收集资源ACL并检查它们的有效性。我确实有很多东西要在这里记录。
历史
PHP项目的简单ACL API。人们可能会问为什么还会有人编写另一个，这是一个合理的问题，除了它最初是一个纯粹的教育项目外，它今天已经成为一个完整的API，原因有很多
-
在教育研究中奠定了这个API的基础，发现大多数现有的ACL API并没有完全拥抱正确的命名概念；
-
它是框架无关的，尽管你可能需要花费相当多的时间来设置它，而不需要框架驱动的服务依赖管理；
-
它是在性能作为一级约束的情况下开发的；
-
它是存储后端无关的，尽管它可以用于没有存储的情况，并连接到动态事件驱动的ACL构建器：这意味着你可以使用API以可重复的方式在运行时编程定义ACL，就像你实现访问权限投票者一样。
这个库最初的用例是为了用某种可以用于任何不是实际Drupal节点的东西来替换Drupal的节点访问API，但又与Drupal节点访问API兼容。Drupal节点访问是一个完整的ACL系统，但没有任何共同的语言，这使得它很难理解：配置文件变成了权限，配置文件类型变成了领域，权限仅限于查看、更新和删除，条目是节点访问记录。
这个库旨在解决的第二个用例是通过Symfony的Security组件使用。这个组件深深集成到大多数Symfony框架中，为控制器和模板提供了一个外观，重新编写它将纯粹是浪费时间，而使用投票者系统集成它可以在Symfony框架中透明地使用。
最终，这个API被编写为框架无关、易于理解、性能良好，可以在Drupal和Symfony都透明地存在于同一运行时环境中使用。
概念
以下是基本的ACL术语表
-
计算机系统中的用户由其身份定义，但可能有多个配置文件（一个配置文件集）；
-
一个配置文件有一个类型（例如组、用户...）和一个标识符。例如，John Smith是用户12，属于管理员组，因此他有以下配置文件：(用户，12)和(组，管理员)；
-
资源是一个没有在这个API中任何含义的业务对象，它由一个类型（例如页面、文件...）和一个标识符标识。例如，在处理博客网站时，你可以有(博客条目，12)资源；
-
此API允许外部插件将条目附加到任何资源；
-
条目（或通用术语中的ACE）由一个配置文件和一组授予该配置文件的权限定义，例如(组，管理员) -> (读取，写入，删除)是一个有效的条目；
-
针对单个资源组合在一起的条目被命名为条目列表（或通用术语中的ACL）。
大多数ACL API都正确做到了，唯一例外是通常被遗忘的配置文件概念，它为了框架驱动概念（角色、用户...）的利益而被遗忘。