On Jan 17, 2008, at 5:11 AM, Jamie Stewart wrote:

One is by using JavaScript, history.back() is what you will want to use. If you don't want to use JavaScript it is possible through code, well with .Net at least. You can easily access the UrlRefferer which gives you the full URL of the previous page.

Of course, disabling the browser back button is "evil" and unnecessary...

The JS solution might work, but the question is how far back in the history one must go to escape the clutches of the evil app.

In my day job, the library's web site offers patrons access to various subscription databases - the user authenticates with a valid library card number on our site and is then passed forward to the database site. (Oh yes, and the back button does work). Almost daily we get complaints from patrons that the authentication doesn't work for them. In almost every instance we find they have Norton Internet Security installed. By default Norton suppresses referring URLs. This is a hugely popular app that most users install and never even look at the settings.

So neither of these solutions will be 100% reliable.

I'm probably a bit of an extremist, but I'm probably not alone - if I visit a site that tries to keep me imprisoned like this, I close the browser window and *never* return. No site is so compelling and so unique as to require that I (or any other user) put up with this abuse.

Can you ask the developers why and how they created this dysfunctionality? My guess is that there's some kind of preprocessing that goes on before allowing the user into the site itself, and the back button takes the user back to that page, which bumps them forward again. There is no technical constraint that requires this behavior. I seem to recall some "wisdom" from the 90s that proclaimed the desirability of keeping users on your site at all costs, but that has long since been discounted. But if there really is some compelling non-technical reason for not allowing users to escape back the way they came, then I'd suggest that this is a case where opening a new window would be justifiable.


List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm

Reply via email to