How to Use Voters to Check User Permissions

Warning: You are browsing the documentation for Symfony 3.x, which is no longer maintained.

Read the updated version of this page for Symfony 7.1 (the current stable version).

Voters are Symfony's most powerful way of managing permissions. They allow you to centralize all permission logic, then reuse them in many places.

However, if you don't reuse permissions or your rules are basic, you can always put that logic directly into your controller instead. Here's an example how this could look like, if you want to make a route accessible to the "owner" only:

1
2
3
4
5
6
// src/AppBundle/Controller/PostController.php
// ...

if ($post->getOwner() !== $this->getUser()) {
    throw $this->createAccessDeniedException();
}

In that sense, the following example used throughout this page is a minimal example for voters.

Tip

Take a look at the authorization article for an even deeper understanding on voters.

Here's how Symfony works with voters: All voters are called each time you use the isGranted() method on Symfony's authorization checker or call denyAccessUnlessGranted in a controller (which uses the authorization checker), or by access controls.

Ultimately, Symfony takes the responses from all voters and makes the final decision (to allow or deny access to the resource) according to the strategy defined in the application, which can be: affirmative, consensus or unanimous.

For more information take a look at the section about access decision managers.

The Voter Interface

A custom voter needs to implement VoterInterface or extend Voter, which makes creating a voter even easier:

1
2
3
4
5
6
7
8
use Symfony\Component\Security\Core\Authentication\Token\TokenInterface;
use Symfony\Component\Security\Core\Authorization\Voter\VoterInterface;

abstract class Voter implements VoterInterface
{
    abstract protected function supports($attribute, $subject);
    abstract protected function voteOnAttribute($attribute, $subject, TokenInterface $token);
}

Setup: Checking for Access in a Controller

Suppose you have a Post object and you need to decide whether or not the current user can edit or view the object. In your controller, you'll check access with code like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
// src/AppBundle/Controller/PostController.php
// ...

class PostController extends Controller
{
    /**
     * @Route("/posts/{id}", name="post_show")
     */
    public function showAction($id)
    {
        // get a Post object - e.g. query for it
        $post = ...;

        // check for "view" access: calls all voters
        $this->denyAccessUnlessGranted('view', $post);

        // ...
    }

    /**
     * @Route("/posts/{id}/edit", name="post_edit")
     */
    public function editAction($id)
    {
        // get a Post object - e.g. query for it
        $post = ...;

        // check for "edit" access: calls all voters
        $this->denyAccessUnlessGranted('edit', $post);

        // ...
    }
}

The denyAccessUnlessGranted() method (and also the isGranted() method) calls out to the "voter" system. Right now, no voters will vote on whether or not the user can "view" or "edit" a Post. But you can create your own voter that decides this using whatever logic you want.

Creating the custom Voter

Suppose the logic to decide if a user can "view" or "edit" a Post object is pretty complex. For example, a User can always edit or view a Post they created. And if a Post is marked as "public", anyone can view it. A voter for this situation would look like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
// src/AppBundle/Security/PostVoter.php
namespace AppBundle\Security;

use AppBundle\Entity\Post;
use AppBundle\Entity\User;
use Symfony\Component\Security\Core\Authentication\Token\TokenInterface;
use Symfony\Component\Security\Core\Authorization\Voter\Voter;

class PostVoter extends Voter
{
    // these strings are just invented: you can use anything
    const VIEW = 'view';
    const EDIT = 'edit';

    protected function supports($attribute, $subject)
    {
        // if the attribute isn't one we support, return false
        if (!in_array($attribute, [self::VIEW, self::EDIT])) {
            return false;
        }

        // only vote on `Post` objects
        if (!$subject instanceof Post) {
            return false;
        }

        return true;
    }

    protected function voteOnAttribute($attribute, $subject, TokenInterface $token)
    {
        $user = $token->getUser();

        if (!$user instanceof User) {
            // the user must be logged in; if not, deny access
            return false;
        }

        // you know $subject is a Post object, thanks to `supports()`
        /** @var Post $post */
        $post = $subject;

        switch ($attribute) {
            case self::VIEW:
                return $this->canView($post, $user);
            case self::EDIT:
                return $this->canEdit($post, $user);
        }

        throw new \LogicException('This code should not be reached!');
    }

    private function canView(Post $post, User $user)
    {
        // if they can edit, they can view
        if ($this->canEdit($post, $user)) {
            return true;
        }

        // the Post object could have, for example, a method `isPrivate()`
        return !$post->isPrivate();
    }

    private function canEdit(Post $post, User $user)
    {
        // this assumes that the Post object has a `getOwner()` method
        return $user === $post->getOwner();
    }
}

That's it! The voter is done! Next, configure it.

To recap, here's what's expected from the two abstract methods:

Voter::supports($attribute, $subject)
When isGranted() (or denyAccessUnlessGranted()) is called, the first argument is passed here as $attribute (e.g. ROLE_USER, edit) and the second argument (if any) is passed as $subject (e.g. null, a Post object). Your job is to determine if your voter should vote on the attribute/subject combination. If you return true, voteOnAttribute() will be called. Otherwise, your voter is done: some other voter should process this. In this example, you return true if the attribute is view or edit and if the object is a Post instance.
voteOnAttribute($attribute, $subject, TokenInterface $token)
If you return true from supports(), then this method is called. Your job is simple: return true to allow access and false to deny access. The $token can be used to find the current user object (if any). In this example, all of the complex business logic is included to determine access.

Configuring the Voter

To inject the voter into the security layer, you must declare it as a service and tag it with security.voter. But if you're using the default services.yml configuration, that's done automatically for you! When you call isGranted() with view/edit and pass a Post object, your voter will be executed and you can control access.

Checking for Roles inside a Voter

What if you want to call isGranted() from inside your voter - e.g. you want to see if the current user has ROLE_SUPER_ADMIN. That's possible by injecting the AccessDecisionManager into your voter. You can use this to, for example, always allow access to a user with ROLE_SUPER_ADMIN:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
// src/AppBundle/Security/PostVoter.php

// ...
use Symfony\Component\Security\Core\Authorization\AccessDecisionManagerInterface;

class PostVoter extends Voter
{
    // ...

    private $decisionManager;

    public function __construct(AccessDecisionManagerInterface $decisionManager)
    {
        $this->decisionManager = $decisionManager;
    }

    protected function voteOnAttribute($attribute, $subject, TokenInterface $token)
    {
        // ...

        // ROLE_SUPER_ADMIN can do anything! The power!
        if ($this->decisionManager->decide($token, ['ROLE_SUPER_ADMIN'])) {
            return true;
        }

        // ... all the normal voter logic
    }
}

If you're using the default services.yml configuration, you're done! Symfony will automatically pass the security.access.decision_manager service when instantiating your voter (thanks to autowiring).

Calling decide() on the AccessDecisionManager is essentially the same as calling isGranted() from a controller or other places (it's just a little lower-level, which is necessary for a voter).

Note

If you need to check access in any non-voter service, use the security.authorization_checker service (i.e. type-hint Symfony\Component\Security\Core\Authorization\AuthorizationCheckerInterface) instead of the security.access.decision_manager service shown here.

Changing the Access Decision Strategy

Normally, only one voter will vote at any given time (the rest will "abstain", which means they return false from supports()). But in theory, you could make multiple voters vote for one action and object. For instance, suppose you have one voter that checks if the user is a member of the site and a second one that checks if the user is older than 18.

To handle these cases, the access decision manager uses a "strategy" which you can configure. There are three strategies available:

affirmative (default)
This grants access as soon as there is one voter granting access;
consensus
This grants access if there are more voters granting access than denying;
unanimous
This only grants access if there is no voter denying access. If all voters abstained from voting, the decision is based on the allow_if_all_abstain config option (which defaults to false).

In the above scenario, both voters should grant access in order to grant access to the user to read the post. In this case, the default strategy is no longer valid and unanimous should be used instead. You can set this in the security configuration:

1
2
3
4
5
# app/config/security.yml
security:
    access_decision_manager:
        strategy: unanimous
        allow_if_all_abstain: false

Custom Access Decision Strategy

If none of the built-in strategies fits your use case, define the service option to use a custom service as the Access Decision Manager (your service must implement the AccessDecisionManagerInterface):

1
2
3
4
5
# app/config/security.yml
security:
    access_decision_manager:
        service: App\Security\MyCustomAccessDecisionManager
        # ...
This work, including the code samples, is licensed under a Creative Commons BY-SA 3.0 license.
TOC
    Version