Symfony version(s) affected

6.2

Description

For my application I created a custom AuthenticationSuccessHandler and AuthenticationFailureHandler having a (slightly) different behavior from the defaults (actually extending the default implementations). But when using these on multiple authenticators this "fails" in that the options of the "last" registered authenticator is used for all authenticators. This is due to the fact that the createAuthenticationSuccessHandler and createAuthenticationFailureHandler of the AbstractFactory wrap the custom handler and reference the provided handler. When the wrapper (CustomAuthenticationSuccessHandler / CustomAuthenticationFailureHandler) is then created the options of the actual (configured) handler are set. But this actual handler is shared between all authenticators. Which thus makes it impossible to set options on a single instance.

How to reproduce

Steps:

1. Configure two authenticators, for example form_login and login_link
2. For both these authenticators configure a different login_path
3. For both these authenticators configure the same failure_handler (most likely this can even be the DefaultAuthenticationFailureHandler)
4. Test both a login failure on the form_login and a login failure on login_link

Expected result:
As both authenticators have a different login_path set both failures should redirect to a different URL.

Actual result:
Both failures send the user to the same URL.

Possible Solution

It is my believe that both AbstractFactory::createAuthenticationSuccessHandler and AbstractFactory::createAuthenticationFailureHandler shouldn't reference the configured handler, but should create a ChildDefinition.

In other words: here and here the new Reference should be new ChildDefinition.
This would then create a unique service which means that the options (and firewall in case of success handler) aren't reused.

Note: if this bug and solution are "accepted" I can create a PR for it as well (which will most likely be against 5.4 as this seems to be old code predating even 5.4). I'm just uncertain whether this is considered a bug or desired behavior.

Additional Context

No response