We are trying to architect a generic way to detect session timeouts. Our solution must be authentication type indepenent and work with and without cookies. These requirements rule out just about all I have found as far as articles regarding detecting session timeouts.

I came up with this ideas this morning and would like your comments. Basically its the same technique as if there were a client cookie, but the "cookie" is moved to the server.

Here are my basic classes:

SessionItem
---SessionItemId : Guid
---UserId : string
---CreateDateTime : DateTime

===============================

sessionDispatch.Add(SessionItem item)
sessionDispatch.Clear()
sessionDispatch.IsSessionExpired(WebSessionInfo sessionInfo) : boolean

===============================

WebSessionInfo sub classes HttpSessionState and is a current class we have to encapsulate session information. WebSessionInfo knows what the current user's userId is...


The way it will work:
===============================
On Session_Start a SessionItem instance is created and added to a collection through the dispatch broker. The dispatch broker will live in a cache object.

On OnLoad of our base Web Form, the current session instance is run through the broker to see if it's expired. To do this, the base page will pass in sessionInfo which will include the userId and the dispatch will look to see if the sessionInfo.IsNewSession is true and if there is an instance in the dispatch collection for the current user. If this is true, then there is an expired session. Otherwise the instance for the current user is found, but the session is not marked as new so the session is good.

In order to keep the collection from growing out of control, the dispatch's clear method will examine the collection for instances that have a create date two hours (or whatever makes sense) past the session timeout limit minus "now". The clear method could be called during the Session_End method.

What problems/drawbacks do you see to this setup?

There are no reliable methods of detecting session timeouts, nor does there need to be. Solutions that depend on these types of events need to be looked at again. This application is no different. Given what you have described, I don't even see the point of your "dispatch broker". It's adding an additional layer onto what seems to be an otherwise simple process.

I am not able to trap Session_OnEnd event of global.asax when session goes out of scope. Anyone out there in the group was able to trap it?

Maybe our method (whch we used in classic asp) to check session availability could be of use here, also?

Thanks,

Derek:

> There are no reliable methods of detecting session timeouts, nor does there need to be.

If there is no need to detect a session timeout how does your application handle the persistence of state information?

The inherent problem is that I need a solution that is not dependent upon the common ways that people are checking the validity of session state. It needs to work for both win and forms authentication as well as not being dependent up on the use of cookies. If there is another method I am missing, please point me in the right direction.

I am just having a hard time buying that the application is flawed because I need to know if a user session is expired.

Help me out a bit by elaborating some more please.

Thanks,

Craig

> <i>I am not able to trap Session_OnEnd event of global.asax when session goes out of scope</li>

When you say you are not able to trap, do you mean the method does not fire, or there are resources you can not get to?

I set a break point in my method during testing and it hits the breakpoint every time.

"I am just having a hard time buying that the application is flawed because I need to know if a user session is expired."

Why -exactly- does the application need to know if a user session has timed-out? You've explained how you've attempted to handle it, but not why.

Derek:

This is for a framework solution that is used by many developers in many different applications with many different requirements. Some have shopping carts, others persist the security settings for menus etc., others have "current data" and settings that need to be passed around their applications, and the list goes on.

I am really trying to get where you are trying to take me, but session and its uses seem pretty well established. What else can I provide to explain the "why"?

Thanks for the help,

Craig

Session state is an established concept, yes, but detecting the expiration of sessions is not. None of the examples you have listed (shopping carts, security or various other forms of data) require or even benefit from such functionality. If the session ends it is eventually recycled by the server.

The most common reasons for sessions recycling is the browser being closed or the user navigating to a page or file on another Web site. I'm sure you know this, and am not suggesting that you do not. However, it's worth noting that if the user is no longer using your application, there is no need for additional processing to occur (in the vast majority of cases).

If your application(s) require things like "Products you saw the last time you were here" (in reference to a shopping cart) you'll want to look at a timestamp-based solution, in which simple comparison logic can be used. This is one of the more common reasons for people stating that they "need" to detect session expirations, when in fact they do not.

Authorization simply shouldn't be implemented in session state (your second example). Authorization data isn't user data and shouldn't be kept as such. Authorization doesn't exist for -a- user; it exists to protect every other user, and as such should be treated as application data, not user data.

Other forms of data (your third example) should be kept in the application's data store (usually a database) if these pieces of data are in fact important at all. This is a common place for session misallocation. I've seen developers stick the weirdest things in session state: browser data (context), the current time (context), connection strings (application data), form data (page data), DataSets (page data), etc. Again, the data itself doesn't need to be changed simply because the user's session expires.

However, if you're still dead set on supporting session expiration, a crude combination of the System.Web.SessionState.SessionModule.End event and some "onunload" JavaScript which invokes a Web request back to the server will work most of the time. Just remember that the Web is inherently stateless. Trying to trick things with cheap hacks is never the best approach.

Derek:

Okay, if I understand your post correctly, I think I may have not described fully what I am trying to do. I do not want to alter data after a session is expired, but rather stop the user from proceeding (and therefore affecting data erroneously) throughout the application.

Here is a more concrete example. Perhaps this will illustrate our need a little better.

One of our applications is an order system for a T-shirt manufacturing company. The user chooses an account and then navigates through the site editing screens linked to that account. The link is established by the account Id being tucked into session when they choose the account on the selection screen. When the user's session expires, we do not want the user to be able to save data off to the database with an incorrect account id.

Now we could add hooks in each screen so that if the account id equals zero then we can assume the session is expired and redirect them back to the account selection page. While this seems nice here, adding these hooks all over the place seem like a maintenance nightmare. Why not just check for a session expiration right off the bat?

What do you think? How would you handle this scenario?

::Why not just check for a session expiration right off the bat?

in a web app, you'd do that with a base class.

create a class that inherits from system.web.ui.page
have all web pages inherit that class instead if system.web.ui.page

override the pageload event in your new base class and check your session state. if the user is not valid, redirect to a login screen

mbanavige:

> override the pageload event in your new base class and check your session state. if the user is not valid, redirect to a login screen

This is exactly what I plan to do. The "what to check" is just what's in question.

Why couldn't this check be done in Application_BeginRequest?

I dont do it there because some of my pages are secure, and some are not.

in a pages public sub new, i can alter the security behavior of the base class...on a per page basis.


As for the "what to check" question, if you need a cookieless session then use the built in session object but set it to be cookieless in your web.config.

I also perform these checks in the page load event. I find it slightly more flexible than HttpApplication.BeginRequest, as you can customize certain responses based on the current page and which controls are set to visible. If you don't require such granular checks, HttpApplication.BeginRequest may be the better choice.