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: http://www.codinghorror.com/blog/2008/04/your-session-has-timed-out.html
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2008/04/your-session-has-timed-out.html
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?
@Tarkin
"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 digg.com and del.icio.us 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 $$. Amazon.com 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!
Marcus,
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.
@HardCode
"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.
@HardCode
"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:
session-descriptor
session-param
param-namePersistentStoreType/param-name
param-valuereplicated_if_clustered/param-value
/session-param
session-param
param-nameTimeoutSecs/param-name
param-value1800/param-value
/session-param
/session-descriptor
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 
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. 