Simultaneous sessions management in .NET Core.

Photo by Fredy Jacob on Unsplash

In the era of REST, stateless distributed micro-services, open API, refresh tokens, etc. in enterprise (and not only) web applications “traditional” session approach still often been used. Generally, session idea is to link HTTP requests between each other and let web server to know about this connection. Using cookies for this purpose is quite convenient: web server while using session id, which is stored in the cookie and travels from client to server and from the server to client correlates which request belong to the same session.

During implementing web app in enterprise this year, the requirement of security department was to allow only one active session for one app user. If there is already user session in the app than the same user when logged on from another browser or a tab should override current existing session. Security department argued that in the case of a user has been hacked, it would be easier to track down the attacker for single browser.

To achieve this we’ve used .NET Core 3.1 SessionState. Few years ago I’ve implemented (or more precisely, adopted ) SqlSessionStateProvider to be used with WCF service, which was an abstraction layer for session storage in the database. This approach solved session issues in clustered Backend applications.

Photo by Tyler Nix on Unsplash

Implementation of .NET Core session is a totally new approach comparing to the “classic” .NET session and sometimes leads .NET developers be a little bit confused about it.

First of all, is session id generation: .NET Core server API returns encrypted sessionKey, which is an unique cache key (in .NET Core session stored in cache, and to make session working, cache storage has to be configurated). It can be done by adding caching middleware, for example for Redis, NCache, or Distributed Memory Cache(which isn’t an actual distributed cache. Cached items are stored by the app instance on the server where the app is running).

We’ve used Distributed SQL Server Cache, which is based on the SqlServer table (e.g. app.Cache) to store cached data:

Session objects are also stored in this table while .NET Core DistributedSession manages session: session sliding, data storage and session expiration.

The encrypted id column from the app.Cache table is stored in session cookie in .NET Core. It is not session id from the Session object.

The next important thing is encryption key for the session key. It is not a machineKey (as it was in .NET Framework). By default for IIS app it is stored in %LOCALAPPDATA%\ASP.NET\DataProtection-Keys folder. These settings are generally appropriate for apps running on a single machine. For our cluster we’ve used configured UNC share for cluster machines instead of at the %LOCALAPPDATA%:

var share = configuration.GetValue<string>(“KeysSharePath”);if (!string.IsNullOrWhiteSpace(share))
{ services.AddDataProtection()
.PersistKeysToFileSystem(new DirectoryInfo(share));
}

To track current user already has been logged in the application, app.UsersSession table has been created (here is FluentMigrator migration for the table):

Create.AppTable(TableNames.UsersSession)
.WithColumn(“SessionKey”).AsString(449).NotNullable().PrimaryKey()
.WithColumn(“SessionId”).AsString().NotNullable()
.WithColumn(“Login”).AsString().NotNullable()
.WithColumn(“UserId”).AsInt64().NotNullable().Indexed()
.WithColumn(“TimeStamp”).AsDateTimeOffset(7).NotNullable() .WithDefaultValue(DateTimeOffset.UtcNow);

In this way, when user logs in application we upsert record with SessionKey, UserId, UserLogin into app.UsersSession table:

where the SessionKey is unique key from app.Cache table and is encrypted in the session id cookie.

Important thing in process is to have this key during session creation on the server and upsert into the app.UsersSession table before session id has been sent to the browser.

In default .NET Core session implementation it is a private property: https://github.com/aspnet/Session/blob/master/src/Microsoft.AspNetCore.Session/DistributedSession.cs, but we have needed it to be public to have a possibility to save it in the database.

The solution was to override .NET Core session implementation to make session key public. In such a way, Distributed SQL Server Cache and overridden DistributedSession manage session expiration date, we do not care about it and only can check is current user has active session for session key received from the browser in the app.UsersSession table.

Due to upserts into app.UsersSession table we have only one record per user. Once more feature should be added is SessionMiddleware, where current user session is validated:

The full code for session manage you can find here: https://github.com/alekshura/Ankara/tree/master/Compentio.Ankara/Session.

Good luck and thank you!

Photo by Massimo Sartirana on Unsplash

Software architect with a wide tech stack interests from database to gui, from monolith to cloud native.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

SQL Project — One Beautiful Morning

One way to create Bot — Slack

Analyze data in RDS and DynamoDB with Standard SQL

My first VR project — Experience

How to Choose the Best VPS Hosting in Cyprus

Industry 4.0: The importance of machine data

let’s try this again

Analytics

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Aleksander Parkhomenko

Aleksander Parkhomenko

Software architect with a wide tech stack interests from database to gui, from monolith to cloud native.

More from Medium

Xamarin Forms: Client-Side caching

StaticResource & DynamicResource in Xamarin Forms

N-Layer Architecture In A Multi-Project Solution

Avatar View | Xamarin.Forms | Xamarin Community Toolkit