Http session issue

Question

Hello everyone,

I met with strange session issue. I have developed a web site which uses session to track user specific information to determine whether a specific user has permission to access some part of the web site. I am using VSTS 2008 + .Net 3.5 + C# to develop ASP.Net web site.

In my design, when I access http://mysite/sitemanager, if no session ID is available, users will be asked to input their user name and password (if passed password checking, available session ID will be granted); if session ID is available, it means user has site management permission and authenticated, then all the functions from site manager should be accessible by the user -- i.e. all login user has permission to access site manager.

The trouble scenario is like this, (1) I access http://mysite/sitemanager from a new IE window, since I have not login before, and I will login using my credential and granted site management permission, (2) then I (not closing IE) enter http://www.google.com into the address bar of the same IE window to replace http://mysite/sitemanager, Google apprears, (3) then I paste address http://mysite/sitemanager into the same IE window to access, I am surprised I am not asking for permission to input password.

Any ideas what is wrong? What I want is in step (3) user should be asked to input password.

thanks in advance, George

Answer 1

Your session has not ended simply because you left the site. A session remains active for it's timeout period since the last interaction with the site. That's why the session information still exists.

To answer your comment, you can end a session by calling Session.Abandon(). If you want to do it when someone leaves the site, I suggest you do an ajax call on the unload client event of the page that will in turn call Session.Abandon() or at least reset the credentials. However, that may be tricky as the unload will be called even if you leave the page for another page in the your own site, so you have to check for that as well. And yes, it is by design. The default session timeout is 20 minutes unless you specify otherwise.

Answer 2

Session state will only be lost if the user deletes the session cookie that your server has given to him/her. Or the user does not make a request for a specific (Session.TimeOut property) period. Or if you abandon it in your code.

Answer 3

This is the way web-sessions work everywhere. To avoid surprising users; you're probably best off just accepting this behavior.

---

But if you really want your users to log off when they stop using your site, here's how...

Rather than using the unload event (which is going be be problematic to implement because it's difficult to tell when someone is really leaving your site - and what happens if they have two windows to your site open?), I'd suggest shortening the session timeout to 1min, and using a client-side keepalive: essentially the browser pings the server every few seconds (say, 10) at a predetermined url, which does absolutely nothing beyond keep the session alive.

This can be implemented entirely without javascript if need be, via an iframe to a page with a meta-refresh tag. It'd be more robust and simpler in javascript, of course, but a hidden iframe isn't too complex, nor is a meta tag. If the server side refreshing page supports sending 304 Not-modified, you'll have a very low overhead solution too.

In your main file you'd always include something like:

<iframe src="keepalive.aspx" width="1" height="1" />
<!--and perhaps use css to hide the iframe - but test that!-->

And in keepalive.aspx you'd include:

<meta http-equiv="refresh" content="5" />

Finally, as a bandwidth optimization, in the code for keepalive.aspx, you could add a Last-Modified response header, and check whether the browser sent an If-Not-Modified-Since request header, and if it has, send a 304 Not-Modified instead of the full document.

Finally, if you're javascript dependant anyhow (many such log-in based web-apps are), you could instead simply use your favorite ajax framwork to periodically perform a request as well - without requiring the iframe.