What kind of problems can I expect with the back button in a typical web application involving transactions? In my application, a Customer could browse the website and buy a few items.(typical basket/checkout kind of functionality)
Say, I have a page with a basket containing 2 items. I add a 3rd item, now my basket shows 3 items. I could press back button in the browser, go back to my previous page. See that there are only 2 items and add another item. But now my basket will show 4 instead of 3. Is this a valid reason why we would handle the back button?
I could handle the back button in the foll. ways:
What the pros and cons of the above 3 options?...Are there any other options apart from the above?
4) None of the above. Design operations with page caching in mind.
The other option you're missing is that alt-back arrow also goes back. I use this without thinking.
Firstly you need to define the pages that shouldn't be cached by the browser and set them up with the required no-cache functionality. If you're not too worried some people make the whole site uncachable.
Secondly, you need to understand POST and GET and make sure you POST data and GET pages. Don't be tempted to combine the two.
The third step I use is I guess what I'd call a non-displaying-processing-servlet, and it's your best tool for protecting yourself against the back button.
That's it. The only special bit is that it doesn't display a page after, it uses sendRedirect to delegate display to another page. The trick here is that since the POST doesn't result in a page, refreshing doesn't result in data being reposted. Also, since (presumably) the previous page wasn't cached and was requested via GET, it automatically gets refreshed by the browser.
There are still a few down sides to it, such as using the back button to go back to a non-cached POSTed page, but it's easier to manage and design around than trying to create a site that effectively blocks the back button.
In my opinion, anyway. Hope this helps, Dave.
Joined: Aug 27, 2003
Thanks Dave, Sorry for not replying to you earlier. Yes, your idea did help us.