Discussion why this feature wasn't introduced when initially adding the resolver: #18510 (comment)

@iltar thanks for the link. I agree that it may collide with the ParamConverter. On the other hand I still think the UserValueResolver should support classes implementing the UserInterface.

Few quick ideas:

• What about making it configurable or togglable?
• Is a ParamConverter called before or after a ValueResolver? Or not at all?

I agree with @davidkmenta here, the param converters are executed before the value resolver so the concern highlighted in #18510 (comment) shouldn't be a problem.

Forcing users to type they controller arguments with UserInterface gives bad DX for IDE auto-completion/static analysis.

@davidkmenta @jvasseur If you type-hint an entity, it will actually try to inject that entity based on the request, which will fail, because there's no way of fetching it. This is because the parameter converters are triggered first.

Forcing users to type they controller arguments with UserInterface gives bad DX for IDE auto-completion/static analysis.

If people use it as quick way to get their current user object, why not provide a (by the SecurityBundle) configurable AVR that can return a given object based on the current UserInterface? That would be a generic solution to a common problem.

@iltar didn't think of that since I tend do disable the automatic conversion.

We need to think of the future of the future of param converters (sensiolabs/SensioFrameworkExtraBundle#436 ?) maybe it's time to deprecate them and introduce configurable argument resolvers, this would allow us to have a configurable security user resolver.

Yes, something has to be done about the parameter converters, but I'm not sure what and I don't have much time myself 😢

Regarding the current AVR, what if we add an additional interface to the UserProviderInterface?

interface DomainUserProviderInterface
{
    // would return your entity for example, names to be discussed
    public function convertToDomainUser(UserInterface $user);
}

# follows the basic configuration
security
    providers:
        hostnet:
            id: App\Security\Authentication\CustomerPortal\UserProvider

This would make it possible for the AVR to resolve the security user to a domain user. If you implement the interface on your user provider, it will simply be "enabled" for whatever has that user. We have the firewall information available, so perhaps it's not even hard to find the user provider.

So I guess this PR can be closed for now :)

TBH I do not follow why this was closed because of bundle that it's not inside symfony.. Personally I do not use Sensio bundles... :(

I believe that this is a problem of sensio bundle that should either decorate the user AVR or overwrite it.

Symfony needs a generic controller configuration system that works similar to the idea behind the annotations from that bundle (but configurable without annotations as well). When this is done, AVR can fully replace the parameter converters and it won't be an issue anymore.

The issue arises because a lot of developers do use the SensioFrameworkExtraBundle, because it also adds features such as @Security. There's also effort being made to deprecate the user object from the Token, so the idea is to be able to inject your Domain user into an action based on this token, which means this AVR wouldn't even be necessary anymore. This won't solve the aforementioned issue though.