How to Implement your own Voter to Blacklist IP Addresses

The Voter Interface¶

A custom voter must implement VoterInterface, which requires the following three methods:

interface VoterInterface
{
    public function supportsAttribute($attribute);
    public function supportsClass($class);
    public function vote(TokenInterface $token, $object, array $attributes);
}

The supportsAttribute() method is used to check if the voter supports the given user attribute (i.e: a role like ROLE_USER, an ACL EDIT, etc.).

The supportsClass() method is used to check if the voter supports the class of the object whose access is being checked.

The vote() method must implement the business logic that verifies whether or not the user has access. This method must return one of the following values:

• VoterInterface::ACCESS_GRANTED: The authorization will be granted by this voter;
• VoterInterface::ACCESS_ABSTAIN: The voter cannot decide if authorization should be granted;
• VoterInterface::ACCESS_DENIED: The authorization will be denied by this voter.

In this example, you’ll check if the user’s IP address matches against a list of blacklisted addresses and “something” will be the application. If the user’s IP is blacklisted, you’ll return VoterInterface::ACCESS_DENIED, otherwise you’ll return VoterInterface::ACCESS_ABSTAIN as this voter’s purpose is only to deny access, not to grant access.

Creating a custom Voter¶

To blacklist a user based on its IP, you can use the request_stack service and compare the IP address against a set of blacklisted IP addresses:

// src/AppBundle/Security/Authorization/Voter/ClientIpVoter.php
namespace AppBundleSecurityAuthorizationVoter;

use SymfonyComponentHttpFoundationRequestStack;
use SymfonyComponentSecurityCoreAuthorizationVoterVoterInterface;
use SymfonyComponentSecurityCoreAuthenticationTokenTokenInterface;

class ClientIpVoter implements VoterInterface
{
    protected $requestStack;
    private $blacklistedIp;

    public function __construct(RequestStack $requestStack, array $blacklistedIp = array())
    {
        $this->requestStack  = $requestStack;
        $this->blacklistedIp = $blacklistedIp;
    }

    public function supportsAttribute($attribute)
    {
        // you won't check against a user attribute, so return true
        return true;
    }

    public function supportsClass($class)
    {
        // your voter supports all type of token classes, so return true
        return true;
    }

    public function vote(TokenInterface $token, $object, array $attributes)
    {
        $request = $this->requestStack->getCurrentRequest();
        if (in_array($request->getClientIp(), $this->blacklistedIp)) {
            return VoterInterface::ACCESS_DENIED;
        }

        return VoterInterface::ACCESS_ABSTAIN;
    }
}

That’s it! The voter is done. The next step is to inject the voter into the security layer. This can be done easily through the service container.

Declaring the Voter as a Service¶

To inject the voter into the security layer, you must declare it as a service, and tag it as a security.voter:

Changing the Access Decision Strategy¶

In order for the new voter to take effect, you need to change the default access decision strategy, which, by default, grants access if any voter grants access.

In this case, choose the unanimous strategy. Unlike the affirmative strategy (the default), with the unanimous strategy, if only one voter denies access (e.g. the ClientIpVoter), access is not granted to the end user.

To do that, override the default access_decision_manager section of your application configuration file with the following code.

That’s it! Now, when deciding whether or not a user should have access, the new voter will deny access to any user in the list of blacklisted IPs.

Note that the voters are only called, if any access is actually checked. So you need at least something like