Deleted session from session store is not always deleted

[fbuetler]

Version

4.5.17, might affect 5.x as well

Context

This is in some way a follow-up of #2674.
In this issue, we learned that the destroyed attribute of a session is not synchronized in a ClusteredSessionStore.
Hence, the solution was to use sessionStore.delete(id) instead of session.destroy() to remove/destroy a session upon logout.

However, we experienced some issues with this approach when using the OIDC back-channel logout to log out a userin a LocalSessionStore. It might happen that a session, deleted through a back-channel logout, can still be access by a follow-up request, resulting in the user still being logged in!

Steps to reproduce

There is a reproducer attached. Search for TOGGLE THIS to experience the bug.

reproducer.zip

It works as follows:

1. Create a session and obtain the session ID
2. Start a long-running request using the session ID (does not necessarily need to be long-running but make the issue appear easier)
3. Simulate a back-channel logout by manually deleting the session from the session store (in a real-world case, this would be another handler)
4. Later, do a new request with the deleted session ID
5. Observe that no new session was generated, but the deleted one reused!

This is mainly due to interleaving requests

• request A using the session
• request B deleting the same session

When request A finishes, it runs through the flush end handler that puts the session back in the session store, if the session is not destroyed or regenerated.

It is possible to work around this issue in a LocalSessionStore by destroying the session (as expected).
However, remember that neither destroyed nor regenerated are synced in a ClusteredSessionStore, so for it to work in with both stores on has to destroy and delete the session.

Do you have a reproducer?

see above