I'm pretty basic with .net
But basically I've been told that to have session stickiness for my website in the environment it is to be deployed means I have to get session from the cookie ASP.NET_SessionId
But what does this mean/how do I use this?
And where I am using my existing session code e.g. Session.Add("Something", something) do I now need to change this?
This is automated for you
You don't have to manually read cookies yourself. Asp.net does it for you. So whenever you access Session dictionary your session will already be preserved if it existed from your previous request(s). If there is none (or expired) it will also be automatically created so adding items to it will make it work without a problem.
So basically instead of accessing Session identifier from a cookies and do whatever with it (as you won't be able to access intrinsic session store), just use Session:
Session["SomeKey"] = myVar;
// or
Session.Add("SomeKey", myVar);
and for reading
var o = Session["SomeKey"];
Are cookies mandatory?
Basically Asp.net supports other means of session ID storage apart from cookies. You can enable cookieless session if you wanted to (a setting in web.config file). Session identifier will be added to your URL like:
http://www.example.com/(S(lit3py55t21z5v55vlm25s55))/orderform.aspx
Read more about it here on MSDN.
What's the default?
By default session identifier is preserved in cookies. That means that you don't have to change anything in web.config. But if you'd like to use other means you'd have to set that in web.config (check the same upper link as before).
Typically the way that I use session variables in ASP.NET is like this
// set
Session["SessionVariableName"] = localVariable;
// get
localVariable = Session["SessionVariableName"] as LocalType; // then check nulls
The issue with any sessions is that if you don't go out of your way to change it, the default stores sessions in-proc so every time IIS recycles a worker process your session is lost. This can be easily fixed by using the built-in ASP.NET State Service. A quick search turned up this article on using it.
You can get a reference to the current session in multiple ways but the most easy way is just use the session property on the page.
See:
http://msdn.microsoft.com/en-us/library/system.web.ui.page.session.aspx
Session stickiness is not a feature of ASP.net, but rather of a load balancer that may sit in front of it. If you are using InProc sessions, then the session data is stored in the server's memory. With "sticky" sessions, the load balancer will send all requests from the same source (based on IP usually) to the same server to ensure that the session always exists.
This isn't the most scalable way to handle a web farm scenario. Microsoft introduced two other mechanisms, StateServer and SqlServer which serve to send the session data to a single location for all web front ends.
You likely just need to make sure you don't have cookieless set to true in your configuration.
Regardless of how this is all configured, you will always retrieve your session data the same way - ASP.NET abstracts the details away.
// Set
Session["mySession"] = "Hello World";
// Get
var s = Session["mySession"];
Related
I have list of Objects containing no sensitive data ( i.e. simple settings of a widget at client side 5-6 integer values and Guid, probably multiple widgets at the same time).
At the moment, I am using ASP.NET MVC Session. It doesn't seems to be relieable. It is getting null time to time for certain keys those are stored inside that. It happens when I launch application at debugging or Network is slow.
Can I use Client side session Storage for storing all settings? ( i.e. sessionStorage or localStorage ).
I am concerned about IIS re-cycling which causes session to remove
or any server side exception.
Edit
public ActionResult ApplySettingsForDashboard(DashboardCommonSettings settings)
{
Session[string.Concat("SettingsToApply_",settingsToApply.PanelGuid)]=settings;
}
public DashboardCommonSettings GetSettingsFromSession(string PanelGuid)
{
var settings = Session[string.Concat("SettingsToApply_",PanelGuid)]
}
Comments and suggetions are welcomed.
Thanks
On the basis of comments, I want to answer in a way : Use Out-Proc Session storage ( persistent storage ) for reliable session storage as much as possible. It would be slow, so need to be used cautiously. In-Proc session storage is highly unreliable specifically at production environment. Either localStorage ( client side ) can be taken as an option when we don't have sensitive data.
Other answers are also welcome.
What I'd like to do is to create different cookie values for different browsers in .NET environment(cache with the same functionality is also ok, but I couldn't figure out how to use cache for that).
To clarify, I want users to be able to open my web app in different browsers simultaneously(e.g. on both Chrome and Firefox at the same time) where different values of a cookie can be used on the different browsers(for instance, cookie name is "MyCookieKey", i'd like to store a value V1 for Chrome and store a different value V2 for Firefox). And the cookie should be valid for solely the clientside.
What I've tried till now(separately):
HttpContext.Current.Request.Cookies,
HttpContext.Current.Response.Cookies,
HttpCookieCollection.
When I've used HttpContext.Current.Request or HttpContext.Current.Response, my app didn't work(i couldn't figure out what exactly the problem).
When I've used HttpCookieCollection, different browsers shared the cookie.
Regards.
Web Apps in general do not keep track of separate machines accessing them, they just keep track of different browser Sessions. Each instance of a client connecting to your app will generate a new session, and the information about this session is generally managed via a special cookie named ASP.NET_SessionId. The configuration for tracking the session allows changing the cookie name or to use non-cookie tracking. This tracking of Sessions can be utilized in a few different ways to differentiate between the separate browsers.
One method would be for your application to keep track of the session count. This would be done via global.asax and adding to the different application and session events. There are a few answers in the SO thread titled How to count Sessions in ASP.Net.
protected void Application_Start() {
Application["LiveSessionsCount"] = 0;
}
protected void Session_Start() {
Application["LiveSessionsCount"] = ((int)Application["LiveSessionsCount"]) + 1;
}
protected void Session_End() {
Application["LiveSessionsCount"] = ((int) Application["LiveSessionsCount"]) - 1;
}
And when it is time to set your cookie; you could access that Application object to retrieve the count, and use that to create a different cookie value.
int LiveSessionsCount = (int) Application["LiveSessionsCount"];
string MyCookieValue = "V" + LiveSessionCount.ToString();
Response.Cookies["MyCookieKey"] = MyCookieValue;
The problem with this would be that the application is keeping track of current sessions. This will increase and decrease as connections to your site start and end. What you could do would be to add a second Application variable that has similar methods in the App/Session starts to start at 0 and increment; however, do not add in the Session End decrement of that value. This would then be a total count of sessions within the app cycle. When the site is restarted this would return to 0.
There are naturally other methods you can use, one of the sites I work with logs all connections into a database and worked with that way. This is just to give you some ideas on what can be done. I would read the documented links to get a better understanding of the application and session objects; as well as the session cookie.
I have this piece of code:
var thisUser = Session["user"];
if (thisUser == null)
{
LogFile.Log("Logging out");
Response.Write("xp");
}
I am trying to track down why sometimes when I play with the system for a few minutes and suddenly the user session variable gets null.
It happens randomly in different scenarios.
I do not set the Session["user"] to null at any point.
Session timeout is set to 20 minutes.
I do not call Session.Clear() at any point.
Any ideas\thoughts\things I should look at as to why is it may happening?
I am using Firefox if that to any help.
The system is built with asp.net.
For more info please ask.
are you calling the same host? if the base URL is different the server will treat this as different users. for example:
http://localhost/path/to/resource and http://localhost:80/path/to/resource
both point to the same resource, but the requests are different and the session cookie will be different, or not present.
An easy way to test this is to launch your browser's developer toolbar and monitor the network traffic. compare the URLs to make sure they are the same base path and the same session cookie is passed in the request.
First of all this looks like C# and ASP.NET, not classic ASP. Now if you never clear the session yourself and the server (or the app pool) is never restarted, then the only way to lose the session is to clear the browser's cookies.
Editing the web.config will recycle the app pool, which clears the session info.
I am using session to do two things:
Keep track of which css file to load for a particular company.
Keep track of the Company Id Guid that tracks what company we are in.
I am seeing that this is coming in as null sometimes but I'm not getting a consistent problem to track down. I have no doubt this is probably something in my code that I need to track down but this bring me up to my questions about session...
Am I relying on Session to much to pass information between screens?
Is it consistent?
What could be clearing it between page loads?
Is session easily cleared by the user?
Should I be using something else more reliable?
I am worried that I will move this to live usage and have all kinds of problems.
I'm simply doing this:
Session["Css"] = css;
and reading it the same way:
css = Session["Css"]
UPDATE
The session I am using:
HttpSessionStateBase Controller Session
There are a few types of Session State. InProc, StateServer, and SqlServer. I believe the default is InProc. You can read more about this on MSDN here and here.
Each of these will obey the timeout value for sessionState defined in your web.config file. For a single server setup (which is what I typically do) I usually have my sessionState setup as follows:
<sessionState
mode="StateServer"
stateConnectionString="tcpip=127.0.0.1:42424"
timeout="2880" />
This is the same default timeout as Forms Auth, so my sessions will stick around as long as my users auth cookie/session. This will require you to set the start up on the ASP.NET State Server to Automatic. Below is my high-level pass at explaining the types and their potential drawbacks.
InProc
This will be reset everytime the application pool recycles the worker process for the web app. I believe this is what is happening to you, and this is why your session variables are null at what appear to be random times.
StateServer
This will persist state across apppool recycles, but requires that you enable the ASP.NET State Server Service, and change it's start up type to Automatic.
You can run into issues if you have a web farm or multiple web servers handling the website, unless you run a dedicated state server.
This requires that variables stored in session variables are [Serializable].
SQLServer
This will persist session variables to a SQL database, and is is generally the best approach for a web farm situation.
This requires that variables stored in session variables are [Serializable].
Could you not be writing your method to GetCss() something along these lines?
GetCss() {
var css = (CastToYourTypeHere)Session["css"];
if(css == null) {
//do whatever you'd normally do here to set the css,
//e.g. get the users guid and find their company css, and set css equal to it
css = myHypotheticalGetCssBasedOnTheUserFunction();
}
return css;
}
That way you're kind of covering all bases in that, you can happily use Session, if it it's lost for whatever reason you're just re-running your initial 'getCssForThisUser' type code.
IMO, session isn't a bad way to hold this kind of data for each user between pages in the type of example you've described.
I've read that you can store classes directly into a session variable i.e.
Session["var"] = myclass;
My question is how the memory management works. Does it automatically serialize this into the session on the client side?
Or does it hold the data for the instance of the class in server memory, and just holds a reference in the session object?
ASP.Net will store your object in a static nested dictionary in memory on the server.
It then sends a cookie to the client with the session ID.
Next time the client sends a request, ASP.Net will retrieve the session associated with that ID from the outer dictionary, then give you the inner dictionary containing the objects in that session.
(This is the way the default session provider works; other providers can serialize objects to SQL Server, or do something else entirely)
You don't store classes in the session but instances of these classes. And yes the default session store is memory. You can use SQL Server as session store as well however. Then some serialization will take place.
The session data is not available on client side.
It depends on how you have sessions set up in ASP.NET. The default is the session resides in the server's memory, and is basically just a dictionary. The user is given a session cookie which is used to identify which of these session dictionaries to grab for a given request (one session dictionary per user)
The object never gets sent to the client because the client only has a cookie, and cookies are too small to hold much of anything, and besides sending an object to the client is likely a security problem.
You can configure ASP.NET to use a database instead of memory to store the session, that is detailed here
The Default Session store is in memory. Which is the easiest to use because the objects dont necessarily need to be serializable.
If you changed the session store to lets say SQL SERVER Database. Then all the objects you store in the session will need to be serializable or else they will throw an exception.
Your Session by default only lasts 20mins. You can change this in the web.config to be as long as you want. But after that time is up, the Garbage collection will remove it from memory.