I have something strange going on with our session state.
Our ASP.NET C# application has a session timeout of 10 min, but it seems to be losing session state when redirecting between pages.
So, we set out session value, and redirect to the next step,
Session["temp"] = "somevalue";
Response.Redirect("page2.aspx");
At the top of page2, we check the session value, and if it's not there, redirect back to the start (the code below is the first on Page_Load):
if (Session["temp"] == null)
{
Response.Redirect("start.aspx");
}
The issue is it keeps on doing this redirect, even though the session should not have timed out.
I have checked the config file, and it has a machinekey, as I have been informed that this can sometimes causes issues if it's not there.
Is there something else that could be causing us to lose the session?
Depending how your session's configured, cookie problems can cause you to lose session. As can switching domains / switching between http and https.
And as an aside, if you're connecting over a mobile connection, all sorts of horrible things can happen to your cookies...
Disabled Coockies may be issue. You can also create brand new application (with default web.config without any change) with single page and test it. This will tell you whether the problem is application specific or server specific.
try to add to system.webServer -> modules section in web.config next lines:
<remove name="Session" />
<add name="Session" type="System.Web.SessionState.SessionStateModule" />
Related
We have a .NET Framework web app where we use .ASPAUTH cookie and ASP.NET_SessionId for authenticated user. Our Session.Timeout is set to 60 minutes in the IIS hosted web.config file.
Recently I follow the recommendation of OWASP top 10 to prevent possible information exposure by Disable caching for response that contain sensitive data.
I did this by adding the following in the Web.config file of the web app.
<httpProtocol>
<customHeaders>
<add name="Cache-Control" value="no-cache, no-store" />
<add name="Pragma" value="no-cache" />
<add name="Expires" value="0" />
</customHeaders>
</httpProtocol>
The very next day I start getting call from some users (not all) that they got redirect to the log out page by simply clicking on links in our web application. So I did what naturally comes to me is to roll back that change and off course that complains went a way gradually.
This puzzle me, as I don't know how http response caching directive could lead to invalidating a user session and log them out. Even though I see the issue went away, there is no way for me to confirm that it was due to my roll back of these header values.
I know the Pragma and Expires are from Pre HTTP 1.1 so I plan to add the following back in and see if I have the log out issue again.
<add name="Cache-Control" value="private, max-age=3600, must-revalidate" />
Do you think they are related? I researched around and all I could come up is the cache control really affect how often the user request resource from server. One factor I don't have control over is can something on the user's browser end that when combine with this Cache-Control directive can destroy their authenticated session?
Update: I see this refers briefly at this resource. However, they don't really go into the details.
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.
We have an ASP Web-Forms site that we update frequently.
However, any time we modify any classes stored in the App_Code folder, this causes an App Pool Recycle and loses all of our session state, causing our users to be logged out.
This means that any time we need to make changes in app code it needs to be around 2:00 in the morning to minimize user impact.
Now, since I value my sleep I was wondering if there is any workaround for this behaviour?
I've tried switching the application to use StateServer mode for Session State.
This seems to work as long as the class being changed is not currently in use.
However if the class is in use it results in every-bodies session being lost.
What is best practice in this case for a heavily used website?
Am I condemned to late nights every time we need to fix a bug in our classes?
Thanks in advance for any response...
You will need sessionState setting cookieless="false" in addition to mode="StateServer".
In addition you need a fixed machine key, so a recycle won't generate a new machine key but uses the same key. If a new key is generated all previous sessionIds can't be decrypted, so the link to the sessionState is lost.
Check https://technet.microsoft.com/en-us/library/cc755177(WS.10).aspx for how to configure/generate a machine key.
This is an example from msdn, so don't use this in production, but generate your own key:
<machineKey
validationKey="32E35872597989D14CC1D5D9F5B1E94238D0EE32CF10AA2D2059533DF6035F4F"
decryptionKey="B179091DBB2389B996A526DE8BCD7ACFDBCAB04EF1D085481C61496F693DF5F4"
/>
In the end you need something like this in your Web.config or your Machine.config if you want to set the same key on machine level.
I am getting this error, and I know what causes it. There are many causes, but in my case, the issue is that the machinekey differs from server to server (in the web farm) and therefore when it jumpes from machine to machine, it can't decrypt viewstate and/or cookies . I've since fixed this issue, however, there are some users still left with a cookie on their machine, written with the old machinekey, and they are getting this error. I need a good way to handle this error, log them out and then redirect back to the login page. I've tried putting an exception handler in global.asax in Application_error, but this doesn't seem to fire for this error. There are other errors that happen, and I've filtered to catch only this error (by looking at the exception). I have customErrors 'on' in the web.config. How do I do this?
There are a few ways to resolve this issue. The best overall solution is to set the encryption and decryption keys explicitly in the machine.config of each server:
<machineKey validationKey="JFDSGOIEURTJKTREKOIRUWTKLRJTKUROIUFLKSIOSUGOIFDS..." decriptionKey="KAJDFOIAUOILKER534095U43098435H43OI5098479854" validation="SHA1" />
Another option is to disable encryption of the ViewState altogether, but you will lose some security benefits by doing this:
<pages viewStateEncryptionMode="Never" />
Lastly, you can disable the validation:
<pages enableViewStateMac="false" ... />
I set sessiontimeout in web.config file like following.
<sessionState timeout="120"
cookieless="false"
mode="InProc"
/>
Some times above code working fine.But many times session expired after 10 to 15 minutes automatically.
and this errors exists in every browser.
when i run same application using .net on my local computer it working fine.
Please note that, i haven't create global.ascx file yet.
Sessions will also be reset when the application recycles. This will happen when you change some things in the site, like change anything in the "bin" folder or modify the "web.config" file.
Also IIS may stop or recycle applications that it thinks are not used at the moment.
Are you sure you want to keep everything in memory for two hours, even after the user left? Better ways to keep the session alive would be to use some regular (every few minutes) AJAX callback. Search for "session keep alive asp.net ajax".
Have you verified the session timeout the app is ending up with? Do a response.write of Session.Timeout. This value can be set in several places.
How do you know the user is being active? The session will time out if he's only typing text, scrolling, and/or reading for lengths of time greater than the timeout value. The browser must invoke a HTTP request to the server to reset the timer.
As Hans mentioned, a background script-based "pinger" set to run at interval to access minimal web content will help.
Considering I'm about to start yet another web application, and I seem to need to add this functionality to most web apps, I was inspired to create a little package called Keep Me Alive to speed this process up in the future. You can find it here:
http://kma.codeplex.com/
Hope it helps!