- Issue created by @malcomio
- 🇬🇧United Kingdom alex_sansom
This seems to be because when user_logout() gets called it destroys the session. If you only invalidate the session rather than destroy it, you're able to switch users OK.
- Status changed to Fixed
over 1 year ago 9:05pm 21 September 2023 - 🇳🇱Netherlands roderik Amsterdam,NL / Budapest,HU
Thanks for that last comment, it convinced me it must be the module and I'd have to take a look.
This meant that I couldn't delay learning more about session handling... because I couldn't just go along with the part of "not destroying the session", without knowing more:
- Would that run any risk of data from the previous session into the next?
- That would mean we can't use Core's helper method (user_logout()). How risky is that?
- Am I sure about what you mean with "the session" anyway?
...so... several weeks later I emerged out of this rabbit hole with detailed knowledge about Drupal's Session code, two potential blog posts and at least three Core issues to work on. (I won't yet, because I really need to do other things now. They may appear as related issues here... sometime.)
As it turns out:
- This issue has existed (the option hasn't worked) since Drupal 9.2, or #2238561: Use the default PHP session ID instead of generating a custom one →
- Before this, the option was... not very nice either (details withheld). Reading that older code proved to me that doing a logout + login was never really supported.
- I guess you meant specifically "call Session::invalidate() instead of SessionManager::destroy()".
- I agree now that this is the solution. Which unfortunately means that I can't call user_logout(), and we are not protected against any future changes to that function. No other workaround/preparation currently works.
- Luckily, I'm now sure that the comment against calling Session::invalidate(), present in user_logout(), isn't actually true.
Further: I couldn't reproduce this on D10. As it turns out, this whole thing isn't an issue / the configuration option is unimportant if you set the ' samesite policy → ' for the session cookie to either "Strict" or "Lax" (because Lax also strips the cookie from the POST request), if the IdP is on a different domain (or hostname, depending on cookie domain settings, I guess).
Change is in the commit I just pushed. The comments/changes around PrivateTempStorage can be ignored; they are just adjustments to other changes in D9 core.
I added a /saml/reauth route for easier testing (though I'm not documenting it; it's harmless but I don't see the usefulness for anything except testing re-login of a different user).
Automatically closed - issue fixed for 2 weeks with no activity.