[SecurityBundle] Set request stateless when firewall is stateless #48044
Conversation
|
Hey! I think @TimoBakx has recently worked with this code. Maybe they can help review this? Cheers! Carsonbot |
|
Thanks for the PR. |
bbbc0ee to
6923cb3
Compare
|
I rebased on branch 6.3 😄 |
|
This looks wrong to me. Something else than the Firewall could still be using the session. |
|
@stof Sure, but that's why you want a warning IMO. If the firewall is stateless then you shouldn't rely on the session and opening one will most likely result in data loss or at least inefficiencies in the code as it reads from session storage for nothing. |
6923cb3 to
ce458c6
Compare
|
Thank you @alamirault. |
|
I tend to agree with @stof here: while it's true that most stateless firewalls are used with stateless routes, this is not systematic and you can have stateless authentication (using JWT cookies or an HTTP middleware adding trusted headers to the request for example) but still require sessions for some specific pages (for CSRF tokens or flash messages for example). I believe we should at least allow this behavior to be overridable if the current request is already marked as |
…bute is not defined (tucksaun) This PR was merged into the 6.3 branch. Discussion ---------- [SecurityBundle] Set request stateless only if the attribute is not defined | Q | A | ------------- | --- | Branch? | 6.3 | Bug fix? | yes-ish | New feature? | no | Deprecations? | no | Tickets | #48044 (comment) | License | MIT | Doc PR | n/a The current implementation makes sense for most cases but not for every case as one can have a stateless authentication but still requires sessions. This PR allows setting the request as non-stateless while having a stateless firewall but keeping the new behavior by default. Commits ------- 5f29c8d [SecurityBundle] Set request stateless if the attribute is not already defined
…ed (alamirault) This PR was squashed before being merged into the 6.3 branch. Discussion ---------- Set request stateless only if the attribute is not defined symfony/symfony#48044 added in 6.3 was updated in symfony/symfony#49997. This PR ajust behavior documentation Commits ------- 20ee4d7 Set request stateless only if the attribute is not defined
|
Our software falls into the case described by @tucksaun, so after updateing to 6.3 it breakes our software. Instead of using the signin methods provided by Symfony, we load the user object from a external server with a session id cookie written by an external SSO software. For this we use a custom, stateless authenticator. We also use Symfony sessions, but not for authetication, which triggers the "Session was used while the request was declared stateless." exception. Is there any way to override this behavior? I found his pull request (symfony/symfony-docs#18195) but I didn't find any documentation what to change in order to get the old behavior |
|
@johannes85 you can define the request as stateful via the routing: #config/routes/security.yaml
app_logout:
path: /logout
methods: GET
defaults:
_stateless: false// [...]
class DashboardController extends AbstractDashboardController
{
#[Route('/admin', name: 'admin', stateless: false)]
public function index(): Response
// [...] |
|
Thank you. I wasn't sure if it is that easy or if I do something "not the symfony way" which will break someting else. |
|
I've opened #50715 for further discussion. |
…he request when firewall is stateless and the attribute is not already set (MatTheCat) This PR was submitted for the 7.2 branch but it was merged into the 6.4 branch instead. Discussion ---------- [SecurityBundle] Revert adding `_stateless` attribute to the request when firewall is stateless and the attribute is not already set | Q | A | ------------- | --- | Branch? | 6.4 | Bug fix? | yes | New feature? | no | Deprecations? | no | Issues | Fix #50715 | License | MIT #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.). Commits ------- 47baed9 [SecurityBundle] Revert adding `_stateless` attribute to the request when firewall is stateless and the attribute is not already set
|
Reverted in #58017, see discussion there. |
Automatically add
_statelessattribute to the request when firewall is stateless