Data races in ServerSideSessions

[aomader]

I am wondering (more, I assume) that there are silent data races going on in the ServerSideSessions, since multiple writers exist and no synchronization is happening, leading to silent loss of data.

We tested this by explicitly marking Data as a concurrency token, so that we could see data races. When we were extending the user claims (and thus the AuthenticationTicket), we were seeing DbUpdateConcurrencyExceptions.

I would assume that this issue can be provoked by any kind of session modification currently, also from build-in ones, like the session coordination service that extends a session's lifetime.

[mahoekst]

Thanks for reporting. We'll take a look.

[mahoekst]

@aomader we were discussing this with the team and had some questions. If you see this on serversidesessions, it is kind of expected that we have conflicts, but since its a rolling window that shouldn't really matter.
But you mention a different path so we weren't sure if we really understood the issue here. Would you be able to clarify what you are trying to do?

[aomader]

I can for sure elaborate further, but be aware that I do not agree with that it "shouldn't really matter".

Let me first shortly explain my understanding of the basic building blocks.

Session updates

1. Applications reads whole session data into model
2. Application modifies session model
3. Application writes the whole session model (fat update)

In step 3, everything that was done to the stored session session in between steps 1 to 3, is lost silently.

This is due to the fact that IServerSideSessionStore has only one fat update method UpdateSessionAsync(ServerSideSession), which is not aware of what changes and must thus always write the whole data.

Components triggering session updates

Session coordination service (ISessionCoordinationService.ValidateSessionAsync)

Is triggered by client requests (not user ones) to update the lifetime of the session, i.e., the meta data (Renewed, Expires) and maybe also the AuthenticationTickets properties (the Data) via ticket renewal (see below).

Ticket renewal (ITicketStore.RenewAsync)

Normally triggered from a user request when something of the identity changed. For example, when a new claim was added to a user and the SignInManager.RefreshSignInAsync is called.

Concurrency issues

So even without doing any extensions at this point, it appears to me that it is quite easy to run into race conditions where data is silently lost. For example, a simple user profile update (front channel) that coincides with a backchannel request that would trigger session coordination can trigger it.

And as I see it, it is currently not possible to solve this, since there is only a fat update method and no fine grained approach which would enable something like optimistic concurrency, nor are there any synchronization mechanisms in place.