Your Session Has Timed Out

How many times have you returned to your web browser to be greeted by this unpleasant little notification:

This is a companion discussion topic for the original blog entry at:

Jeff, I can see you are working on stackoverflow based on the topic. Are you going to avoid using username/password combos and just use passwords as you’ve alluded to in the past?

"Go to any local midrange restaurant. Order a beverage, and look at the menu. See if the waitress will wait an hour for you to complete your order."

Uh, yes, that’s exactly what restaurants do. You get your drinks, when you’re ready for more drinks or finally ready to start eating you can signal or wait for the next time she shows up to order. I’ve had 4-hour lunches that went just like this, even in cheap places. That analogy is unbelievably stupid and irrelevant, but the fact that it’s so wrong is just hilarious. (Mapping food service onto the internet, are you insane? Do we tip our web servers and get half price goods on sundays?)

You just had better have a fat tip ready for staying around so long.

Personally, I like timeouts. Get off my server if you’re not using it, you slob.

As I see it, this post and most of the discussion misses the point.

Sessions are used legitimately for user authentication on the web. Some sort of timeout for authentication also makes sense for security reasons – however, many community internet applications provide a way that people can be logged in permanently… Services like and wouldn’t be so much fun if you had to log in all the time.

The most sophisticated web sites have a split model for authentication. Amazon has permanent authentication for low security sections (seeing personalized results) but requires you to authenticate (and create a new session) if you do anything that’s sensitive.

Most often, web programmers use sessions out of ignorance and laziness. One culprit is the stream of Win32 and Unix programmers who were tasked with moving existing applications to the web.

Most of the world’s research libraries, for instance, use a software package called Voyager for their online catalogs. Voyager was originally a terminal application, which created a new process each time a user logged in. They kept this model when it changed to a web application: each user got a session id and a process id – the web process reconnected to a long-running process each time a page was rendered.

Voyager has all sorts of problems, but the worst is that users get their sessions expired when they walk away from the browser in ten minutes. Patrons hated it, but Librarians thought it would be too expensive and complicated to build a catalog that “works more like Google”. Funny, I built a search application for a bibliographic database almost as big as theirs in a weekend, and it was about as fast on a four-year old PC with Linux, mysql and Perl as Voyager was on a eight-way Sun server with an expensive disk pack…

It looks like many libraries are going to outsource their catalogs to Google or OCLC since they can’t manage to deal with software developers without getting rooked.

Another suspect is languages that provide an easy to use Session facility. Cold Fusion and ASP are particular offenders; somehow PHP users never got that big into session variables. Session variables are fine for authentication for personalization, but they’ve got (almost) no place in CRUD apps – at least if you want them to work reliably. Programmers shouldn’t use session variables until they’ve had a few years developing apps without them.

The problem is that web apps store state in multiple places: some state is in the web browser and some state is on the server. If you’ve got some state on the server and some state on the client, the app gets wrecked when people use the back button. There are a few patterns were session variables can prevent problems rather than causing them, but they don’t seem to be widely known.

Keeping short-term application state in form variables and passing it back and forth like a football is the most effective, simple and reliable answer to the problems of multipart forms.

Finally, many companies have been rooked by vendors that make CMS products and application frameworks that are entirely dependent on sessions. This is good for keeping your site from being indexed by Google… And that’s about it.

Totally agree. One very simple thing I sometimes used to do was to use SSL together with basic auth and use the user name as the key to the data. The login “screen” looks nasty but at least, the credentials travel (encoded thanks to SSL) with each request. It doesn’t prevent you from caching the user data but in case that cache entry expires, it is super-easy to recreate. Session never expires this way.
If you don’t authenticate your users, one question to ask is is there anything to protect? Should you use session at all? Can you use a longer-lived cookie and use that as your user data key?

I don’t think the “user leaves/shares the workstation” scenario is something one could prevent with expiring sessions.

If the user leaves the workstation with the browser left open, he made a bad mistake, which can get him into trouble, even if there is a reasonable short session timeout. It doesnt matter that much if the malicious guy needs hurry a little (at 5 minutes) or has any time he wants: He can screw the user. So no argument for a short timeout here.

If the user closes his browser, the client’s side of the session is terminated, if “session cookies” (those which have no “expire”) were used, and no harm can be done anymore by stealing sessions. No argument for a short session timeout here either.

And, besides this, i think the real problem here is, that there are forms which are that huge and painfull to fill that the user takes more than 5 Minutes.
What are they for, doing the tax declaration?

Of course, it depends what the session time outs are designed to protect against. Absoultely NONE of your recommendations deal with one situation - somebody ELSE wandering up to the computer when you’ve popped off for a cup of coffee and transferring your entire net worth to nigeria.

The original AJAX application, Outlook Web Access, has quite a neat solution. If your session times out, when you try to do something, the login screen reappears, either in the window you were accessing in, or in a pop-up if appearing in that would cause loss of information.

Result is sessions time-out, your protected against someone sitting down at your desk if you’ve wandered away for five minutes, but nothing is lost if you do come back to your half-written email after an hour. (And, yes, that’s exactly how it benefits you, the user, to be logged out after ten minutes of inactivity - somebody else in the cybercafe doesn’t start reading all your email after the mass evacuation due to the fire alarm!)

Jeff, big fan, but you’ve really lost the plot. This is done for security purposes. Non-one wants someone else reading their email or bank statement when they’ve left their PC unattended.

Wrong answer Keppla.

In the real world, the phone rings. In the real world, people need to juggle multiple tasks. Filling out a form might require half an hour of research to dig up something they don’t have on their fingertips.

One of the worst places where people use the server language’s session mechanism is for web shopping carts. Many mom and pop online stores do this, and they throw away more than half of their potential sales because session timeouts cause people’s shopping carts to get dumped.

Because these systems typically don’t have good logging, these businesses aren’t even aware that they’re burning $$. keeps your shopping cart for weeks… Not for high principles, but for customer satisfaction and profit.

You might not like it, but many people keep their computers running all the time. If they have a Microsoft Office document open, they can come back to it a week after they started working on it. People expect the same thing from web applications – if you’re going to give them sanctimonious bulls**t about how they can’t do it, you’re an enemy of usability.

We looked into this issue for the case of a large electronic publishing site. We found people were complaining about timeouts on a form even if the timeouts were 24 hours (they expected to be able to walk away from the computer and come back the next day, even over the weekend) Funny enough, we still got complaints about a one week timeout!


that's bull.  If you're worried about somebody messing with your computer when you're not there LOCK YOUR DESKTOP.  

Outlook and Firefox don't "time out".  Microsoft Word doesn't "time out".  Photoshop doesn't "time out".  Amazon doesn't "time out".  Google doesn't "Time out"

Web applications "time out" because people build applications based on bad practices and bad architectures.  Web applications "time out" because lazy and ignorant developers put their own convenience and bad ideas ahead of the needs and concern of your computers.  They should stop drinking the Kool Aid from vendors and learn the practices that work.

"1. Performance. Consider a highly trafficked web site. "

I think it’s more to do with scale than performance; either way it’s a legitimate concern.

“2. Security.”

Legitimate concern.

"1. Create a background JavaScript process in the browser that sends regular heartbeats to the server. "

That keeps me logged in - see below.

“2. If you’re worried about session hijacking – and you really should be – use a HTTPS protected connection. This is an absolute no-brainer for financial institutions of any kind.”

I disagree it’s a no brainer. You want clients to have certs as well; most don’t.

So, interesting post, but you haven’t factored in an important issue - people don’t always log out of web apps. Think of it this way - imagine a site that has login, but no logout, as operationally that’s how they tend to function. Does your argument still hold? I’m not sure it does as it’s based on the assumption you want to keep people logged in rather than logged out. I think the sensible model tends to be managing security on a per resource/action basis and not as a global setting.

That’s the why of browser session timeouts from the programmer’s perspective. But that doesn’t make it right. Far from it.

@Paule Houle
i never said that timeouts are a good idea, in fact, i said they arent neccesarry.

And while i am surprised by the 24-hour-complaints, i still stand by my statement, that complicated forms are a problem.
I, as a user, am seriously annoyed every time a stupid shop makes a 5-Page form out of “…and now, send the stuff in the cart to this adress”. Some of them even include mandatory surveys.
I would guess, that there’s a huge amount of users, who never return, because the remember the shopping as too complicated.

"The age old rebuttal, “What if the user walks away from his PC?” is so tired and so nonsensical. It would only make sense the day every malicious person waits the allotted 20 or 30 minutes before sitting at the PC of the person who walked away."
Most bank services deal in less time than that. Also, the chances of a malicious person getting to your computer within 20-30 mins is much lower than the chance someone malicious will pass it in the next hour.

"The issue can only be solved by end user discipline."
Aka "It is insoluble"
So you wash your hands of it, and if someone gets robbed, “It’s not my problem, it’s your fault.” Conscientious.

"No 20 or 30 minute timeout or 15 minute workstation lock is going to prevent someone from sitting at the chair as soon as the legitimate user is down the hall, or out the door, or out of sight."
But it will stop someone from coming in 20 minutes later and doing the exact same thing.
The chances that there’s a malicious user over your shoulder are small. The chances that one will use a public computer over the course of 2 hours is much much bigger.

@Paul Houle
"Outlook and Firefox don’t “time out”. Microsoft Word doesn’t “time out”. Photoshop doesn’t “time out”. Amazon doesn’t “time out”. Google doesn’t “Time out”"
Does Google do something I’m not aware of with those tabs? A Financial Manager tab or soomething?

The only one of these that can do even a fraction of the damage that access to banking software can is Amazon, and they have a returns/cancellation policy. Also, they have the address where the ordered items were sent to, so they can easily track the actual items. All the bank will have is a record that the money was transferred into another account, which was then closed.

For anything other than actual financial services the value of this level of security is highly dubious. The worst offenders seem to be web-based stores. Some are so bad, Verizon is a good example, that they will timeout and kick you back to the front page even when you’re just browsing. Much more common is for stores to empty out your shopping cart with some ridiculously short timeout. Sometimes I like to take my time shopping, deciding which things I actually want, and sometimes I’ll get pulled away in the middle of something, it’s annoying to come back and have to start from scratch again.

I wonder how many developers actually control the session timeout. I’m the application developer for a few commerce related web sites for my employer. There’s no code in my application to time out sessions, which run on BEA Weblogic application servers.

However, the application configuration defines the timeout. The parameter was selected based on discussions with our IT security dept., the internal business unit for which the site was developed, our server admins, and myself. The selection was based on a combination of security issues (both financial and privacy related data) as well as server resources:


Note there is a difference between session id cookies and authorization cookies (at least for ASP.NET, but it’s rubbish by all accounts, so I’m sure it’s the same or better in php and ruby land)

That said, I’d say 1/2 of session timeouts are the result of poor/naive programming, and the other 1/2 is poor stakeholder decisions. Mostly the stakeholders are myopic and think their data is all important, but in reality nobody cares.

Fine … my online Bank times out, and I think there’s a good reason for that. It’s about the only thing I can think of mind you.

For the rest of you, don’t rely on sessions. They’re evil. Sure shove a little cached state in there that you don’t care about, and regenerate sessions on the fly. Then you can aggressively reclaim idle sessions and can still use load balancing. But don’t rely on sessions for anything, ever.

For all you session time-out’ers, there’s an easier solution. Identify critical actions and have users re-enter their password to proceed. Simple, and if you look closely, most of the big sites where the extra security matters do so.

Think of it the other way. Isn’t it flawed to assume that just because clicks keep coming in, that it’s still the same person? Also, as others point out, just because you didn’t click doesn’t mean you’ve left.

I’ve read a lot of the comments, and most are rubbish excuses. Web Browsers are not ATM’s. Web browsers are not running cars. Web browsers are not waitresses. It’s like using a hacksaw to remove a splinter in your finger. If you truly need security that badly, you shouldn’t be using the web and relying on session timeouts.

I think the problem is not retyping you password, The problem for the user is Loosing-the-information-typed-in-the-form.

I normally choose the the following two-step session management

When the session times out (30 minutes), store the session info to disk (db) and keep it there for a ‘long time’ (Since my users mainly log in from internet-cafes, I choose 4 hours)

If they try to continue a session, (they make a new request / post new data)

If they try to continue a session after the re-auth timeout, but the session is still on disk:

If They choose to ‘be remembered’ - automatically restore there session and process the request / posted data.
If they choose not to be remembered - Store the request/data, reprompt them for their password (we know their username from the session data stored on disk)

  • If they supply the correct password - process the request / posted data.

If they try to continue a session that is no longer on disk:

If they choose to ‘be remembered’ - create a new session and Try to process the request / posted data.
If they choose to not to be remembered - ask for username and password

  • If they supply the correct username and password - Try to process the request / posted data.

just my 2 cents :slight_smile:

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.

Not necessarily. The browser did send the data in its POST-request, so it’s up to the server to be able to connect the received data with the user who just logged in again. Creating a temporary cookie before redirection occurs doesn’t look too hard to me.

And to take T.E.D.s example, something like that seems to work for some forums. Like him, I also tend to write a lot of stuff and rephrase it again and again, so the session expires, I get politely ask to submit my credentials again - et voil, my posting appears. No data lost.

So according to my experience, there must be a solution for the “get me back to where I was” problem already. It’s up to the stupid code-monkeys to implement it. :wink: