Allow additional Request or HttpContext properties to be linked to ServerSideSession

[105659]

Hi,

We are trying to create a nice page to display a list of Sessions for the current logged in user. But it would be nice to store extra information against the session.

So my suggestion is for a section in the AddIdentityServer() ServerSideSessions options. That allows you to list out any additional request headers or HttpContext information e.g. (IP, UserAgent) that is then linked to the Sid and stored in a table ServerSideSessionProperties.

options.ServerSideSessions.AddClientRequestIP= true;
options.ServerSideSessions.AddClientRequestUserAgent = true;

Then this additional information can be returned when querying the sessions via the manager.

Another way, would be allowing a different class to be used for ServerSideSessions:

.AddServerSideSessions()

[wcabus]

We currently have no plans to extend what is being stored inside a server-side session, but you can add custom data to the AuthenticationTicket stored in the session. There are multiple ways to add properties to the authentication ticket, here's an example when using ASP.NET Core Identity:

builder.Services.ConfigureApplicationCookie(options =>
{
    options.Events.OnSigningIn = context =>
    {
        // Adds a custom "User-Agent" property to the Items dictionary:
        context.Properties.SetString("User-Agent", context.Request.Headers["User-Agent"].ToString());

        return Task.CompletedTask;
    };
});

You can retrieve this data afterwards from a UserSession instance like so:

var userAgent = userSession.AuthenticationTicket.Properties.GetString("User-Agent");

For example, this is what you would get on the server-side session management screen (as implemented in the Quickstart UI):

Should you need more control over where the custom data is stored, or extend the database model, then you'll need to add custom migrations and add your own implementation for various services related to server-side session storage.

[105659]

Thanks for getting back to me and for the really helpful response. I had not thought about doing it that way.

Will there be any issues with size limits on the authentication ticket?

Not that I would store much in there. I guess with server side sessions all the information is stored in the DB, then the reference is stored in the cookie. So it should be ok.

[wcabus]

The cookie itself indeed only contains the reference to the server-side session. I wouldn't of course recommend storing entire blobs of data inside the authentication ticket.

Another reason to extend the data model, would be if you need to query server-side sessions based on the additional metadata: you won't be able to query information stored in the ticket, since the ticket is protected in the database.

[105659]

Yeah we have data protection enabled as well, as the servers will be load balanced. It would be nice to be able to query the additional data, but for the moment, just being able to have the IP and Browser details linked to the session is enough for end users to see which session is which. I can foresee that management here would want to have some reports based on browser usage etc etc. But that is something for a future time.