Description
Symfony version(s) affected
6.3.0
Description
There are already several comments on #48044 that indicate that that change is a BC break.
The main problem is that flagging a firewall stateless has never meant that each request that passed that firewall is meant to be stateless. It was merely a way to tell Symfony not to persist the authentication token in the session. The application could still have valid reasons to access the session later on. @tucksaun mentioned CSRF checks and flash messages as examples.
My problem is that #48044 changes the semantics of the firewall attribute stateless. This might be a surprise for applications that suddenly raise exceptions on routes that worked perfectly fine with Symfony 6.2. However, this exception is not raised with production settings as far as I can tell, so it's "only" the local dev environment that breaks.
I think that this behavior should've been opt-in, maybe with a deprecation layer.
How to reproduce
Declare a stateless firewall and access the session from a controller behind that firewall on a route with no explicit stateless setting.
Possible Solution
Revert #48044 or make that functionality opt-in.
Additional Context
In my case, my firewall was declared stateless because Symfony was not supposed to manage the session of the application. This is part of a typical temporary authenticator I use when migrating legacy applications to Symfony: I can make Symfony aware of the authenticated user without migrating the login form. If I wouldn't declare the firewall stateless, Symfony would remember the authenticated token which would break the logout mechanism of the legacy app.
I "solved" this in my project by declaring an event listener:
#[AsEventListener(priority: 1024)]
final class StatelessListener
{
public function __invoke(RequestEvent $event): void
{
$event->getRequest()->attributes->set('_stateless', false);
}
}But that only works because we don't make use of that stateless route flag at all at the moment.