Hmm, theLogoutHandlerInterface was deprecated and this listener actually replaces it (ref#36243). So I don't think it's a good idea to introduce that interface.

However, I agree with you and I see the problem here as well. What about this:

• Keep the changes in this PR
• ImplementEventSubscriberInterface + the code of this listener inAbstractRememberMeServices
• If the remember me service implementsEventSubscriberInterface, add thekernel.event_subscriber tag inRememberMeFactory.
• If the remember me service implementsLogoutHandlerInterface, but notEventSubscriberInterface, trigger a deprecation and "fix" the situation by registering this logout listener with the remember me service instead.

If I'm correct, this would make core work without deprecated usages and provide an upgrade path for your bundle and people creating their own remember me service.

Would it be such a bad thing to depend on the deprecatedLogoutHandlerInterface? For the matter of keeping backwards compatibility, sometimes it's necessary to depend on a deprecated item, until you can introduce a potentially breaking change.

I like that there is aRememberMeLogoutListener, because that keeps the architecture nice and clean. Merging the listener intoAbstractRememberMeServices doesn't feel to me like proper separation of concerns (but I agree, your suggestion would work).

I believe the long-term solution to this problem would be to move the method fromLogoutHandlerInterface toRememberMeServicesInterface in the next major version. Its signature goes very well with the other methods of the interface, so it feels like the right place.

publicfunction autoLogin(Request$request);publicfunction loginFail(Request$request,\Exception$exception =null);publicfunction loginSuccess(Request$request,Response$response,TokenInterface$token);publicfunction logout(Request$request,Response$response,TokenInterface$token);

For offering a migration path, you could treat the constructor argument inRememberMeLogoutListener as a "union type" (even when we don't have union types yet):

class RememberMeLogoutListenerimplements EventSubscriberInterface{private$rememberMeServices;publicfunction__construct(object$rememberMeServices)    {if (!($rememberMeServicesinstanceof RememberMeServicesInterface &&$rememberMeServicesinstanceof LogoutHandlerInterface)) {thrownew \InvalidArgumentException('Argument 0 must be instance of RememberMeServicesInterface and LogoutHandlerInterface');        }$this->rememberMeServices =$rememberMeServices;    }

You could also "softly" introduce the method onRememberMeServicesInterface without the risk of breaking code.

/** * @method logout(Request $request, Response $response, TokenInterface $token) */interface RememberMeServicesInterface

Then, with the next major release, you could move the method, removeLogoutHandlerInterface and remove the union type checks to only check forRememberMeServicesInterface.

This change is fine technically to ease BC/FC. Updating the constructor in 6.0 can happen without any hard BC break.

Thank you@scheb.

Glad to help 👍

I think we should provide the upgrade path as proposed by@scheb. I've submitted a PR for it:#36832