Cover of the book Symfony 5: The Fast Track

Symfony 5: The Fast Track is the best book to learn modern Symfony development, from zero to production. +300 pages in full color showing how to combine Symfony with Docker, APIs, queues & async tasks, Webpack, Single-Page Applications, etc.

Buy printed version

New in Symfony 5.1: Access decision based on voter priority

Contributed by
Andreas Schempp
in #34548.

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.

New in Symfony 5.1: Access decision based on voter priority symfony.com/blog/new-in-symfony-5-1-access-decision-based-on-voter-priority

Tweet this

Comments

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!

Comments are closed.

To ensure that comments stay relevant, they are closed for old posts.