In Symfony applications, security voters centralize the authorization logic
which decides if a given user can access to the requested resource. They are
regular Symfony services tagged with the security.voter tag, so they can
define their priorities via the priority attribute of the tag.
In practice this voter priority is mostly irrelevant, because of the access decision strategies used by Symfony:
affirmative, grants access as soon as there is one voter granting access;consensus, grants access if there are more voters granting access than denying;unanimous, grants access if there is no voter denying access.
That's why in Symfony 5.1 we've added a new access decision strategy called
priority which grants or denies access depending on the first voter that
does not abstain. In this case, the voter priority is essential, because the
first non-abstain decision will be the final decision:
1 2 3 4 5
# config/packages/security.yaml
security:
access_decision_manager:
strategy: priority
# ...This feature originated from the Contao CMS project, which is built with
Symfony, and defines some default permissions which other extensions/bundles
must be able to override. This new priority access decision strategy is
the only one able to do that.
Looks like a useful addition. Any ideas if using this would also bring (relative real world) performance improvements? Of course one must make sure to only vote on a specific attribute in one Voter. (Otherwise you probably need the affirmative or one of the other strategies).
@Ruud Bijnen the priority attribute can play a role in performance when using the affirmative and priority strategies. Voters are lazy loaded and lazy executed. If a voter is heavy to initialize (e.g. lots of dependencies) or executes heavy tasks while voting, you might get some benefits by placing it lower in the list (this only applies if other voters already granted access/not abstained before).
This is such a great improvement. Thank you!
Thank you for the good work!