Session Timeout behavior isn't quite as described

Answered
0
1

In my main page, I am hooking Application.SessionTimeout when my app is in the logged-out state, and unhooking that handler when my app is in the logged in state.  My handler just sets e.Handled = true to suppress the timeout when not logged in.

The timeout does work, but the timing does not very closely match what the documentation says.

  • If I set the timeout (in default.json) to 60 seconds, the SessionTimeoutForm pops up after about 90-100 seconds of inactivity.
  • If I set it to 90 seconds, the dialog pops up in about 200 seconds.
  • If I set to to 120 seconds, the dialog pops up in about 270 seconds.
  • In each case, when the dialog appears, the countdown timer displays the configured timeout value (60, 90, 120, etc.), counts down from that value and the session does indeed expire after the configured number of seconds – it’s only the time before the dialog appears that’s variable.
  • I’ve verified that my handled is never called while in the logged in state (as expected – so it’s not my handler that’s postponing the timeout).

So, what’s going on with that period before Application.SessionTimeout is raised?

 

General
Share
  • You must to post comments
Filter
Sort by: Recently Active
Good Answer
0
0

The session timeout is fired from the browser when the user is inactive after the number of seconds set in the sessionTimeout settings. However, to avoid starting and removing a javascript timer every single time the mouse moves or stops moving or a key on the keyboard is pressed Wisej sets a flag “skipNextTimeout” which skips the next timeout. So when the timeout is 60 seconds at the most it fires after 120 and at the minimum after 60.

  • Carl Daniel
    That makes sense, but it doesn’t seem to match what I’ve observed: setting the timeout to 120, I didn’t see the dialog pop up until very nearly 4 minutes. During the wait interval I move my mouse completely away from the remote desktop session in which I’m working and touch neither the mouse nor the keyboard until I get the pop-up. I’m going to do more testing with longer intervals – basically, I’m fine with -0/+60 second uncertainty, but with the intervals I’ve tried it seems the longer the timeout the larger the uncertainty.
  • Carl Daniel
    Doing more experiments, it looks like the uncertainty is indeed proportional to the timeout value, which is undesirable. Related question: I’ve had reports from users (and I’ve seen it myself) where the browser is inside a remote desktop session, and the timeout appears to be much longer, as if time is not passing inside the remote desktop. For example, a system configured with a 20 minute timeout – the user logs in, then detaches from the remote desktop. When they reconnect hours later, the session has not yet timed out. Does it make sense that the browser would somehow be “aware” of the disconnected RDP session? What if the RDP window is minimized? Covered up by another window? I would assume that the browser would be unaware of any of these things…
  • Luca (ITG)
    The browser may suspend JavaScript, which is outside of our control. You can change the built-in timeout form with a custom one. There is only 1 skip next session timeout as designed. The js code is public on GitHub. You may be observing the browser freezing javascript timers. Which is the only type of timer available,
  • You must to post comments
Showing 1 result
Your Answer

Please first to submit.