-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Security] make it possible to configure a custom access decision manager service #19034
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Security] make it possible to configure a custom access decision manager service #19034
Conversation
* | ||
* @author Christian Flothmann <christian.flothmann@xabbuh.de> | ||
*/ | ||
class StrategyAwareAccessDecisionManager implements AccessDecisionManagerInterface |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really like this name. So I welcome any suggestions for something better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not really sure why you introduced a new class here, it looks like the old class has equal behaviour?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we want to deprecate the old one in favor of this one, I would call it VotingAccessDecisionManager
or the like. The special thing about this implementation is that it uses voters to decide the access.
935c6a5
to
6ef3459
Compare
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. |
|
||
if ($strategy instanceof VoteStrategyInterface) { | ||
$this->voteStrategy = $strategy; | ||
} elseif (self::STRATEGY_AFFIRMATIVE === $strategy) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what about deprecating passing a string as strategy?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And maybe removing allowIfAllAbstainDecisions
, allowIfEqualGrantedDeniedDecisions
from constructor of this class in future?
I like the idea of having all strategies in seperate classes and configuring the service ID of the strategy to use (with a shortcut for |
Status: needs work |
@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 the |
@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's So simply creating a custom manager and setting it through a service should be more than enough. |
6ef3459
to
7ec99f0
Compare
6417e74
to
c28ca0a
Compare
I pushed an update that reverts the changes made to the |
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 the |
c28ca0a
to
4abe705
Compare
Status: Needs Review |
099c769
to
9a8779f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
9a8779f
to
1d5a5c6
Compare
Moving to milestone as this is not a blocker for 3.3. If you don't agree, please explain why. |
1d5a5c6
to
ba9fd2f
Compare
PR description updated to match the actual state of this PR (the idea of a |
ba9fd2f
to
e0913a2
Compare
ping @symfony/deciders |
Thank you @xabbuh. |
Doc PR welcomed ;) |
…ss decision manager service (xabbuh) This PR was merged into the 3.4 branch. Discussion ---------- [Security] make it possible to configure a custom access decision manager service | Q | A | | --- | --- | | Branch? | 3.4 | | Bug fix? | no | | New feature? | yes | | BC breaks? | no | | Deprecations? | no | | Tests pass? | yes | | Fixed tickets | #942, #14049, #15295, #16828, #16843, | | License | MIT | | Doc PR | TODO | These changes will make it possible to let users define their own voting strategies without the need for custom compiler passes that replace the built-in `AccessDecisionManager` (see linked issues in the PR table for some use cases). Commits ------- e0913a2 add option to define the access decision manager
These changes will make it possible to let users define their own voting strategies without the need for custom compiler passes that replace the built-in
AccessDecisionManager
(see linked issues in the PR table for some use cases).