PHPackages                             fedale/access-control-voter-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. [Authentication & Authorization](/categories/authentication)
4. /
5. fedale/access-control-voter-bundle

ActiveSymfony-bundle[Authentication & Authorization](/categories/authentication)

fedale/access-control-voter-bundle
==================================

Symfony bundle for dynamic, DB-driven authorization voters (#\[IsGranted\] backed by a database)

02↑2900%PHP

Since Jun 20Pushed todayCompare

[ Source](https://github.com/fedale/access-control-voter-bundle)[ Packagist](https://packagist.org/packages/fedale/access-control-voter-bundle)[ RSS](/packages/fedale-access-control-voter-bundle/feed)WikiDiscussions main Synced today

READMEChangelogDependenciesVersions (1)Used By (0)

Fedale Access Control Voter Bundle
==================================

[](#fedale-access-control-voter-bundle)

Autorizzazione **nativa Symfony** (`#[IsGranted]` / `isGranted()` / `AccessDecisionManager`) guidata da regole **dinamiche e persistite su database**.

È il complemento di [`fedale/access-control-bundle`](https://packagist.org/packages/fedale/access-control-bundle):

`access-control-bundle``access-control-voter-bundle` (questo)LivelloFirewall su `kernel.request`Voter nativo SymfonyProteggeURL (path/host/ip/method)Attributi/azioni (`#[IsGranted('EDIT_INVOICE')]`)Semanticafirst-match-winsfirst-match-winsSorgente regoleDB (Doctrine) + cacheDB (Doctrine) + cacheQuesto bundle **dipende** da `access-control-bundle` e ne riusa i pattern (provider, cache PSR-6, bridge Doctrine, config `AbstractBundle`), ma **non lo modifica** e vive in un pacchetto separato.

Installazione
-------------

[](#installazione)

```
composer require fedale/access-control-voter-bundle
```

Registra il bundle (se non usi Symfony Flex):

```
// config/bundles.php
return [
    // ...
    Fedale\AccessControlVoterBundle\FedaleAccessControlVoterBundle::class => ['all' => true],
];
```

Col provider Doctrine (default) il mapping ORM dell'entità viene registrato **automaticamente**(`prependExtension`): non serve aggiungere voci a `doctrine.orm.mappings`. Genera ed esegui la migration per creare la tabella `permission_rule`:

```
php bin/console make:migration
php bin/console doctrine:migrations:migrate
```

Quick start
-----------

[](#quick-start)

1. Annota un controller/azione con un attributo a piacere:

    ```
    use Symfony\Component\Security\Http\Attribute\IsGranted;

    #[IsGranted('EDIT_INVOICE')]
    public function edit(Invoice $invoice): Response { /* ... */ }
    ```
2. Inserisci una regola nella tabella `permission_rule` (o via la tua UI/CRUD):

    attributerolesallowsortactive`EDIT_INVOICE``["ROLE_EDITOR"]``true``0``true`
3. Un utente con `ROLE_EDITOR` ottiene **200**, gli altri **403**. Disattiva la regola (`active = false`) o cambiala a runtime: la decisione cambia senza deploy (ricordati di invalidare il pool di cache, vedi sotto).

### Come decide il voter

[](#come-decide-il-voter)

Per ogni attributo (`EDIT_INVOICE`):

1. **`super_admin_role`** concesso → `ACCESS_GRANTED` (short-circuit).
2. Regole attive dell'attributo, ordinate per `sort` ASC: la **prima applicabile** (ruoli soddisfatti, `roles` vuoto = sempre applicabile) decide via il suo `allow` → grant/deny. *(first-match-wins)*
3. Nessuna regola per quell'attributo → `supports()` è `false` → **ABSTAIN** (decidono gli altri voter).
4. Regole presenti ma nessuna applicabile all'utente → `ACCESS_DENIED`.

I ruoli sono valutati con `isGranted()`, quindi la `role_hierarchy` dell'app è rispettata.

> Edge-case: evita di usare come `attribute` una stringa che coincide con un ruolo (`ROLE_*`): il voter è attributo-scoped proprio per non intercettare i voti sui ruoli ed evitare ricorsione.

Configurazione
--------------

[](#configurazione)

```
# config/packages/fedale_access_control_voter.yaml
fedale_access_control_voter:
    enabled: true
    # Ruolo che bypassa tutte le regole (stringa vuota per disabilitare).
    super_admin_role: ROLE_SUPER_ADMIN
    cache:
        enabled: true
        pool: cache.app
        # ttl: 3600   # secondi; null = nessuna scadenza (invalida il pool a mano)
    # 'doctrine' = provider built-in, oppure l'id di un servizio custom.
    provider: doctrine
```

Le regole sono cachate **in blocco** sotto un'unica chiave (`CachedPermissionRuleProvider::CACHE_KEY`): il voter le interroga ad ogni voto, quindi il DB non viene toccato per ogni richiesta. Dopo aver modificato le regole, invalida il pool (es. `php bin/console cache:pool:clear cache.app`) oppure imposta un `ttl`.

Diagnostica delle regole effettive:

```
php bin/console fedale:access-control-voter:list
```

Provider custom
---------------

[](#provider-custom)

Imposta `provider` all'id di un servizio che implementa `Fedale\AccessControlVoterBundle\Contract\PermissionRuleProviderInterface` (YAML, API, in-memory, ...). La decorazione di cache resta opzionale e indipendente dalla sorgente.

Ispirazione: Yii2 RBAC
----------------------

[](#ispirazione-yii2-rbac)

Il design prende spunto dall'auth manager di Yii2 e ne mappa i concetti su quelli nativi di Symfony:

Yii2 RBACQuiPermission (auth item)`attribute` (es. `EDIT_INVOICE`)`Yii::$app->user->can($permission, $params)``isGranted($attribute, $subject)``$params` passato a `can()``$subject` del voterAssignment ruolo→utente, role hierarchy`roles` sulla regola + `role_hierarchy` di Symfony**Rule** (`execute($user, $item, $params): bool`)`PermissionConditionInterface::evaluate($subject, $token, $context)`L'idea più utile di Yii2 è la **Rule**: una condizione contestuale e riusabile, agganciata a un permesso, che decide in base all'oggetto (es. "puoi modificare *questa* fattura solo se ne sei l'autore").

### Predisposizione object-level (non ancora attiva)

[](#predisposizione-object-level-non-ancora-attiva)

L'entità/DTO espongono già due campi pensati per questo:

- `subjectType` — FQCN del soggetto a cui la regola si applica;
- `condition` — id di un servizio `PermissionConditionInterface` (la "Rule" stile Yii2).

```
interface PermissionConditionInterface
{
    public function evaluate(mixed $subject, TokenInterface $token, array $context = []): bool;
}
```

Allo stato attuale il `DynamicVoter` **legge** questi campi ma **non** li valuta: la decisione dipende dai soli `roles`. La valutazione del `$subject` e l'esecuzione delle condizioni sono predisposte ma fuori scope (estensione futura), insieme a un eventuale supporto per ExpressionLanguage.

Test
----

[](#test)

```
composer install
vendor/bin/phpunit
```

###  Health Score

21

—

LowBetter than 18% of packages

Maintenance65

Regular maintenance activity

Popularity3

Limited adoption so far

Community6

Small or concentrated contributor base

Maturity11

Early-stage or recently created project

 Bus Factor1

Top contributor holds 100% 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/aad4207f0dcf5e8fcac3ef897660e0f550a85e9ccb097868fe8419cdd8b5cfe5?d=identicon)[fedale](/maintainers/fedale)

---

Top Contributors

[![fedale](https://avatars.githubusercontent.com/u/127323?v=4)](https://github.com/fedale "fedale (1 commits)")

### Embed Badge

![Health badge](/badges/fedale-access-control-voter-bundle/health.svg)

```
[![Health](https://phpackages.com/badges/fedale-access-control-voter-bundle/health.svg)](https://phpackages.com/packages/fedale-access-control-voter-bundle)
```

###  Alternatives

[kartik-v/yii2-password

Useful password strength validation utilities for Yii Framework 2.0

761.2M17](/packages/kartik-v-yii2-password)[better-futures-studio/filament-local-logins

This is my package filament-local-logins

1334.6k](/packages/better-futures-studio-filament-local-logins)

PHPackages © 2026

[Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)