I just realised that@hhamon suggested almost the same years ago (see#942) which was closed in favour of creating more specialised access decision managers (though that never happened). What do you think about that idea? Should we create one class per access decision strategy instead and then make it easier to inject your own access decision manager by introducing a new config option in the SecurityBundle?

@symfony/deciders What are your thoughts on this?

Not sure if we need to create classes for existing strategies, we could keep them inline as today. If not, I would make those classes final.

I like the idea of having all strategies in seperate classes and configuring the service ID of the strategy to use (with a shortcut forsecurity.strategy.%s IDs, soaffirmative will set thesecurity.strategy.affirmative service andapp.custom_strategy will use that ID).

Status: needs work

I like the idea of having all strategies in seperate classes and configuring the service ID of the strategy to use [...]

@wouterj My main concern is if we really need to go the way of custom strategies then or if it wasn't enough to configure a service implementing theAuthenticationManagerInterface and then making it easy to change that service?

@xabbuh Any interest in finishing this one by taking into account comments?

Well, we should first decide which way we would like to go (i.e. making the vote strategy configurable or making it possible to configure the access decision manager like suggested in#942). I think my favourite solution is to keep the separated vote strategies for greater flexibility (as they are now in this PR), but remove the StrategyAwareAccessDecisionManager and instead allow just configure the access decision manager service in the SecurityBundle (you will only be able to configure either the access decision manager or the vote strategy). What do you think?

On second thought, I think we should remove the strategy stuff and just allow to configure the AccessDecisionManager service ID. With the VoteStrategyInterface, we add an extra layer of complexity for almost nothing. The AccessDecisionManager simply only proxies it'sdecide() call to the VoteStrategy and there is no other code in the manager.

So simply creating a custom manager and setting it through a service should be more than enough.

I pushed an update that reverts the changes made to theAccessDecisionManager, but makes it possible to configure a service providing anAccessDecisionManagerInterface implementation.

ping @symfony/deciders

Does it make sense to keep the strategy configurable for a custom access decision manager as a service?

@HeahDude I first thought when I introduced theVoteStrategyInterface. But thinking about it again I don't think there's much value in having reusable voting strategies. Reusing them wouldn't be much different from using the built-in access decision manager IMO.

Status: Needs Review

Moving to milestone as this is not a blocker for 3.3. If you don't agree, please explain why.

PR description updated to match the actual state of this PR (the idea of aVoteStrategyInterface was dropped in favour of being able to configure your ownAccessDecisionManager service).

ping @symfony/deciders

Thank you@xabbuh.

Doc PR welcomed ;)