There is also the case of timing out due to locking other resources than the server hardware. For example, in a web shop you don’t want one visitor to lock some items that could be bought by another visitor whilst the first visitor was gone doing something else.
My view on session timeout is, if you have very good h/w (like google) for your server then you can afford to keep the session for a long even if user is idle, and if you don’t have that kind of hardware (mainly RAM), you must use the session timeout. You can’t just make processing of other active members slow because of the idle users. Performance will surely go down as when RAM is over, then page file on disk will be used and overall performance will go down.
Typically apps don’t store state in cookies because they can be easily tampered with by a malicious user. The alternative is to store session data in the app, which generates overhead, hence auto-logging people out.
My solution in some applications is to generate a crypto keyed Hash Message Authentication Code (HMAC) of the cookie content and store that in the cookie.
Then, when the cookie is presented back to you, check the HMAC. You can now safely store all session data in plain text in the cookie, and need keep no state in the app.
I am a database Administrator.And for non trivial web apps that communicate with a database having sessions extend over hours and be resumable from where they were up to,implies locking records for hours in the database.This kind of thing really impedes other transactions and is another reason why session time out is sensible.
If it didn’t occur the same person may well be trying to get back in and not be able to, only to find their records still locked by their previous session!!!
Locking records in database for extended periods is a recipe for disaster. Say i wanted to update everyones salary by 10% and I cant, because all their records are constantly locked.
Database programmers try to ensure concurrency by by NOT allowing
locks to persist for extended periods.
If their “sessions” were kept open ( but not their database locks)
they would still need to re initiate these transactions to try to re aquire these ( records )locks in anycase. Besides, if in the mean time data has changed,you shouldn’t be merely trying to push through their transaction as the criteria upon which they have acquired these lock and records may have changed and would lead to a different or unwanted outcome or and may well mean that they dont want to proceed with the transaction any longer. ie. it is no longer wanted or needed
eg buying a book, if the mean time the price has gone up, or a better book become available - they may no longer want to buy it,or it may be out of stock. They should have to ( not unreasonably re initiate the whole process ) - I believe most people would want and expect this.
If you want to kill performance and user satisfaction and basically kill the app - allow sessions to hold locks indefinitely.
I don’t recall the URL of the blog entry, but some time ago I stumbled over a new functionality in a well-known AJAX framework, which’ name I don’t recall either. It offers some kind of “screen-saver” overlaying the page/application with a modal dialog, requesting to re-authenticate after a time-out with the password. When done so, modal dialog disappears and the user can continue working as when he left.
Indefinite session time out makes no sense, but usually a day or so, at least for interactive apps, makes sense. The question is whether you want to pay for it to set up the resources to hold the sessions long enough.
Cheers!
@one of Paul Houle’s comments, the “10-minute timeout”, c.:
The library catalog Voyager does put ridiculous resource demands on a server with its web interface (RAM demands increased by a factor of 5 from one version to the next), agreed. But it, and similar software, consist of far more than that front end: It’s like an iceberg, with much happening where the user doesn’t see it. Gotta share resources, and many libraries aren’t keen on buying the amount of RAM needed to support hundreds of long-running sessions, precisely because the user doesn’t see it–how can you justify it to a university administration, for example? BTW, the timeout doesn’t have to be 10 minutes: Some Voyager libraries have a timeout as short as three minutes and others have timeouts of 30 minutes (or more).
But as a librarian, I’m very much conditioned to think of the user’s privacy, and I want to protect your privacy EVEN IF YOU ARE NOT LOGGED IN to the software. So I want that library catalog session to time out, because it isn’t anybody’s business what you were looking for in the catalog.
Some of you punters still don’t get it. Relying on session tear-down is a bandaid to bad coding. Relying on session data and having that reliance visible to the user, at all, is bad practice.
If you have users, you store things like shopping carts, preferences, etc. You should store these indefinitely, or at least until you can tell that a user is never coming back. Storage is cheap. You would never hold any of this in ‘session’ unless you’re an idiot. Newbies take note! What looks easy is a recipe for disaster.
Locking: No self-respecting developer should hold a database lock open between requests, let alone minutes and hours. Unless you only make single person websites, this will never scale, ever. @Mark, I pity you for the people you work with. Non-expiring sessions does not imply locking. Retaining a db lock over 1 request implies bad coding. Smells like limburger cheese left in a heating vent for a few months.
Sessions are a bad smell. You don’t need in-memory ‘sessions’, ever. Read my previous post about what a session is. In God knows how long I’ve been writing websites, there’s always a better, more scalable way.
Session are not the same as authentication timeouts. Most self-respecting frameworks let you re-authenticate without losing what you’re working on. It’s a usability thing, but maybe you just don’t care about writing correct websites.
RTFM = READ The Fscking Manual
On a project that I worked on, we actually had some fancy stuff that would allow you to “resume” after a session time-out error. In summary, when you would make a request to the server after your session had timed out, you would get a lightboxed login screen. By filling the form out and submitting, the application would attempt to re-execute the request that you had originally submitted (I think the request was serialized as a hidden field on the lightboxed login form). This worked for any XMLHttpRequest. So, you could half-fill a form, go away for a year, and come back to fill the rest of the form. When you click “submit”, it would ask you to authenticate, but would then successfully post your form (as long as we hadn’t changed the code on the back end during your hibernation).
This was reasonably easy because we were using a custom MVC library on the server. Granted, I’m not suggesting that you develop or use a custom MVC library (ever!), but that’s what we had and so we (ab)used it. The overall experience was slick. Well, I think so anyway.
Perhaps a better solution to the problem is coming with HTML5 and client-side storage. Rather than store session on the server, it might be possible to store everything you need to know on the client (as long as you validate it all before you use it on the back-end).
Use SSL client certificate instead. It is secure as SSL. The process of logging in is hidden from user, you don’t see forms, don’t press a submit button and such a crap, don’t reload a page, are not redirected, nothing. Major browsers support SSL client certificate. It’s a shame that it is not used on web-sites. You can even benefit from global authorization (like OpenID), because you can safely log into different sites with the same client certificate.
I like an IFRAME with a page (say HeartBeat.aspx) that serves itself as an empty page with a meta refresh… as long as the user is on any page, they keep chatting with the webserver to keep the session alive. Makes 5 minute cookies a reality.
http://www.codeproject.com/KB/session/Session_Defibrillator.aspx
Isnt this a simpler way to keep session alive? Use SetInterval, then include the EnableSession attribute on your web service method?
window.setInterval(KeepAlive, 300000);
[WebMethod(EnableSession = true)]
public void KeepAlive()
{ return;}
What if Cookies are turned off- I never had solution for Gmail with IE - Accidentally I turned off my cookies now I am never able to login on Gmail through IE - btw I don’t like that browser always 
Mozilla is perfect for us.
In fact there is a fairly simple solution to the problem of preserving context after session expiration. Dan on May 10, 2008 10:27 PM has something nice, but there is a simpler approach that resides entirely on the server and therefore doesn’t require XMLHttpRequest or indeed any Javascript at all.
In short, it involves never changing the URL, even if you need to display or process a login form, and always adding to the login form any post your page has received, using hidden fields.
A well crafted, general-purpose include module (or equivalent technology) can handle this for all (form processing or plain GET) pages in your web application, so you don’t have to implement this solution on each of them individually. The same goes for the processing of the login form: every page should potentially be able to process it (the authentication logic should go into an include that every page can use if a post is detected and it contains the login and password fields).
The only elements of your form that will need special attention are file upload fields but there are solutions for these, too.
I have been using this for years, and it works perfectly. After the user is authenticated, whatever he was trying to do is performed.
Good Day. Do not be awe struck by other people and try to copy them. Nobody can be you as efficiently as you can.
I am from Mauritius and learning to speak English, give please true I wrote the following sentence: If you are looking for the best online travel agency, then you just succeeded by finding sas airline tickets.
Thank you very much :P. Kabibe.
A common practice to prevent sessions to be stolen, is to bind it to a certain IP address. If someone steals such a session id (such as copy-pasting an url which has the session id as a parameter), the session still will not be recognized as yours since the IP addresses differ.
It isn’t totally safe, but safe enough to take the effort to implement (it’s only an additional WHERE clause for the session-retrieval-sql, guys).
I know what application have session timeouts. So I just quit them and start new one after a while. They don’t tell me that the session has been timed out before I start doing something again. There could be at least the heart beat that shuts the application so I know that it logged me out.
Some applications that I use over intranet log me off too. Then they hide the relog button behind few clicks, which is irritating. At least give me the relog page without me having to search for it.
I’d just save all my changes on their documents and tell them to complain to the IT department. The fact that you are making changes and having to exit “fast enough” is absurd.
In general:
The credit card companies and banks pay dearly for fraud. If you walk away it’s unlikely you will have to pay a thing. I’d prefer not to be logged out, but really you should have to deal with whatever they give you, because they are the ones at risk.
Ideally there would be something you could sign that says “I want to be logged in at all times and I’ll be responsible for any and all charges, blah blah”, but I guess there are legal reasons why that’s not possible.
(I also think that stores should be required to check ID for every credit card purchase, and if they don’t, the fraud is their responsibility. But if you want to sign something ahead of time that says “I don’t want to show my ID, and if someone uses my credit card then I’ll be responsible”, then you should be able to do that too.)
@T.E.D.
I’ve actually taken to composing posts in emacs and pasting them in the edit box when I’m ready. I just can’t trust my content to Blizzard’s user interface. But sometimes I forget and loose another 20 minutes of work. Grrrrr.
A good habit to get into before submitting a web form with a lot of content in a text field – a long forum post is a prime example – is to do a Ctrl+A, Ctrl+C on the content field. (Ctrl+A does a Select All; Ctrl+C does a Clipboard Copy. The specific keystrokes may vary if you’re on a platform other than Windows.) Then, if the session has timed out or something else goes wrong, at least you have a copy of the content you entered sitting on your clipboard, which you can save off somewhere locally and/or re-enter on the web form.
http://blog.jonschneider.com/2006/02/tip-ctrla-ctrlc-before-submitting-text.html
Obviously, this tip is only really applicable for “power users”, and it doesn’t help on a web form with many individual fields (as opposed to one primary large field), but I’ve still had it save me from losing content on more than occasion.
And the answer is: Don’t use sessions. When user logs in, store a security token on the server and pass it down to the client (encrypt it, etc). When client posts a new request, pass the token as part of the request (hidden variable on a page). If valid, post the data, if invalid, have use authenticate again and then post the data.
Add logout feature that automatically invalidates the token.
The only thing that should expire is the token.
If not using HTTPS, I can see possibilty the token being “hijacked” by another entity, but maybe check IP Address or location of token when it was validated.
If security is really a concern, then use HTTPS and then no one can see the token.