PHPackages wemakecustom/symfony-acl-bundle - PHPackages - PHPackages [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register) 1. [Directory](/) 2. / 3. [Security](/categories/security) 4. / 5. wemakecustom/symfony-acl-bundle AbandonedLibrary[Security](/categories/security) wemakecustom/symfony-acl-bundle =============================== Symfony ACL Bundle 6472PHP Since May 13Pushed 9y ago6 watchersCompare [ Source](https://github.com/wemakecustom/symfony-acl-bundle)[ Packagist](https://packagist.org/packages/wemakecustom/symfony-acl-bundle)[ RSS](/packages/wemakecustom-symfony-acl-bundle/feed)WikiDiscussions master Synced 2mo ago READMEChangelogDependenciesVersions (1)Used By (0) Currently not maintained ======================== [](#currently-not-maintained) Symfony Acl Bundle ================== [](#symfony-acl-bundle) This bundle is intended to provide a replacement to the [Symfony2 ACL Component](http://symfony.com/doc/current/cookbook/security/acl.html). Symfony2's ACL Component is currently weakly documented, hard to extend, and present a leaky abstraction. All of these issues makes it hard to maintain. In this context, we offer a new alternative, whose abstraction layer has been redesigned from scratch and offering easy extension points. This component can be used either directly, requiring only the Symfony Core to be used. Or with the full-stack Symfony2 framework. This component is relying on 5 concepts: - ACL and ACEs, Grantees and Targets - Permissions, Permission Map and Attributes - ACL Provider - Voter and Access Granting Strategies ACL and ACEs, Grantees and Targets ---------------------------------- [](#acl-and-aces-grantees-and-targets) An ACL (Access Control List), is a list of ACEs (Access Control Entry). An ACE is a triplet \[Grantee, Target, Permission\]. The Grantee is whom the permission is granted to. The Target is what the permission is granted on. The permission is obviously, what is granted. For example, \[UserA, Post1, VIEW\] would mean that UserA is allowed to VIEW Post1. Of course, the ACL system is internally using an abstraction for Grantees and Targets. But you don't need to worry about creating these yourself, the ACL Provider will take care of everything for you. You only need to know what is accepted as a Grantee or as a Target. ### Grantees [](#grantees) Grantees are abstracted away as SecurityIdentities. There are three kinds of security identity: - Anonymous, which will be used for anonymous users. - [Role](http://symfony.com/doc/current/book/security.html#roles). - [User](http://symfony.com/doc/current/book/security.html#users). Thus, accepted grantees are: - `null`, denoting an *Anonymous* identity. - A string, denoting the name of a *Role*. - A Role instance, denoting the *Role*. - A User instance, denoting the *User*. - A Token instance, denoting the *User* associated to the Token, or an *Anonymous* identity if there is no such User. Any implementation of [UserInterface](http://api.symfony.com/2.4/Symfony/Component/Security/Core/User/UserInterface.html)will be seamlessly accepted by the ACL system. The User is identified using its class and ID (or Username if there is no `getId()` method). If you prefer to identify your User using something else, you should implement [AclSecurityObjectInterface](src/Model/AclSecurityObjectInterface.php). Any implementation of [RoleInterface](http://api.symfony.com/2.4/Symfony/Component/Security/Core/Role/RoleInterface.html)will be seamlessly accepted by the ACL system, as long as `getRole()` returns a string. If you prefer to identify your Role using something else, you should implement [AclSecurityObjectInterface](src/Model/AclSecurityObjectInterface.php). ### Target [](#target) Targets are abstracted away as TargetIdentities. ACLs can be granted on 4 kinds of targets: - A Domain Object (i.e. an object you usually manipulate in your application). - A Domain Class (i.e. the class of an usual object). - A Domain Object's field (i.e. a given field on an usual object). - A Domain Class' field. (i.e. a given field on an usual class). Thus, accepted target are: - A string, denoting the name of a *Class* - An object, denoting the *Object*. - An array of two elements: an object and a string, denoting the name of the *Object's field*. - An array of two strings: denoting the names of, respectively, *a Class and its Field*. For objects to be accepted, they need to either implements [AclTargetObjectInterface](src/Model/AclTargetObjectInterface.php), have a `getId()` or a `__toString()` method. N.B.: A field doesn't need to be actually a property within the class, but it could be any string. This could be useful to specify permissions on parts of an Object. Permissions, Permission Map and Attributes ------------------------------------------ [](#permissions-permission-map-and-attributes) Symfony's Security system is based on "attributes", this is the first parameter given to [isGranted](http://symfony.com/doc/current/book/security.html#access-control). However the mapping between granted permissions and attributes is not 1:1. For example, following the [Symfony2's ACL Built-in Permission Map](http://symfony.com/doc/current/cookbook/security/acl_advanced.html#built-in-permission-map), if you grant someone the `OPERATOR` permission, your intent is to grant `VIEW`, `EDIT`, `CREATE`, `DELETE`, `UNDELETE` and `OPERATOR` attributes. Thus, one permissions actually denotes several attributes. This correspondance is taken care of through the Permission Map. To this end, we provide a re-implementation of the Symfony2's ACL Built-in Permission Map. In the full stack Symfony2 framework, the permission map is available through ACL Provider ------------ [](#acl-provider) The ACL Provider is the most central item of the ACL system. The ACL Provider is the object responsible for fetching the ACEs from a backend storage (usually a database) and providing easy access to them. A basic ACL Provider is considered Read-Only, but the MutableAclProvider allows easy modification of the ACL (i.e. creation and deletion of ACEs). Voter and Access Granting Strategies ------------------------------------ [](#voter-and-access-granting-strategies) Symfony's Security system is based on a set of [Voters](http://symfony.com/doc/current/cookbook/security/voters.html): each time `isGranted` is called, a set of voters are called until one decides on granting or denying access. A Voter is provided with a Token (denoting a User and its Role), a Target and a set of Attributes. The ACL default voter check if the current User or any of its Roles is granted a permission providing any of the requested Attributes. However, granting decisions for ACL could be quite complex. To make this easier, the Voter is not implementing the whole access checking process, but delay the final decision to an Access Granting Strategy. The strategy is responsible for deciding if any of the User or Roles is actually granted any of the attributes on the target. We provide 5 built-in strategies: ### Plain [](#plain) We check only the target ACEs themselves. So, given a class `C1` and one of its instances `O1`, if a User is granted access on `C1`, but the permission is not explicitly given on `O1`, he will not be granted the permission. ### Meta [](#meta) We check for permissions on objects and their classes. If a User does not have any permission granted on an Object (or an Object's Field), we will try to check if they have any for the Class (or the Class' Field). This is the default strategy in the full stack framework. ### Field erasure [](#field-erasure) We check for permissions on Fields and Object or Class. If a User does not have any permission granted on an Object's (or Class)' Field, we will try to check if they have any for the Object (or Class) itself. ### Inheritance [](#inheritance) We check for permission on Parent classes. If a User does not have any permission granted on a Class (or its Field), we will try to check on its Parent Class (or its Field). ### Complex [](#complex) This strategy is a mix the last three. It is mostly intended to be used as a code example for your own Strategies. Please read the [source code](src/Voter/Strategy/AclComplexAccessGrantingStrategy) for more details. ### Health Score 24 — LowBetter than 32% of packages Maintenance20 Infrequent updates — may be unmaintained Popularity14 Limited adoption so far Community16 Small or concentrated contributor base Maturity41 Maturing project, gaining track record Bus Factor1 Top contributor holds 72.2% of commits — single point of failure How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window. **Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores. **Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement. **Maturity (30%)** — Project age, version count, PHP version support, and release stability. ### Community Maintainers ![](https://www.gravatar.com/avatar/080e2a485e6d12b767d5d1b8c309c9c7b5cfd963f0f762836f5263b91c7a7f56?d=identicon)[lemoinem](/maintainers/lemoinem) ![](https://www.gravatar.com/avatar/c05b9ebc41865c351397a0282d90b0457ed53ae8c8b5ed7dcdf8715399c1417e?d=identicon)[ksom](/maintainers/ksom) ![](https://www.gravatar.com/avatar/ec3a0e0db3f9c250563b821407537b24bd3304c8bb3379c017d8ca4743b7b15c?d=identicon)[lavoiesl](/maintainers/lavoiesl) --- Top Contributors [![lemoinem](https://avatars.githubusercontent.com/u/234992?v=4)](https://github.com/lemoinem "lemoinem (39 commits)")[![lavoiesl](https://avatars.githubusercontent.com/u/1216046?v=4)](https://github.com/lavoiesl "lavoiesl (14 commits)")[![tchern0](https://avatars.githubusercontent.com/u/8822216?v=4)](https://github.com/tchern0 "tchern0 (1 commits)") ### Embed Badge ![Health badge](/badges/wemakecustom-symfony-acl-bundle/health.svg) ``` [![Health](https://phpackages.com/badges/wemakecustom-symfony-acl-bundle/health.svg)](https://phpackages.com/packages/wemakecustom-symfony-acl-bundle) ``` ### Alternatives [defuse/php-encryption Secure PHP Encryption Library 3.9k162.4M212](/packages/defuse-php-encryption)[roave/security-advisories Prevents installation of composer packages with known security vulnerabilities: no API, simply require it 2.9k97.3M6.4k](/packages/roave-security-advisories)[mews/purifier Laravel 5/6/7/8/9/10 HtmlPurifier Package 2.0k16.7M112](/packages/mews-purifier)[robrichards/xmlseclibs A PHP library for XML Security 41278.1M118](/packages/robrichards-xmlseclibs)[bjeavons/zxcvbn-php Realistic password strength estimation PHP library based on Zxcvbn JS 86917.5M63](/packages/bjeavons-zxcvbn-php)[enlightn/security-checker A PHP dependency vulnerabilities scanner based on the Security Advisories Database. 33732.2M110](/packages/enlightn-security-checker) PHPackages © 2026 [Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)