Re: Inhibiting Browser Back/Fwd Buttons via PHP?

From: Ralph Freshour (ralph_at_primemail.com)
Date: 10/20/03 

Date: Mon, 20 Oct 2003 13:55:31 GMT

First off, I'd like to say that the browser back and fwd buttons were
implemented when web pages were *static* - but as time and technology
went on, dynamic web pages came into being and we all know how
critical it is to call dynamic web pages via the links on web each
page, not by clicking the back/fwd buttons.

Now to respond to your reply: I don't want to display an expired page
because thats like displaying an error message - the user may continue
to click on the back button and then at the point the pages are all
screwed up from a dynamic data stand point.

I don't mind making the buttons disappear and because I tell them in
my help page not to use the back/fwd buttons, if they work around that
somehow and do invoke the buttons in another manner, I'll tell then
not to do that when they email me - how do you remove those buttons or
otherwise make them inoperative?

Thanks...

On 20 Oct 2003 06:17:07 -0700, tony@marston-home.demon.co.uk (Tony
Marston) wrote:

>Keith Bowes <do.not@spam.me> wrote in message news:<1066549704.905234@cache1>...
>> Ralph Freshour wrote:
>> > Is it possible to inhibit the browser Back/Fwd buttons via PHP?
>> >
>>
>> No. Firstly, PHP is a server-side technology and could only be used to
>> generate the appropriate client-side code.
>
>Yes, it is possible, because I have done it. It involves the use of
>sessions and self-executing scripts (ones where the script that
>outputs a page via the GET method also deals with the corresponding
>POST method). The technique is as follows:-
>
>a) Within a form any link to a different form does not invoke that
>form directly, instead it sends a message to the current form
>containing the identity of the required form.
>b) The required form is validated as some users may not be able to
>access some forms. If it is valid then it stores the new script name
>in a session variable called $_SESSION['expected_script'], then passes
>control to that script using the header() function.
>c) At the start of each script is a call to a standard initsession()
>function which checks that the name of the current script is the same
>as the one in $_SESSION['expected_script']. If it is then it is
>allowed to run, otherwise a 'page has expired' message is generated.
>
>This mechanism means that you have to go through the current script in
>order to be redirected to a new script, so if a user tries to use the
>browser back/forward button all they will see is a 'page has expired'
>message (unless that page is for a previous iteration of the current
>page).
>
>> And secondly, those buttons
>> are a necessary function for browsing in graphical browsers, and
>> inhibiting them would annoy users.
>
>I am afraid that allowing those buttons to be used annoys users even
>more than not having them at all. Take the following scenario:-
>
>a) A user starts a session with form A, then chooses form B.
>
>b) Form B can potentialy retrieve huge amounts od data, so it is
>displayed in separate pages with options to browse forwards and
>backwards through the available pages.
>
>c) Within form B the user browses through several pages, then wants to
>jump immediately back to form A. A button/hyperlink in the current
>form will do this, but the browser 'back' button will have to traverse
>all the prior pages the user visted while in form B before it gets to
>form A.
>
>d) To encourage the user to use the navigation controls within the
>page you have generated rather than the browser controls it is
>necessary to disable the browser controls. Although it is possible to
>make the back/forward buttons disappear they can still be invoked
>using the relevant key strokes.
>
>In this fashion I can make a web application behave just like a
>non-web application and not have to bother about the user switching to
>a previous page outside the control of my application. The user is
>only allowed to process a script which my application considers to be
>the 'current' script.
>
>Any questions?
>
>Tony Marston
>http://www.tonymarston.net/