Adding such a method which is not part of the interface is a bad idea, as it would force to code against the implementation rather than the interface (which is not a supported usage of Symfony, as we allow ourselves to decorate services with a different implementation, and we do it regularly to implement the profiler features for instance).

I think this should be implemented as a separate class (most of the logic is handled by the access decision manager anyway)

Agree, where do you think I should put this code ? Do you have any idea about a classname ?
ImpersonatorAccessDecisionManagerSwithUserDecisionManager ?

edited. ping@stof

I'm not sure about using fallbacks. I think using a single is_granted can be confusing and can lead to errors (from a DX point of view).

Maybe other Symfony contributors have an idea ?

I am not sure I understand the use case here. Can you elaborate a bit?

The use case is pretty simple.
I have an app where I have a User, a user admin and an administrator.

The user admin can switch into a user. and sometimes on several screens, there are some actions that only the user admin can do. And I have to check the impersonator roles to acheive that

So if I understand this correctly, we are looking for a shortcut foris_granted('ROLE_ALLOWED_TO_SWITCH')?

No, because we can have different levels for user impersonation. And I want to check the roles of impersonator

What do you mean with different levels in this context?

I am sorry to bother you with these questions but I would like to better understand the use case to see whether or not this fits in the Symfony core.

That totally fine 👍
I mean the impersonator can be for example a manager, or a member of the application support.
Both manager and support can impersonate a user, but the manager can do some actions that the support team can not. I want to check this on the user list. Not sure if it's fully clear now

I think this is not the goal of the impersonating. You should be the impersonated user with the exact roles, no matter from which role you did the impersonation...
But if I understand you correct, this is the goal of the PR, right?

It is :)

What about a voter that checks for aIMPERSONATOR_ATTRIBUTE_X withIMPERSONATOR_ prefix configurable, it would early return false if the token is not an instance ofSwitchUserToken then remove the prefix before calling its decorated auth checker (we are no tied by circular dependency anymore, but the voter should be in the SecurityBundle though)?

We could then have a Twig functionimpersonator_is_granted('ATTRIBUTE_X') that adds the prefix before callingis_granted in thebridge security bundle too?

Maybe an IMPERSONATOR_ROLE_X to be consistent with RoleVoter ?

To be flexible this should be working with any attributes to trigger custom voters not just using roles or roles hierarchy.
Using aSwitchUserVoter would get rid of that new interface, and would be simple to implement:

// ...class SwitchUserVoterextends Voter{private$prefix ='IMPERSONATOR_';private$accessDecisionManager;// ...publicfunctionsupports(...)    {return0 ===strpos($attribute,$this->prefix);    }publicfunctionvoteOnAttribute(...)    {if (!$tokeninstanceof SwitchUserToken) {returnfalse;        }return$this->accessDecisionManager->decide($token->getOriginalToken(), [substr($attribute,strlen($this->prefix))],$subject);    }}

That would allow both:

{% is_granted('EDIT_POST',post)or impersonator_is_granted('MANAGE_POST',post) %}{# or with a custom prefix X_#}{% is_granted(['EDIT_POST','X_MANAGE_POST'],post) %}

Plus the second example is valid for any call ofisGranted() anywhere (that's what I mean by more flexible), while we can decorate the method easily in twig, in raw PHP it requires a new contract.

The prefix would be easier to decorate also inSecurity andControllerTrait helpers.

Closing as I don't think this feature (as explained by@OskarStark) should be in core.