Hmm, I'm not very sure about these changes. But the listener logic is quite complex, so I might completely miss something. What I see:

• The only requirement for firewall listeners is to be callable:

  symfony/src/Symfony/Component/Security/Http/Firewall.php

  Lines 110 to 119 in93d0276

  	protectedfunctioncallListeners(RequestEvent$event,iterable$listeners)
  	{
  	foreach ($listenersas$listener) {
  	$listener($event);
  	if ($event->hasResponse()) {
  	break;
  	}
  	}
  	}

• Only theAbstractListener implements this callable functionality usingsupports()/authenticate():

  symfony/src/Symfony/Component/Security/Http/Firewall/AbstractListener.php

  Lines 24 to 29 in93d0276

  	finalpublicfunction__invoke(RequestEvent$event)
  	{
  	if (false !==$this->supports($event->getRequest())) {
  	$this->authenticate($event);
  	}
  	}

So, it should be possible to have a class with just an__invoke() andgetPriority() method, right?AbstractListener is only relevant when you want your listener to support laziness.

AbstractListener is only relevant when you want your listener to support laziness.

Actuallysupports() is also relevant for listeners that don't need laziness (yet), as they can opt-in using the specialnull return type for this method.

At the time lazy firewalls were introduced,@nicolas-grekas and I talked about deprecating not extendingAbstractListener at some point, so that we have a consistent API for firewall listeners (seehttps://github.com/orgs/symfony/projects/1#card-30499343).
I'm still a bit annoyed by the fact we need to rely on inheritance instead of a clear contract if we do so.

Meanwhile we are reintroducing an interface which, right now, only covers the priority feature.
This PR takes it as an opportunity to not force extending a base class, making the concept more structured and more flexible. That's worth the hassle to me.

About adding__invoke() to the contract, I'm mitigated: should we just acceptcallable|FirewallListenerinterface for firewall listeners?
The interface allows you to opt-in into more complex features like priority, laziness and the ability to separate concerns between the guard clause and the actual authentication logic.

Does this make sense?

Thank you@chalasr.