Your Session Has Timed Out

I really agree with the point you made here, it shouldn’t be the user’s job to worry about sessions.

It really cripples the user’s experience.

I think sessions should time out. People should get on the computer, do their business, then get off and go do something like play with their kids, interact with humans, plant flowers, etc.

Go rent “Farenheit 451”.

My solution was to stop putting so much stuff into Session and use the ASP.NET profile, which in turn uses a database store. Sessions still expire but most items can be retrieved quickly from database and the user can pick up where they left off.

You can always “ajax-ify” your login so that upon submitting a form it allows you to log in BEFORE submitting the form and therefore the hard work you put into the form isn’t lost…

Use HTTP authentication! That way you don’t even have a session to time out.

@Foxyshadis
"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."
With the expectation of that fat tip you mention. And even with that fat tip, if you’re not doing a decent amount of business, the staff and management will deeply resent your presence.

" 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."

Service is service. Speed of service is paramount. If you are idly wasting resources that could be better used servicing people who are able to be timely and punctual about their use of the resources, you are a drag on the system.

"(Mapping food service onto the internet, are you insane?"
My sanity has nothing to do with the issue. Service is service. I bet you, too, are one of ‘those people’ who take cellphone calls at the register, or purchase 20 items plus tobacco and alcohol at a self-checkout lane.

"You just had better have a fat tip ready for staying around so long."
Which I would map to the higher development and service cost of a website or web application which would have 4-hour session times and increased security awareness.

I think this is an indicator of the general “ME FIRST ONLY” type of thinking prevalent in today’s modern, on-demand culture. People often fail to realize their part in receiving speedy, efficient, and excellent service. That part is understanding that you are not the only person being served by the system. This is much more transparent in say, retail or foodservice (you know when you are the only person in the store/restaurant), but it applies online as well. The server(s) must deal with many users at a time, not just you and you only.

I’d like to see Jeff revisit this issue after six months or a year of running stackoverflow.com . I’m guessing his view will be a little different then ;^)

An ex-boss of mine told me about a credit union website, that when the page lost focus, would expire your session. I told him it was the stupidest thing I’d ever heard of.

If this is possible, I would suggest something that keeps the state of the page you are on but at the same time it has a pop-in? (pop-up but same exact window/tab) that requests you to login to continue so all of your data is still available when it disappears and logs you in, in the background.

There is one session timeout I absolutely loathe, netlibrary.com.
If you even access their site after a while it will have a popup requesting you to continue your session or it kills your session (this might only be from a network with a subscription, like a university or company)

One approach is of course not to persist anything in the session state and put all the state in hidden fields. That has the downside, though, that you cannot trust the client - anyone can modify any hidden fields before submitting back to the server. It also increases the size of both the response and the next request.

I’m surprised nobody’s mentioned the awesome Firefox extension “Reload every…”. It’s dead simple. Right-click on a page and pick from anywhere between 10 seconds and 15 minutes for the page to automatically refresh. It’s saved me from many a session timeout.

Cheers.

The webApp my group writes is for reporting on personal information. Stuff like income, Social security number, Address, Name, etc… And the contract specifies that we build in a time out for each session. And we are uber secure.

The applications run on a VPN, and cannot be accessed outside of the VPN. The user must exist and be able to login to the VPN to access anything. The user must login to our application to access anything. There is controlled access to the computers in people’s offices with a policy on the PC that if the PC is idle for 5 minutes it locks as well.

Part of the requirements was that after a set timeout, we not only expire the session, but automatically, change the page to a default login screen without any prompting to the user. So, you could technically be reading a report, not interacting with the computer, and get booted while you are sitting in front of the PC… crazy. And it was a pain to make all that work together.

But, our customers wanted it and they have never complained. I guess with all the identity theft going on, it’s a necessary evil.

Session timeouts were conceived of as a means of minimizing resource utilization on the web server. They were later latched on to as a cheap means of “security”. Be wary, though, since programmers who rely on session timeouts to provide security may have other low morals and offensive habits as well.

Security costs time and effort on the part of both the user and the programmer. Use HTTPS. Consider using HTTPS with mutual authentication. If you fear a session may have been hijacked during a period of inactivity then reauthenticate the user before allowing an action to take place. Consider authenticating on every action, if the need for security is sufficiently great.

Don’t just throw the user’s work away.

The easy solution, session timeout, is probably the wrong solution for most problems other than the one it was invented to deal with: server resource starvation.

Bret (Brett on April 16, 2008 06:24 AM ) RE: CSRF.

Thank you, thank you, thank you. CSRF is the number one reason why people should be logged out of sites, either via inactivity or after they’ve finished their activities on the site.

CSRF is a fundamental flaw in the way webapps work, and I really don’t see all that many sites protecting themselves from it (and I work in the security industry)

There’s not all that much being said about it, compared to say XSS or SQLi, and I’m certain that there’s more attacks out there using this vector than we know about, but it’s thankfully getting more noise.

I know that security sometimes gets in the way of usability, but in some circumstances you’ve just got to suck it up.

The one thing about the GMail example is that Google has more disk space than God, of course. One example that does pop to mind is Songza, which in several months of use I believe I’ve had to log in to once.

I tried ordering tickets on my iphone from the devilish business that is ticketmaster. While I’m pretty fast at typing on the phone I still found the windows of timeout it gave me incredibly annoying. At the top of the page it’d say something along the lines of “you have 2:00 to complete this page or your tickets will be released.” I can’t imagine how a slow typer on dial-up buys tickets online. I suspect their time windows are as much for pressuring you into buying as they are to protect their business from scammers. There’s no reason I need to make a 2 minute decision on tickets 2 months after tickets went on sale and 2 months before the event.

We actually just have our session timeout set to 1 day. But we don’t have anything all THAT sensitive (nothing financial) that somebody else stealing your session is that big of a deal.

Mostly it’s just to keep track of who does what. I think what happens is security stuff is developed for more sensitive applications (like banks) and then people think it needs to be used for everything.

All we have behind the login is additional content. If somebody steals that extra content, we aren’t really all that upset (plenty of people would rather get it legitimately).

However, when it comes to actual sensitive information a short timeout makes sense. Yes, it might be convenient to be able to walk away from your account, come back and make changes, but seriously, that’s a Major Risk in many circumstances.

Not everyone logs into those sites from a computer they know nobody else touches. Anybody from other family, neighbors to complete strangers might use the same terminal you do in many cases, and the people (IE Developers) who make the websites can’t know for certain that you aren’t on such a terminal.

I would liken it to starting a transaction at a bank terminal or ATM, and then walking away. Do you really think that somebody else won’t come along and make a withdrawal while your account is wide open?

So. I have to go 50/50 with you. On some applications the timeout is unnecessary and should go away (but you can just disable it, rather than having some fancy heartbeat). But on sensitive applications, it’s a no brainier. You NEED a timeout.

I agree that most people are able to make sure nobody else uses their terminal, but as a fellow developer, I am sure you know, it’s the edge cases that cause problems. And when you are talking finances, it can be a million dollar problem! Not something you want to mess with for the sake of convenience.

@Jeroen Mostert: "That’s what “Lock Workstation” is for."
Yes, that’s right. Forget to lock your workstation, and people should be able to steal all your money.

"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?"
What about them? I never use auto-password on anything I wouldn’t allow any user to be able to access. If your bank even allows you to auto-fill the password, you have WAY bigger problems. I don’t know the exact ins and outs of auto-fill, but you’re at least giving anyone who sits down at your PC the chance to RUIN YOUR LIFE.
And I’m struggling to find a really destructive use for browser history. The most they could do is blackmail you about your browsing habits, and let’s face it, The Internet is for Porn.

"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."
Unless you share a terminal with someone. Or someone knows your locking password (entirely possible).

NB. This all only applies to software such as Banking and Online Transaction software. Anything non-financial, not so much of an issue.

Pretty easy to force any website to refresh at an interval with greasemonkey…

window.setInterval(“window.location.reload();”, 300000);

The “lock” scenario is the best scenario I’ve seen. If a user’s session has timed out (or they logged out in another tab) and they submit a form, we “intercept” the request on the server, redirect back to the original page/form, populate the fields and place a “popup” div asking the user to login. It gets tricky when you have some significant state (multi-page forms) to keep track of, but over all it works quite well.

There are security reasons for timeouts. A non-expiring session cookie is still good even if I go to another webpage or quit my browser, then come back to the original webpage. Imagine someone on a public computer reading their email, leaving while forgetting to log off, then someone else comes and takes over. Like ATMs, you really need a timeout.

Why don’t you get session expire messages in GMail? It’s Magic! No, it’s just the fact that you are signed in and identified in Gmail. When your session cookie expires, GMail saves the state of your application. Clicking on a new link will simply restore your browser and give you a new session cookie. Plus, because GMail is AJAX, it knows when you are typing and keeps the session cookie refreshed. The only way you’ll time out is if you start composing an email, then leave your computer for an hour. And even then, GMail will save your draft before it expires.

So GMail’s tricks are:

  • You are always signed in
  • Using AJAX to refresh the session cookie when you are typing
  • Saving your state when the session cookie does expire

That won’t work for places that let you do things without first signing in or that don’t heavily use AJAX.