Ajax and Javascript client side timer

[G_Waddell]

Hi All,

I have to deliver a secure web ASP.net site that after 20 minutes of inactivity wipes the users sessions and forces then to login again. I have set up all the necessary timeouts on the server and at the top of each of my master pages I have placed the following javascript:

setTimeout('top.location = "login.aspx"', 1200500)

The idea being that once the server has expired the session at 20mins of inactivity the browser will load in the login page. This works great until I use AJAX on my pages I suspect that as the page is only doing a partial reload, the timer keeps running as it were.

My questions are:

1. Am I correct?
2. Is there a way to reset the Client side timer through AJAX?

Any help much appreciated.

[Airshow]

GW,

I don't know much about ASP.net but I'm pretty sure that forcing the login page to be displayed will not in itself cause a session to be terminated. Unless the login page's ASP script included a deliberate session-killer, the user could simply press the browser's back button and carry on. Besides, you would give yourself a headache resetting the timer at each user interaction.

As with other server-side environments, I think you need to control session timeouts server-side not client-side. This article discusses the options:

http://justgeeks.blogspot.com/2008/07/aspnet-session-timeouts.html

And I'm sure much more advice is available on the web.

With a server-side approach, requests that naturally arise during a session will (subject to server-side settings) keep a session alive.

It's hard to think of an example but in web applications that give rise to only infrequent requests, and for which a session timeout is considered necessary, Javascript might be employed to make "keep-alive" requests. It is thus more realistic for a client-side script to keep a session alive than to kill it.

Airshow

[G_Waddell]

GW,

I don't know much about ASP.net but I'm pretty sure that forcing the login page to be displayed will not in itself cause a session to be terminated. Unless the login page's ASP script included a deliberate session-killer, the user could simply press the browser's back button and carry on. Besides, you would give yourself a headache resetting the timer at each user interaction.

As with other server-side environments, I think you need to control session timeouts server-side not client-side. This article discusses the options:

http://justgeeks.blogspot.com/2008/07/aspnet-session-timeouts.html

And I'm sure much more advice is available on the web.

With a server-side approach, requests that naturally arise during a session will (subject to server-side settings) keep a session alive.

It's hard to think of an example but in web applications that give rise to only infrequent requests, and for which a session timeout is considered necessary, Javascript might be employed to make "keep-alive" requests. It is thus more realistic for a client-side script to keep a session alive than to kill it.

Airshow

Sorry, you are misunderstanding my issue.

I have the server settings resetting sessions after 20 minutes of inactivity, the Javascript clientside code redirects the page to the login after 20 mins and 500 milliseconds so the session has already been killed off at that point. If they try and hit the back button, the page will not find the session variable that says they've logged in and will redirect to the login page. The idea being if they get up from their comnputer or leave a browser window open, after the 20 minutes (and 500 milliseconds,) the page is back at the login.

But none of this is my issue, the problem I am having is that on pages where I have used AJAX, the client side script is behaving erratically i.e. not redirecting after 20 mins 500 milliseconds but at random times.

[Airshow]

GW,

Yes, I misunderstood.

OK, you need to ensure that your client-side timer models the server-side timer as accurately as possible.

The session is more than likely kept alive by just two things:

• page refreshes
• ajax requests

Javascript will be something like this:

//keep variables together in an object (global, or preferably in an onload or document.ready closure).
var sessionData = {
  timeout:null,
  t:20*60*1000
};

function sessionTimeoutModel(margin) {
  clearTimeout(sessionData.timeout);//kill previous timeout if it exists.
  session.timeout = setTimeout('top.location = "login.aspx"', sessionData.t + margin);//set new timeout.
}

Elsewhere in the javascript, ensure that sessionTimeoutModel is called as follows:

• page load: sessionTimeoutModel(0) (margin can be 0 because the client-side timer will already be late)
• ajax responses: sessionTimeoutModel(500) (just before each ajax request is made)

Slightly better (I think) would be to call sessionTimeoutModel when each ajax response is received (regardless of its status code) rather than before the request is issued. This way, no margin would be necessary as the client-side model would automatically be slightly late in both cases:

• page load: sessionTimeoutModel(0)
• ajax responses: sessionTimeoutModel(0)

Thought: Depending on the consequences of requesting a page after the session has actually died, you might even consider a negative margin. I guess that, in general, it's probably better for the client-side timeout to be conservative (ie. fire earlier than the server-side timeout).

Airshow

[Airshow]

Line 9 should read:

sessionData.timeout = setTimeout.....