Introduction to the Defibrillator
Sometimes you want to keep a session alive only as long as the user is on the site, or until they close their browser. You don't have security requirements in this situation that would make this a bad idea. You just want to keep the session timeout down, but let it persist as long as people are on your site (not just posting back to the server). I'm not kidding you when I tell you that I have figured out a way to do this with two lines of code.
Coming from a biomedical engineering background, I simply had to call this construct The Defibrillator :-) You'll soon see why.
Nuts and Bolts
The most elegant engineering solutions are the simplest ones. You break down a problem into its finest components, and then focus on applying your vast knowledge to each component in order to produce a unified solution.
There are only four concepts to this solution:
- Knowledge of the Response.
- Knowledge of the
Refresh HTTP header attribute.
- Session property access.
- Plain old IFrame.
You will create a dummy WebForm called Defibrillator.aspx. You do nothing with this page other than add one line on the Page_Load in the code behind file:
private void Page_Load(object sender, System.EventArgs e)
{
Response.AddHeader("Refresh", Convert.ToString((Session.Timeout*60)-10));
}
You just added the Refresh HTTP Header Attribute to the WebForm and gave it a value of your session timeout minus ten seconds. What does that mean? It means that ten seconds before the user's session is going to timeout, as long as they have a browser open, and they are on your page, this defibrillator page will deliver massive amounts of electrical current to your server, jolting the user's session back from the brink of death...which can also be described as automatically posting back to keep the session alive :-).
Great, you say...I don't want my site to post back visibly just to keep the session alive. You don't have to. This is where the second line of code comes in.
Go into your user control that is site persistent, such as the header, or footer user control. Now add this line of code into the front end WebForm markup language:
<IFRAME id=Defib src="/Defibrillator.aspx"
frameBorder=no width=0 height=0 runat="server"></IFRAME>
Now this invisible Defibrillator WebForm will just sit in the IFrame and post itself back to the server 10 seconds before the session times out, only if they are still on your site or a browser is open. Check out a View Source, you won't even see the Refresh attribute because it's hanging out in the invisible IFrame.
Please use this clever little trick with discretion and an understanding of your blade resources, or else I will have an army of network administrators ready to storm my fort :-)
Caveats
- Browser Compatibility
It will work in any browser that interprets the Refresh HTTP header. In Netscape it has the effect of hitting 'Reload' at the specified time. I have read online that this refresh will exclude your page from search engine crawling... which is fine since you put this functional tag on a dummy page in an IFrame, that you don't want anyone browsing to anyway.
- Out of our control: precision of ASP.NET timeout on server.
I've found that the session timeout itself in ASP.NET is not entirely accurate, especially when you are in a debug process. While I haven't had the Defibrillator fail for Session.Timeout - 10 seconds, I tested for 2 days with Session.Timeout - 5 seconds and it failed at around 36.5 hours of inactivity, because the ASP.NET session timed out before it was supposed to on the server. You may want to keep this in mind and perform your own little test. You could even fire up different browsers and let them rip, logging a time of failure and the browser type from the Request in your DB. So far so good on my app, no problems with the way I presented the solution here on Netscape or IE 6. (RE: Joe).
Extension
Write a combination of code in the defibrillator that works on a JavaScript timer, prompting the user to refresh session, and replace the Refresh HTTP header attribute with this construct. Since it is site persistent, put as much JavaScript into your .js files as possible. (RE: Fredrik)
