Out of context access to the session store

[AdamHamilton]

We have a fairly large deployment of StateServer for a web farm's application cache and ASP.NET session state storage. We have a complex use case we need to support, which we were told during the sales process (years ago, this project has been on hold for a time) should be possible. However, we are having trouble figuring out the specifics and can't find documentation for a few of the objects involved. Here's what we need to do:

We have a multi-user application. Sometimes, one user's action affects the stored session data for another user. For example, one user might revoke another user's access, at which time that target user's ASP.NET session state object needs to be modified to indicate their reduced permissions. So the first user needs to update the second user's session values.

We want to solve that problem soft of like this:

• Apply [SossIndex] to properties of the object stored in ASP.NET Session State for each user.
• Query the cache containing the session state values using this indexed property to find the affected sessions.
• Modify those objects and store them back to the cache containing the session state objects.

It seems that these are all things StateServer can do. However, when we initially tried this we got this exception:

The supplied key is for an ASP.NET session object. The NamedCache API cannot access objects of this type -- use the SessionAccessor class instead.

The SessionAccessor object seems like something we could use to solve this. However, it is undocumented or we can't find the documentation. How can we use this to:

• Index properties of objects stored in the ASP.NET session state cache?
• Query on those indexes to get a list of sessions matching a certain indexed property?
• Modify and write those session objects to the ASP.NET session state cache?

Thanks for pointing us in the right direction!

 

[AdamHamilton]

I just checked with our ops team and I think we also have the "Standard Support and Maintenance" plan for our install. If needed to answer this, could we escalate this as one of our allowed "non-error support" cases?

 

[admin]

Hi Adam,

If you have data that needs to be modified outside of a user's page request then you'll almost certainly want to move it out of session state and into a separate object that's accessed through our NamedCache API and is keyed by UserID instead of a session ID.

(I found your original list of requirements from 2015, but I don't think we realized back then that you needed to query ASP.NET session objects--the assumption was that you'd be querying cached objects that were stored via our NamedCache API.)

Anyway, you're having trouble with the query approach right now because:

• The [SossIndex] attribute is only honored by our NamedCache API, so objects buried in a Microsoft SessionStateItemCollection won't get indexed by the ScaleOut Service.
• ASP.NET session state is its own, isolated API we don't have much control over, and the way that objects are serialized and stored makes it difficult for any client except an ASP.NET page handler to access session data. So our NamedCache API throws the exception you reported because it knows you won't be able to anything useful with the blob you get back.

Also, the ScaleOut SessionAccessor class you noted is an internal classs that's really only intended to be used by our ASP.NET provider in the context of a normal web request doing session management.

So it would be tough to try to access and modify another user's session object. It could probably be accomplished with enough code and time, but it will take a quite a bit of work because ASP.NET is going to fight us every inch of the way--it deliberately goes to some lengths to keep sessions isolated from each other. I'd really advise against trying it, but if it's a firm requirement then we should take this discussion off the public forum (we'll really be abusing our low-level APIs if you want to do this). Moving the data in question out of session state would be a much, much smoother implementation.

 

[AdamHamilton]

Thanks! We've been outgrowing ASP.NET Session State for some time now, so it probably makes sense for us to just start managing this ourselves. I was hoping for an easy solution for right now, but I think we were always going this direction in the long term anyway.