Is asp.net core session not user specific?

Question

When i was working with classic ASP.NET or even with old web forms the HttpContext.Current.Session was User specific. So when user makes the request he receives the session cookie and then onward that session belongs to that user only. So two different users can have session key with the same name in their respective session.

I am reading the documenation on session in ASP.NET Core and looks like it has the same concept as old asp.net however certains notes in the documentation is confusing.
here it says

Session storage relies on a cookie-based identifier to access data related to a given browser session (a series of requests from a particular browser and machine). You can’t necessarily assume that a session is restricted to a single user, so be careful what kind of information you store in Session. It is a good place to store application state that is specific to a particular session but which doesn’t need to be persisted permanently

also here it says

Session is non-locking, so if two requests both attempt to modify the contents of session, the last one will win. Further, Session is implemented as a coherent session, which means that all of the contents are stored together. This means that if two requests are modifying different parts of the session (different keys), they may still impact each other.

so lets say i have User1 logged in and upon some action i set

 `Session.SetInt32("key1", 123)`

now User2 logs in from some other machine and upon some action i set

 `Session.SetInt32("key1", 999)`

Question 1
Will this overwrite User1's key?

Also note here says

ASP.NET ships with several implementations of IDistributedCache, including an in-memory option (to be used during development and testing only)

Question 2
What are the other implementation of IDistributedCache that i can use in production?

Duala

Answer 1

For Question 1.

No, one user modifying a session key will not overwrite a different user's key. The session is unique to each visitor/user because of the .AspNetCore.Session cookie that is created.

All of the Session.Set calls get stored per that unique identifier.

Jape

Answer 2

#1

Session isn't tied to a user because session is only identified by it's session key, so if someone gets possession of the session key/cookie, he can access it.

Asp.Net Core Identity has its own cookie (if you are using cookie authentication) and Session middle ware use its own cookie too.

Naturally, you can also use Sessions without a user. Take Google.com for example. When you first visit Google, it shows you policies and set a session cookie. All settings you do (i.e. maturity filter), will be saved in the session which gets accessed each time you perform a search.

This all without being logged in, so there is no user at all.

#2

Open Source is your friend: https://github.com/aspnet/Caching/tree/dev/src

Redis and SqlServer are the default distributed caches, with InMemory being for development / single-node only. There also may be other third party libraries which add support.

Oppen

for #1 how that is different than classic asp.net? session in classic asp.net works the same way i think. Also if session is not recommended then what option do i have to store user specific data – Duala

I didn't said its not recommended, depends on where you are using it (in WebAPI its pretty bad idea as WebAPI/REST Service should be stateless), for MVC its pretty fine to use it. If you want to tie it to a user, save the user id and ip in it, compare it on each request (i.e. write an middleware which checks it and if necessary invalidate the session if user and saved user id don't match) – Oppen

It's not different to classic, but people, and especially annoying security scanning tools, sometimes assume that session is linked to a user, so we call it out to be clear. – Absorbing

Its funny, I was reading this and thinking "why do people still use session?" - assuming it's for non-MVC and non-WebAPI work; my thinking has changed since MVC has risen and I always write MVC apps to be stateless as well as WebAPI now, and cant think when I'd need to use a session state cache. Redis - yes, but for caching rather than storing user state. User state for me is either transient (and passed to/from the client/server) or persistent (and stored in the db). Sticking it on the server means you (pretty much) have to use distributed persistence in a load balanced environment. – Anthropometry

@RussellYoung there are several reason i see i would use session. First of all not all applications need distributed persistence. Applications with smaller user base but needs better user experience can use session to store user specific information. Im using session to store Queue information that is user specific. I dont want to hit DB once the queue is built. I am using In memory session for this. – Duala