Your Session Has Timed Out

I think the worst case I’ve run into is for a university- which politely asks if you’d like to continue your session, you click OK, but then subsequently kicks you anyways! :frowning:

Something like that in place is fine by me- if it works… maybe even a private pin to get you back to your previous state.

Another idea: do expire the cookie after 10-15min of inactivity, but keep state persisted for a day or so, unless the user has explicitly logged out. You might get a session timeout, but at least you’d be back to where you left, after you logged in again.

I use a heartbeat via Ajax (or more properly, via XMLHttpRequest) to keep web app sessions alive. I set the interval to be just a little less than the session timeout to keep traffic to a minimum. The session stays active as long as the user keeps the browser window open but as soon as they close it, the heartbeat stops and the session timer starts running. Works quite well.

Actually, I’ve been timed out of gmail, though I haven’t seen the message. It just seems like new messages aren’t coming in, and then when I click the inbox, it sends me back to the login page.

Maybe it’s just some other bug though.

I agree though, it’s very annoying.

f0dder’s idea is what I usually stick to. I still find it necessary to log the user out of the application due to sensitive data, but they should be able to go back to where they were.

f0dder – that doesn’t help in the (extremely) common case of filling out a web form, walking away for an hour, filling out some more of the web form, and pressing “submit”. All your data entry will be lost when you get redirected to the login.

For some reason, this tends to piss users off…

I’d rather use AJAX to persist form state to the DB, instead of hacking session timeout with a heartbeat … more work, sure, but it doesn’t circumvent the benefits of timeouts, either.

As, I see, f0dder also prefers.

A number of people have asked what kind of form could be so onerous that it requires a long session time. How about an ASP.NET web form with an upload component, which uploads the damn file into client-side memory even before you call the SaveFile() method to stream it to the server? Even a small file that loads relatively quickly could result in a session timeout.

Now take that same form and deploy it for users in the developing world, where hardware is often older and connection speeds aren’t always exactly blazing…

Keeping track of millions of session-id’s?

Where is the problem, dudes? Binary search will do it! Scales incredibly well.

Keep the records that have been active over the last days in memory as a cache and put the older one into a database or whatnot.

Easy as that.

When you suggest using an HTTPS protected connection to prevent session hijacking, are referring to just the cookie, or the whole page? If the whole page then I think an Javascript Heartbeat script hitting the server via HTTPS would be a better option for performance. I would need to test because I’m not sure if you can keep a HTTP session alive with a HTTPS cookie.

I’ve always thought that one of the features of session timeouts is exactly that: if the user leaves his PC unattended by walking away, his session should expire so any evil doers that approach the PC while the user is away cannot do much.

Of course this is somewhat spoiled by the fact that by now every browser on earth stores passwords, but a security conscious user will hopefully decline that.

How are timeouts a benefit to the end user? In what scenario is it beneficial to me to be automatically logged out of GMail after 10 minutes of inactivity?

Imagine if Microsoft Word or Excel “logged me out” if I was idle too long in a document.

Isn’t “you’ve been idle too long, lock the workstation” the job of the operating system and not the job of every little application that I run to implement in their own peculiar oddball way?

I agree, session timeouts are unpleasant. But if you’re somewhat critical programming web applications (for example a homebanking solution), not only session hijacking is a problem.

What about a user, who (accidentially or not) forgot to log out and leaves the application open? The next person who passes by the PC with the open session can do anything with it - that has to be prevented, too. Yes, it’s the fault of the user (why hasn’t he logged off?), but from a programmers perspective I have to make sure that my application can’t be compromised in every way I can imagine - and that sometimes means I have to protect the user from himself. Until now I haven’t seen better solutions for that kind of scenario than session timeouts.

It all depends of course on the type of application you do, as you’ve made your point with the comparism to “building the space shuttle”!

How would you handle public computers then? If your session lasts forever and you leave a public computer logged in, the next user can access your data.

In that case the timeout is there to prevent other people taking over your stuff if you forget to log out, which isn’t uncommon either. And people who use public computers rather than have their own are more likely to not be fully computer literate and realise that other people can access their session afterwards.

The argument I’ve always given for being logged out of stuff like bank account sites, credit card sites and corparate windows machines is: ‘What if the user walks away from their computer?’. The idea is that you are risking someone performing the most basic of session hijacking tricks (i.e. sitting down at your computer and starting to use it). This is a pretty important security hole to consider for these applications - especially considering that many will be used from insecure internet connections (internet cafes, etc). Obviously, its much less important for less valuable data, like for example Facebook. But when was the last time you even had to log in to Facebook, let alone have your session expire?

My view: If you have something that is worth protecting (money, corparate secrets, etc) then you need the draconian session expiration. Otherwise, don’t just scrap the session, you shouldn’t ever have to even log in at all!

Keeping logged in is fine as long as it’s an option, i.e. I can turn it off (either by closing the window or not selecting some “keep me logged in” checkbox) - simply to enable accessing the Web app at a public place, or using a friend’s computer, etc.

Even better, though, is to not use session state and cookies, and simply go with HTTP authentication instead.

The biggest problem of an expired sessions is that all data in the forms is lost. Often you get redirected to a login page after your session has expired, so that you have no change to copy-and-past your input to a text editor (or something similar).
The web application should save the current data in the background (this also can be used to send a heartbeat to the server). So when your Internet connection is closed and you get log out (after a certain amount of time), at least your most recent data is saved.

I agree with you: Session-timeouts are really annoying and avoidable for most of the applications out there. But in very-high-security apps I think security worries outweigh the disadvantages. I dont want my online banking account being logged in for hours because I had to leave all of a sudden. In the meantime all kinds of malware could take control over my account. In this case I think I would prefer f0dders way of handling the problem.

@Martin Probst: That’s what “Lock Workstation” is for. Leaving a computer unattended so that any yokel can walk up and do things with it (or even just look at what you’re doing) is a major issue in itself. “Cannot do much”? What about browser history and auto-filled in password fields?

There’s little point for the browser to single this situation out. The computer auto-locking after X minutes would make a lot more sense than all your browser sessions expiring after X minutes.

Session timeouts prevent remote hijacking; they’re not much use for preventing local takeovers.