Expiring web sessions
I do a *lot* of online shopping these days, the high-street is so far away, and then I have to find parking too. (Even then, when I get back to my car I may find dents in the doors from the adjacent car because the greedy car park company only allows a tiny space for each car!)
So, back to my point. Why do web-sessions expire? Visit confused.com and you'll often get:
We are sorry but your interactive session has expired.
So we have to go back and fill in all the forms again. The reason we have these web applications which don't work is because there isn't a professional UI/widget layout development system like we have on GNU-Linux with Qt and Qt Designer etc. So every programmer tries to do his/her best, redeveloping the wheel. Which leaves things like even the "Exit Confused Site" button not working.
Once we get a better web-server configuration which fits with a standard web application UI/widget these problems will go away, so for the moment we still have to suffer when using websites like confused.com.. oh well, things will improve eventually.
Labels: Future
posted by Jon Grant, 東京 @ 13:44
3 Comments
3 Comments:
I'm interested to hear what your alternative solution would be. I lot of the sites expire for efficiency (closing uncompleted database transactions) and security (not storing data on the web server that is no longer active).
I've seen suggestions for adding OpenID to improve persistence of sessions (using a login on sites I use a lot does work for me), and there's a chance that writing for Firefox 3.0's new offline functionality may solve this (if the offline mode is triggered automatically), but do you have any other ideas?
The first change has to be eliminating the timeouts. Increase it to 24hrs since last activity. My HTTPS GMail or forum login doesn't expire, so web shopfronts don't need to either.
As you say, persistence is key. Where a local application would store the data conventionally there needs to be a secure online repository (or offline via the Firefox 3.0 offline functionality you also mention). I'd personally prefer an OpenID online system, but I expect someone like Google will get the first working solution out. GMail-google-gears? I posted about the tabbed browsing problem which is related BTW.
Have you got any ideas yourself? This area is definitely going to be key in the next five years, and the first group to get it right with a widely adopted solution will be in a great place.
I think at the moment there are only 3 ways to persist data for shop fronts: Authenticated logins, cookies, or storing state in the URL.
The third has far too many security holes to be useful in this case (change the URL, get someone else's account) and any cookie-based solution will need to store state on the server, unless you want to send pricing and quantity information to and from and un-trusted client.
So we either use an id saved in a cookie or an authenticated login, which will behave in very similar ways as far as the web app is concerned: Pick up the unique identifier, retrieve the current session, generate the web page.
Cookies expire, it's part of their contract, and they can be deleted. Also, a large number of users (according to a survey earlier this year - reporting in The Register IIRC), will populate their cart, find the delivery price and decide to go elsewhere, but that session has to be stored as if they don't go elsewhere. What happens if, say, that session contains a Wii, which is then either out of stock when the customer next visits the site, or is held reserved in that order waiting for the customer to buy or cancel?
I think the problem is that for something like a forum or mail, a single form submission is an atomic transaction, so the server can store a complete state, but with shopping, each form submission updates the state of an ongoing transaction, and the longer that transaction goes on, the further out of sync it gets with the database (anyone who's used branching in source control will appreciate this I'm sure), so the problem is not only how to persist a transaction that cannot be committed, but updating that transaction to reflect the current system state. I see that as non-trivial.
For your insurance example, where I know quotes themselves expire after 30 days, the only solution I can really think of would be:
(1) Store your important details (i.e. name, address, type of car etc.) as one set of persistent information
(2) Store completed quotes with references to your details
(3) Automatically populate new quotes with your details and generate them just in time.
(4) Make sure that user interaction (logout buttons for example) never expires and always returns a valid state.
Post a Comment
<< Home