[SecurityBundle] Revert adding _stateless
attribute to the request when firewall is stateless and the attribute is not already set
#58017
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
#40372 was about routes matching both stateful and stateless firewalls: you couldn’t easily configure them as stateless under a stateless firewall only.
#48044 fixed it by linking these two attributes: a stateless firewall then implied a stateless request. While it can sound logical, this impacted many projects using the session while authenticating users in a stateless fashion.
At last, #49997 allowed to override this behavior by explicitly configuring routes as not stateless. This kind of proved that #48044 was a mistake: you cannot tell a request must be stateless only because it matches a stateless firewall.
As such, this PR reverts #48044 (and consequently #49997) so that configuring routes as stateless is the developers responsibility alone. It also reopens #40372, but I think this issue should be fixed in an opt-in way (with a new
firewall.stateless.with_routes
boolean configuration in the SecurityBundle e.g.).