But that only works because we don't make use of that stateless route flag at all at the moment.

You could make your solution compatible with that by running your listener between the RouterListener (priority 32) and the FirewallListener (priority 8) instead of using priority 1024. This way, you could check whether the route already added this attribute in the request.

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.

I second this. IMHO the exception should only be thrown if the code tries to access any authentication related session data (e.g. the token) and not otherwise. Or is the idea that there must never be a session if a firewall or route is declared stateless?

When a request is declared as stateless, there must not be any usage of the session during the handling of that request. That's the whole point.
A request can actually have 3 states:

• declared as not stateless
• declared as stateless
• no declaration on the request (this is treated as not stateless as far as the requirement is enforced, but this unconfigured state is relevant for other parts).

If a route declares the stateless flag, it declares that state for the request

When a firewall is marked as stateless, it has 2 impacts:

• the ContextListener using the session to store the authentication token is disabled (meaning that your authenticator must be a stateless one able to authenticate each incoming request instead of relying on a previous request to a specific check path like form_login)
• if the stateless state of the request is unknown at the time of executing the firewall, it will mark the request as stateless (making it easy for the common use case where parts of the app covered by a stateless firewall must be fully stateless)

So if you need a stateless firewall without making the request fully stateless (because you use the session for something else), the solution is to explicitly mark the request as not stateless before the firewall runs (see my previous comment)

• if the stateless state of the request is unknown at the time of executing the firewall, it will mark the request as stateless (making it easy for the common use case where parts of the app covered by a stateless firewall must be fully stateless)

So if you need a stateless firewall without making the request fully stateless (because you use the session for something else), the solution is to explicitly mark the request as not stateless before the firewall runs (see my previous comment)

But that is the BC break. Being able to define a request (or route) as stateless is fine, but a stateless firewall should not automatically assume that all requests are stateless (only the authentication is).

When a request is declared as stateless, there must not be any usage of the session during the handling of that request.

@stof Thanks for clearing that up. 👍

In my case, I get the warning

Session was used while the request was declared stateless.

when someone call a route /api/routeNotFound.

It renders the 404 not found page which use the session (for CSP nonce for instance).

Some advice were to put stateless: false on the concerned route. But how do we do when it's not a route, but an error page generated by Symfony. Shouldn't this route be ignored by the "automatically set stateless" PR ?

Is there a way to configure different error page for different firewall ?

If your error pages unconditionally access your session, none of your routes is stateless. 🤷🏻‍♂️

I've always thought that stateless firewall turns off session (you're not able to use session at all during that request). I have a flashback of the blog post that presented this as a performance feature (if stateless means there is no session then let's remove it)

@javaDeveloperKid Marking a firewall as stateless means that the firewall itself will not use the session anymore.
Then, we have an additional smart behavior based on that about marking the request as stateless which I explained in #50715 (comment).
Once a request is marked as stateless, the framework ensures that nothing used the session during the request handling so that it actually is stateless.
If your template uses the session to read flash messages, the template will prevent marking things as stateless.

Hello, I just wanted to drop in and say that this broke my 5.4 -> 6.4 upgrade. Some of the tests started crashing because of the changed behavior and then another test started behaving weirdly when removing credentials for the next request (token stored in session).

Anyway yeah, I'd like this behavior to be optional if possible.

I'm getting the error when making a DELETE request to API platform. But it appears to actually do the delete (in the database).

I do have the symfony/security-bundle installed, but it's really a pretty generic app, symfony new --webapp (Symfony 7), then installing api platform and the symfony tools for security (e.g. make:user).

Any suggestions on how to debug this or configuring it differently?

curl 'https://127.0.0.1:8012/api/reactions/66'   -X 'DELETE'  | jq

{
  "@id": "/api/errors/500",
  "@type": "hydra:Error",
  "title": "An error occurred",
  "detail": "Session was used while the request was declared stateless.",
  "status": 500,
  "type": "/errors/500",
  "trace": [
    {
      "file": "/home/tac/g/sites/pulse/vendor/symfony/event-dispatcher/Debug/WrappedListener.php",
      "line": 116,
      "function": "onKernelResponse",
      "class": "Symfony\\Component\\HttpKernel\\EventListener\\AbstractSessionListener",
      "type": "->"
    },
    {
      "file": "/home/tac/g/sites/pulse/vendor/symfony/event-dispatcher/EventDispatcher.php",
      "line": 206,
      "function": "__invoke",
      "class": "Symfony\\Component\\EventDispatcher\\Debug\\WrappedListener",
      "type": "->"
    },
    {
      "file": "/home/tac/g/sites/pulse/vendor/symfony/event-dispatcher/EventDispatcher.php",
      "line": 56,
      "function": "callListeners",
      "class": "Symfony\\Component\\EventDispatcher\\EventDispatcher",
      "type": "->"
    },
    {
      "file": "/home/tac/g/sites/pulse/vendor/symfony/event-dispatcher/Debug/TraceableEventDispatcher.php",
      "line": 127,
      "function": "dispatch",
      "class": "Symfony\\Component\\EventDispatcher\\EventDispatcher",
      "type": "->"
    },
    {
      "file": "/home/tac/g/sites/pulse/vendor/symfony/http-kernel/HttpKernel.php",
      "line": 211,
      "function": "dispatch",
      "class": "Symfony\\Component\\EventDispatcher\\Debug\\TraceableEventDispatcher",
      "type": "->"
    },
    {
      "file": "/home/tac/g/sites/pulse/vendor/symfony/http-kernel/HttpKernel.php",
      "line": 199,
      "function": "filterResponse",
      "class": "Symfony\\Component\\HttpKernel\\HttpKernel",
      "type": "->"
    },
    {
      "file": "/home/tac/g/sites/pulse/vendor/symfony/http-kernel/HttpKernel.php",
      "line": 76,
      "function": "handleRaw",
      "class": "Symfony\\Component\\HttpKernel\\HttpKernel",
      "type": "->"
    },
    {
      "file": "/home/tac/g/sites/pulse/vendor/symfony/http-kernel/Kernel.php",
      "line": 185,
      "function": "handle",
      "class": "Symfony\\Component\\HttpKernel\\HttpKernel",
      "type": "->"
    },
    {
      "file": "/home/tac/g/sites/pulse/vendor/symfony/runtime/Runner/Symfony/HttpKernelRunner.php",
      "line": 35,
      "function": "handle",
      "class": "Symfony\\Component\\HttpKernel\\Kernel",
      "type": "->"
    },
    {
      "file": "/home/tac/g/sites/pulse/vendor/autoload_runtime.php",
      "line": 29,
      "function": "run",
      "class": "Symfony\\Component\\Runtime\\Runner\\Symfony\\HttpKernelRunner",
      "type": "->"
    },
    {
      "file": "/home/tac/g/sites/pulse/public/index.php",
      "line": 5,
      "function": "require_once"
    }
  ],
  "hydra:title": "An error occurred",
  "hydra:description": "Session was used while the request was declared stateless."
}

But that is the BC break. Being able to define a request (or route) as stateless is fine, but a stateless firewall should not automatically assume that all requests are stateless (only the authentication is).

Yes - this is an annoyance. We're using Google's IAP for authentication which works by passing us signed headers, and so whilst the authentication is stateless, the pages being served are anything but (CSRF tokens, flash bags etc).

On the plus side, at least I now know that I can fix it by marking a crap-ton of routes as stateless: false :)

(Edit: Actually can just mark all of the routes in question as not stateless en-masse via our attributes.yaml, so it's an easy fix!)

Got bit by #48044 again. Is there a chance a PR reverting this behavior would be accepted? AFAICT there wouldn’t be any BC break doing so.

Let's discuss this on a PR indeed.

Got bit by #48044 again. Is there a chance a PR reverting this behavior would be accepted? AFAICT there wouldn’t be any BC break doing so.

IMHO it might be the reason why there was so many PR about "fixing" session access in stateless request. (And my misunderstanding about this feature)
I personally never used stateless request, only stateless firewall but I had to fix tons of "Session was used while the request was declared stateless." errors.