You see the code below, how I did use the session variable;
So the three questions are:
Where are they stored? (Server or Client side)
Are they unique for each web page visitor?
Can I remove it using ajax or simple js code when my job is done with it? or it will be removed automatically..?
.
sbyte[][] arrImages = svc.getImagesForFields(new String[] { "CustomerName", "CustomerSurName" });
Dictionary<string, byte[]> smartImageData = new Dictionary<string, byte[]>();
int i = 0;
foreach (sbyte[] bytes in arrImages)
{
smartImageData.Add(fieldNames[i], ConvertToByte(bytes));
i++;
}
Session.Add("SmartImageData", smartImageData);
Read more about sessions here. To answer your questions:
Depends on your configuration (in-process, Session State Server etc.), but always server-side.
Yes, each visitor gets a unique cookie.
You can remove it client-side by removing the session cookie (usually ASP.NET_SessionId), or server-side by calling Session.Abandon(). Also, a session times out after a certain (configurable) period of inactivity.
Session variable are stored on the Server? You can configure other state management mechanism (E.g Database).
They are unique for each user session. It will be removed when Session times out.
Session state information is stored on the server and not on the client side. When the session expires, this session information is removed completely and automatically. You can change the session expiration duration through web.config file. Session data is unique for each user. You can always use it using ajax or change it or even remove it.
If you want the session data persistent to be persistent, you can configure your database for storing the session information. You can even configure a state server to store the session data.
The session is usually stored on the server (depending on your server/application configuration). Each unique browser connection is allocated a session id which the server uses to associate the client with a unique server session on subsequent connections. The session id is passed to the client to store as either a cookie, or as a paramater attached to each url request to the server.
It is used as a means of preserving client state with the server between HTTP calls.
The session expires after a configurable time of inactivity. However in .NET you can call Session.Abandon() to end the current session.
Related
We use a DistributedSqlServerCache to store user session data but I have noticed some unexpected/strange behaviour. So I was wondering how a DistributedSqlServerCache works under the hood to help me understand the behaviour that I am seeing.
When a user arrives at the site, immediately a DB entry is inserted, as seen below in img 1.
When the user logs out or the session times out, the session data is cleared (replaced with some arbitrary default value) and the ExpiresAtTime is also reset, as seen below in img 2.
Again, another user arrives at the site, and a new DB entry is inserted, as seen below in img 3.
But this time, if the application pool is recycled or the IIS is reset, then the below (img 4) is the result in the database:
It appears that the original session has not been emptied and also a new session is started.
For completeness, here's the code we use in StartUp.cs:
services.AddDistributedSqlServerCache(o =>
{
o.ConnectionString = "conn_string...";
o.SchemaName = "dbo";
o.TableName = "PS_PWD_SESSIONS";
});
services.AddSession();
Unless I’ve got the wrong end of the stick, this doesn’t make sense to me. I would be very grateful for any insight into this behaviour.
It's best not to worry about this too much. ASP.NET Core knows what it's doing. I think the behavior you're seeing is a result of session key vs. session id. The session id is tied to the actual physical session, persisted in the database here. However, the cookie that gets sent to the user contains only a session key. This session key is always valid and never expires. The client then always sends back this cookie with the same session key, and ASP.NET Core internally decides whether to restore the previous session or create a new one, based on whether the session has expired, etc.
In other words, the underlying data in the actual database doesn't necessarily reflect existing "sessions", at least from a client perspective. To the client, their session lives forever, but in the database it could be deleted. If there's no active session in the database to correspond with the client's session key, then ASP.NET Core just creates a new one.
It appears that I am able to read the SessionID at any time, even if no cookie currently exists!
Dim SessionID As String = Request.Cookies("ASP.NET_SessionId").Value
This code will always return a value, presumably the ID held by IIS server side.
The cookie appears to be generated only when a request to store session information is made.
Why is this?
and ...
If I am using session state server will the SessionID ever differ from the cookie SessionID and which take priority if one of the ID's is lost or reset?
EDIT
If the app_pool is reset. A new session ID must be created will this cause the session cookie to be updated also? As this could create potential conflicts for users already logged in.
When a user accesses a website powered by ASP.NET IIS generates a SessionID to uniquely idetinfy the users session.
If the website is using cookies:
<sessionState mode="StateServer" cookieless="UseCookies"/>
A cookie named ASP.NET_SessionId will be generated only when a request to store session information is made by the webpage. If no session information is stored a cookie will not be created but the user will still have an active SessionID.
The SessionID is read from IIS when no cookie is present.
The SessionID on the server always takes precedence and will update the session cookie when a new request to store information in the cookie is made.
Every time that an user access the website and a session is opened ASP.Net by default creates a SessionID unless you specify the cookieless option:
If you are using a session state server the SessionID should be the same across all web servers otherwise you wouldn't be able to find the same user.
If the ID is lost or reset the state server will simply create a new one and write a new cookie with the new SessionID and the old one will be deleted after the expiration time.
I'm almost sure what I'm looking for exists, but I didn't finding on Microsoft documentation nor here.
I just want to get an unique ID (a string or a number, I don't really mind) from a client in ASP.NET 4.5, on the server side. I want this ID linked to a session, so different for each system that would connect to my server (like multiple computers or same client with different browsers), but the same if a user open multiple tabs on the same browser on my server.
I already looked on:
System.Web.UI.Page.ClientID: It is the name of the control (so always "__Page").
System.Web.UI.Page.UniqueID: It returns the same.
Session.LCID: I'm not sure to what it refers to, but it is the same if I connect to my server with different browsers.
Session.SessionID: Change each time I refresh the page or open it in a new tab.
Request.AnonymousID: Is null.
So all my attempts gave me an ID that changes everytime or never. Is there any way to get something from session ?
What you are looking for is in fact the Session.SessionID, however it comes with a caveat.
From MSDN:
When using cookie-based session state, ASP.NET does not allocate storage for session data until the Session object is used. As a result, a new session ID is generated for each page request until the session object is accessed. If your application requires a static session ID for the entire session, you can either implement the Session_Start method in the application's Global.asax file and store data in the Session object to fix the session ID, or you can use code in another part of your application to explicitly store data in the Session object.
I suggest using REMOTE_ADDR / REMOTE_HOST values from ServerVariables collection. These would have same values even if the user is using multiple browsers and uses different sessions from the same machine. Note that REMOTE_HOST might not always have a value.
References :
https://msdn.microsoft.com/en-us/library/system.web.httprequest.servervariables(v=vs.110).aspx
https://msdn.microsoft.com/en-us/library/ms524602(v=vs.90).aspx
In my web application I test for a condition on one page and want to retain the results of the test for a specified duration (such as 5 minutes). I can do this with a cookie, of course, but just in case a user has disabled cookies, I'm thinking a custom server varible might do the trick. I've heard about this, but I haven't been able to find out to do it.
Alternatively, maybe a session variable might be better? There's no inherent way to expire these, right? How long would such a variable survive before IIS tosses it?
Asp.Net has session state. Each Asp.Net Page has a Session property. You can also access it via HttpContext.Current.Session, though there is a subtle difference that won't matter until it bites you (which see my answer to the question, Difference between Session and HttpContext.Current.Session.
The default session state configuration is in-memory. That means that if your web site is served up from something like an F5 Networks Big IP (load balancer) cluster, unless the load balancer is set up to be 'sticky' (meaning that once assigned to a machine in the cluster, you'll always hit that machine unless it goes down or is otherwise removed from the cluster).
If your clustered web site doesn't have sticky sessions, your session state will vanish when your request hits a different machine...and then reappear when another request hits the original machine. You can guess how much fun that can be.
There is built-in support for SQL Server session that you can enable in your web.config. Once set up that way, you're using SQL Server as the backing store for session state. That solves the server farm issue noted above, but does so at the expense of hitting a SQL Server each and every time a session state value is accessed. That slows down access considerable, especially if the session size large. Oddly, executing a SQL query and shoving a 500kb session blog across the network every time you access a session state setting can negatively impact performance. Who knew? [Don't ask how we found that out].
There are other solutions to the problem: ScaleOut's products come to mind (e.g., ScaleOut SessionServer).
Or you can roll your own session state provider using something like an AppFabric cache.
Another "feature" of using SQL Server sessions state is that anything going into Session must be ISerializable.
You can't set a server variable; instead, using Session, which is tied to the current user, is the best approach for user-based data. For application-based data, you can consider cache. So assuming the former, do:
Session["Key"] = MyValue
Note that session lasts 20 minutes; if you have to have exactly 5 minutes, you can use cache, which you can explicitly expire at 5 minutes:
Cache.Add(CurrentUserID.ToString() + "Key", "Value", .. TimeSpan.FromMinutes(5));
You can use the ID of the current user to make the cache value specific to a user, or use cookies, but set HttpOnly=True on the cookie object. An HTTPOnly cookie is only on the server and never accessible on the client, as such:
varcookie = New HttpCookie("Key", Value);
cookie.Expires = ..;
cookie.HttpOnly = true;
Is session in Asp.net is shared between users of the website or not?
Client 1
stored value in session in page load like that:
Session["editStudentID"] = editStudentID.ToString();
Client 2
Visiting the same page of client 1 in the same time so there will be other session stored
Session["editStudentID"] = editStudentID.ToString();
so can client 1 or 2 sessions interrupted by each other ?! or the session is unique per client
No, it is not shared.
The server, where the Client is sending the request to start a new Session, assigns that client a new Session ID. This is a unique ID or Token per Client. Each Post or Get to the server generally sends that Session ID or Token with it in order to tell the Server who it is(an identifier).
Also all session variable data is stored on the server.
Session is per-session ID, and session IDs are normally per-browser (via a cookie or a URL parameter).
No, it is not.
When a client connects to the service for the first time the initial response includes a cookie which is used to track subsequent connections from that client. The cookie's value is then used whenever you reference the Session object to determine which data in the backing Session store is referenced.
So changing the Session data in any request will only alter it for that client. If you need to have data shared between multiple clients you have to provide a different mechanism for doing so - a static dictionary or similar.