Authorization

参见

You can change the default strategy in the configuration.

AuthenticatedVoter¶

The AuthenticatedVoter voter supports the attributes IS_AUTHENTICATED_FULLY, IS_AUTHENTICATED_REMEMBERED, and IS_AUTHENTICATED_ANONYMOUSLY and grants access based on the current level of authentication, i.e. is the user fully authenticated, or only based on a “remember-me” cookie, or even authenticated anonymously?

use SymfonyComponentSecurityCoreAuthenticationAuthenticationTrustResolver;

$anonymousClass = 'SymfonyComponentSecurityCoreAuthenticationTokenAnonymousToken';
$rememberMeClass = 'SymfonyComponentSecurityCoreAuthenticationTokenRememberMeToken';

$trustResolver = new AuthenticationTrustResolver($anonymousClass, $rememberMeClass);

$authenticatedVoter = new AuthenticatedVoter($trustResolver);

// instance of SymfonyComponentSecurityCoreAuthenticationTokenTokenInterface
$token = ...;

// any object
$object = ...;

$vote = $authenticatedVoter->vote($token, $object, array('IS_AUTHENTICATED_FULLY');

RoleVoter¶

The RoleVoter supports attributes starting with ROLE_ and grants access to the user when the required ROLE_* attributes can all be found in the array of roles returned by the token’s getRoles() method:

use SymfonyComponentSecurityCoreAuthorizationVoterRoleVoter;

$roleVoter = new RoleVoter('ROLE_');

$roleVoter->vote($token, $object, array('ROLE_ADMIN'));

RoleHierarchyVoter¶

The RoleHierarchyVoter extends RoleVoter and provides some additional functionality: it knows how to handle a hierarchy of roles. For instance, a ROLE_SUPER_ADMIN role may have subroles ROLE_ADMIN and ROLE_USER, so that when a certain object requires the user to have the ROLE_ADMIN role, it grants access to users who in fact have the ROLE_ADMIN role, but also to users having the ROLE_SUPER_ADMIN role:

use SymfonyComponentSecurityCoreAuthorizationVoterRoleHierarchyVoter;
use SymfonyComponentSecurityCoreRoleRoleHierarchy;

$hierarchy = array(
    'ROLE_SUPER_ADMIN' => array('ROLE_ADMIN', 'ROLE_USER'),
);

$roleHierarchy = new RoleHierarchy($hierarchy);

$roleHierarchyVoter = new RoleHierarchyVoter($roleHierarchy);

注解

Most authentication tokens extend from AbstractToken, which means that the roles given to its constructor will be automatically converted from strings to these simple Role objects.

The Access Listener¶

The access decision manager can be used at any point in a request to decide whether or not the current user is entitled to access a given resource. One optional, but useful, method for restricting access based on a URL pattern is the AccessListener, which is one of the firewall listeners (see Firewall Listeners) that is triggered for each request matching the firewall map (see A Firewall for HTTP Requests).

It uses an access map (which should be an instance of AccessMapInterface) which contains request matchers and a corresponding set of attributes that are required for the current user to get access to the application:

use SymfonyComponentSecurityHttpAccessMap;
use SymfonyComponentHttpFoundationRequestMatcher;
use SymfonyComponentSecurityHttpFirewallAccessListener;

$accessMap = new AccessMap();
$requestMatcher = new RequestMatcher('^/admin');
$accessMap->add($requestMatcher, array('ROLE_ADMIN'));

$accessListener = new AccessListener(
    $securityContext,
    $accessDecisionManager,
    $accessMap,
    $authenticationManager
);

Authorization Checker¶

The access decision manager is also available to other parts of the application via the isGranted() method of the AuthorizationChecker. A call to this method will directly delegate the question to the access decision manager:

use SymfonyComponentSecurityCoreAuthorizationAuthorizationChecker;
use SymfonyComponentSecurityCoreExceptionAccessDeniedException;

$authorizationChecker = new AuthorizationChecker(
    $tokenStorage,
    $authenticationManager,
    $accessDecisionManager
);

if (!$authorizationChecker->isGranted('ROLE_ADMIN')) {
    throw new AccessDeniedException();
}