Not so. If you expire the cookie, you can still store the session id inside a hidden form field.
Now, let’s say the user comes back and completes this form. Just allowing the entry is a security risk. What if, in the time you walked away, someone else sat down at your computer? No, you must re-enter your password after your session expired. BUT YOU ARE ABSOLUTELY RIGHT - YOU SHOULDN’T LOSE YOUR DATA!
So how about this:
Store the user’s session data on the server for a long period (e.g. a day).
The session KEY should expire, but still be kept on the system.
However, a new one is generated every time you log in.
Thus, if you came back to the computer after an hour and submitted your form, the system would see that you used the old session key. It would ask you to log in and GENERATE A NEW SESSION KEY FOR YOU. However, after you have successfully logged in, IT WOULD PROCESS THE FORM YOU JUST SUBMITTED, essentially letting you pick up where you left off!
If a site wanted to be really friendly, it should allow you to LOG OUT but still save your form data, to fill out later. Let’s say you have to go to a meeting and you don’t want to wait the mysterious “X” number of minutes until your session expires, to make SURE you are safe. And you are in a library. And you can’t just lock your computer.
So just LOG OUT and when you LOG BACK IN the site can restore things exactly as you had them!
THAT would be cool. Maybe it should be called “LOG OUT AND SAVE WHAT I WAS DOING”.
Right before the session is abandoned I check to see if the user logged out, if so I persist session state to a table keyed on the user’s login. Next time they login they we check the db for any persisted session data in the db. If there is they are asked if they want to resume their session. If they say yes, it is rebuilt from the db, if not it is destroyed in the db. The sessions expire every X minutes (no sliding expiration) unless the user responds to a “keep me signed in” popup that is displayed Y seconds before the session is abandoned. If the user does not respond to the popup in Z seconds, their form data is submitted (via ajax) and it is saved in session along with the page they were on when the session was expired.
Leaving your computer without locking it is akin to walking away from your unlocked car while the keys are in it and it’s still running.
Session timeouts are similar to your keys falling out of your keyswitch the radio settings and power seats reseting because you sat at a stop light too long. You need to restart the car, reconfigure the radio and move the seat back to where you had it before you can continue on your drive.
The solution here is behavior modification in terms of educating users on the nasty things that might happen if they leave a valuable asset open for all to use. Lock it when you leave it sit there or someone may just come along and steal those 8-tracks in the back seat.
The issue is more about balancing the timeout value with the sensitivity of the web app. Banking and highly sensitive apps should log you out quickly, but web sites of a less serious nature should change the default timeout value to something higher, like a day instead of 30 mins.
Users expect that by closing their browser, they are done with the session and it’s hard to explain to them that somebody can sit down after them and pull up their session from the browser history.
Forms on the other hand should always submit without requiring a session. I usually add a hidden formfield with a MD5 hash of the user ID plus a secret salt value so I can accept forms without having to rely on a session cookie.
For preventing data loss in case of session timeout, it should be browsers responsibility to keep a copy of user data, if session expires, the user can hit Back button to get its composed email text.
it would be nice if we can have some standard Logoff and Lock buttons (web site level lock as we have for OS) in the browser - like we have close on top right corner.
I agree with you, session expiration sucks big time.
But there’s a case you forgot, public computers. A cyber cafe or any other public access computer, people normally don’t really understand what a session really is, they walk away and they think they magicaly left gmail… but then another guy comes and now he’s in control of your account. People DON’T close sessions, they don’t see why and there’s no way for the app to warn them when they leave.
It’s not perfect, of course, someone could use the same terminal before the session expired, but well, there’s no other way I can think of.
By the way Jeff, this comment form keeps showing me the same word (orange) in the Captcha… is it because it recognizes a cookie or something like that?
My captcha is “orange” too! Is that by design? Or is it a “feature”?
In response to your article:
I think we’re treading dangerous waters when we seek to enable the insecure habits of lazy users. Users should be encouraged to maintain the security of their information. I agree with the plethora of posts that suggest a hybrid solution: extend state, trash session.
Also, we should look to sites that get the user experience right, instead of focussing merely on our budget banking websites. For example, consider the way Amazon.com manages state. Your session is kept alive, but your ability to perform financial or identity actions will expire after a certain time. I don’t know exactly how this is implemented, but I love the fact that I can leave Amazon up for hours, and rest assured that nobody can come along and buy stuff using my account without re-logging in.
session timeouts are very, very necessary for the fact that users still routinely check their bank accounts from public terminals. until every person on earth becomes intelligent, session timeouts ain’t going anywhere.
Why not give the user the option? Make him/her select whether or not they’re accessing from a public or private computer? Sessions should persist on private computers, but on public machines, the user should understand that, for his/her own good, the session will terminate after time.
I can’t believe people are still bringing the “We need to educate our users” line. Look, it’s not gonna happen. Users don’t learn because you feel like they should know something. We have had 50 years of IT science, and users still haven’t learned. Individual users learn, but users as a whole don’t, not like this, not because you want them to.
The only way to get users to learn to lock their PC is if Windows would shut down instead of starting a screen saver, and even then they probably would just get a tool that “fixes” it instead of remembering to lock their PCs.
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.
The issue can only be solved by end user discipline. 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.
“Create a background JavaScript process in the browser that sends regular heartbeats to the server”
Defeats the benefits of a timeout… more work for the server. Actually, even worse than disabling the time-out, as bandwidth is being used as well as memory for caching the session info.
“How are timeouts a benefit to the end user?”
Prevents your son buying crap on ebay using your pre-logged on Paypal account. Even vigilant users may forget to press ‘Sign Out’ at some point in their lives… I know I have.
“Imagine if Microsoft Word or Excel “logged me out” if I was idle too long in a document.”
Why would it? Microsoft are not responsable for such measures here. In a web app, the developers are charged with protecting the data that drives their site’s back end or user data… therefore they must put such mechanisms in place. Word and Excel really arn’t responsable for ensuring that your data is safe… that comes down to the IT administrator on your corporate network. With this in mind, I think it’s safe to say that the source of DATA are ultimately responsable for its security, not a third party developer of a generic piece of software that has many uses in many areas.
It was suggested that it should be left up to the OS to log off the user if idle for a set length of time. This does nothing for security or performance as a website developer can not control every PC that visits, so the only alternative is a server side time out. All in all, security comes down to the end user… after all it is those people who share their passwords or enable the password save in their browser. That being said, time-outs are established primarily as a means of ensuring that the web server stays a web server and not a speed bump, as well as giving the developer/host a way out when legal actions suppose that their system is at fault when some user left their password taped to their machine.
In my case, the session timeout was a ‘feature’ – or rather, something that WAS necessary.
It’s a ticket purchasing system for a smaller endeavor: wherein, once you have said that you want to purchase 5 tickets – those 5 tickets are temporarily held/reserved to prevent oversell of an event.
If you wander away and leave a half-filled out form: your session expires and your ‘faux reservation’ goes back out into the pool of available tickets.
The most stupid logout occurs in Sharepoint even though your session is identified through your Windows Active Directory Account. After some inactivity, it takes you to an intermediate page, where you have to push a link to reactivate your session. How daft is that?
“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.”
Vice versa, if it’s done in a way that isn’t a drag on resources, or is less of a drag than the extra money it generates, then it’s worthwhile. Otherwise we may as well have no application at all, to free up all that precious cpu.
“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.”
No, I just expect different service out of an unthinking, unfeeling machine than I would a human, and I can’t understand this anthropomorphizing of the web server. You’re the one basing your rationale on web application design on an industry example absolutely unrelated to the matter under discussion. I mean, if you’re going to consider thirty minutes rude to a human server, then you may as well consider thirty microseconds as being rude to a web server, adjusting to its own time scale. Does it start to make sense how arbitrary the attitude is now?
Look at the shopping cart comment above and think back to how frustrated you got the last time you lost your cart over a session timeout.
See, I can write the code to transfer a session at timeout to another table, to prevent performance degradation, and load the session back into the main table on the next login (whether it’s in five minutes or five years), in no time. Machines don’t care if they have to hold onto things for long periods. I’m damn glad that I don’t have a manager like you throwing such bizarre analogies at me when building applications - the clients are already bad enough.
