Where is Session stored in ASP.NET Core and how best to use it?

Asked

Viewed 1,119 times

9

Knowing that ASP.NET MVC when it comes to Session should be taken care not to abuse too much of such functionality due to its memory consumption by the server can "weigh" the application.

Reading a little about her on microsoft website saw that you have the option to store in cookies on the client side, however the data becomes a little fragile due to the possibility of a user to manipulate cookies.

That Session of ASP.NET Core (2.2 specifically) has actually removed the server’s responsibility to store the Sessions? Where is it stored now? And what would be the best setting for it?

Configuration I currently use:

  services.AddSession(options =>
  {
    options.IdleTimeout = TimeSpan.FromSeconds(10);
    options.Cookie.HttpOnly = true;
    options.Cookie.IsEssential = true;
  });

2 answers

7


A session weighs on the server? So you’re doing something wrong.

A session on the server stays in memory as long as it takes or the ASP.NET policy determines, if the application does not invalidate, and if nothing goes wrong in the middle of the way that destroys the session. Don’t consider the session to be trustworthy and secure. It shouldn’t be common for you to miss the session, but don’t treat it as if it couldn’t happen. If it happens often there’s something very wrong with what you’re doing.

There are ways to change this, including allowing session distribution, but I don’t think that’s the case here.

One way to ensure more security in the data that would usually be in session is to store in database, so even a failure would still keep everything running if you have proper code to deal with this, it’s your problem to do it properly.

I’m talking about security in the sense of reliability and persistence not data protection, especially in sessions do not consider the data as safe, so be careful what you store in them.

There is the possibility to make the session itself be stored in database, but almost always does not make much sense because you can do otherwise with more flexibility and performance, the standard session is to be simple and with high performance.

Note that the session is, and has always been, controlled by a cookie, just don’t have the data kept on it. You need some identification to understand that you are "talking to the same person". I’m not going to go into detail about his use, but it’s just kind of a session signature and not the session itself. You can configure how this identification can be formed right there in the options you started to configure.

If you want data to be kept between sessions directly on cookie you can, it’s just not recommended. It’s complicated, a lot can go wrong and it’s less safe. Even configuring the way you did the data is still on the server.

There are other ways when the cookie is not interesting or does not work in a certain scenario, but in general are less safe.

There are other ways to maintain status when you don’t exactly need a session, analyze if you can use.

Additionally I have to say that the standard of Idle is 20 minutes, some people consider this little, you put in 10 seconds, which probably makes the session useless since it is extremely common not to have interaction for more than 10 seconds.

I don’t understand why you think the session isn’t on the server now, it’s still on.

  • I read in some places that excessive use of Sesssions can slow down the application, hence the observation. Regarding thinking that the session does not stay on the server was due to this relationship with cookies (in the browser) and this was recovered dynamically in the requests.

  • If you abuse it, of course it is bad. Cokkies have always been used, but never (under normal conditions) if you used the session in the cookie, only the same ID. Note that nothing has changed in ASP.NET, it has changed the way of configuring only.

  • Understood, thank you!

5

In ASP.NET Core a Cookie is provided to the User (client), which contains a Session ID that is sent to the server at each request, and the server uses the Session ID to fetch data in the session.

Here is some information about the session taken from the microsoft website:

  • Since the session cookie is browser-specific, it is not possible to share sessions between browsers.

  • Session cookies are deleted when browser session ends.

  • If a cookie is received from an expired session, a new session will be created that uses the same session cookie.

  • Empty sessions are not held-the session must have at least one value set on it to keep the session between requests. When a session is not maintained, a new session ID is generated for each new request.

  • The app maintains a session for a limited time after the last request. The app sets the session timeout or uses the default value of 20 minutes. Session status is ideal for storing specific user data for a particular session, but where data does not require permanent storage between sessions.

  • Session data is deleted when the Isession.Clear implementation is called or when the session expires.

  • There is no standard mechanism to inform the application code that a client browser has been closed or when the session cookie has been deleted or expired on the client.

  • ASP.NET Core MVC and Razor page templates include GDPR (General Data Protection Regulation) support. Session status cookies are not marked as essential by default, so session status is not functional unless tracking is permitted by the site visitor. For more information, see Support for General Data Protection Regulation (GDPR) in ASP.NET Core.

That is, session data continues to be stored on server, what is stored on the Client side is the Cookie with the session ID

Browser other questions tagged

You are not signed in. Login or sign up in order to post.