Populate extra session data for unauthenticated users

#1

Hi there,
I’m trying to figure out how to populate custom session data for users without having them authenticated. I’ve a custom session, CustomUserSession derived from AuthUserSession. The idea is that when a certain users access the application from a known ip address or with a api key in the header, I’d want to update certain properties. I was able to do this by hooking into OnCreated in Session Events. Is this a proper place to do this? Is OnCreated called just once when a session object is created for the first time for a user? I can’t hook into OnAuthenticated because I’m not authenticating the user.

Thanks!
Kebin

#2

The AuthUserSession is for Authenticated Users, you can use the base.SessionBag for storing arbitrary data against a Users Session. OnCreated is for adding user metadata available to SSE Clients.

#3

Thanks for the quick response!

What I am doing for the authenticated right now is that on authenticated I am populating custom user session with some “features” that user gets. Eg:

CustomUserSession:AuthUserSession
{
     public IList <string> Features{get;set;}
}

The intention now is to give certain users(not authenticated) the same “Features” as an authenticated users. In other parts of the application, we check if a user has certain Feature using SessionAs and getting back typed session. Would you suggest that we move the “Features” to SessionBag instead?

Where would you suggest to set this Feature? Global request filter and/or BaseController?

Finally is OnCreated in ServerSentEvents and Session Events the same hook?

#4

Please don’t use Interfaces on DTO’s, use the concrete List<T> instead, interfaces are horrible on DTO’s and IList<T> is especially useless given it nearly always wraps a List<T> which has more functionality available to it.

If you’re going to give non-authenticated users the same access as authenticated users why not remove the feature check? or maintain a the list of “public” features in an AppSettings configuration, where if the feature is defined in AppSettings it’s considered public, otherwise fallback to the Authenticated Users Features collection to see if they have access. Seems weird to conflate auth/non-auth user features together.

They’re not the same hook, OnCreated() on ServerSentEvents has nothing to do with Auth Session Events or even Sessions for that matter, OnCreated() is called each time a SSE connection is made.

#5

Thanks for the suggestion on using List instead of ILiat on DTOs! Will definitely do.

The issues with features is that there are 3 different types of users. Authenticated with accounts, non-authenticated but recognized users (schools, libraries) via IP address or unique key and then finally general visitors. Certain features are granted to these schools and libraries without having to create accounts. To go one step further, each of these schools might be granted different features. I guess AppSettings would not really do the job here, unless I make an entry for each of those schools.