Inhibiting Browser Back/Fwd Buttons via PHP?

[Ralph Freshour]

Is it possible to inhibit the browser Back/Fwd buttons via PHP?

Thanks...

[Keith Bowes]

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. And secondly, those buttons
are a necessary function for browsing in graphical browsers, and
inhibiting them would annoy users.

[Ralph Freshour]

If anyone else replies please use my email address as I'm losing my
ISP news server - thanks...
On Sun, 19 Oct 2003 03:26:17 GMT, Ralph Freshour <ra***@primemail.com>
wrote:

Is it possible to inhibit the browser Back/Fwd buttons via PHP?

Thanks...

[Geoff Berrow]

I noticed that Message-ID: <6d********************************@4ax.com>
from Ralph Freshour contained the following:

If anyone else replies please use my email address as I'm losing my
ISP news server - thanks...

Well get another one! www.news.individual.net

Post to Usenet, reply to Usenet.
--
Geoff Berrow
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/

[Tony Marston]

Keith Bowes <do****@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/

[Ralph Freshour]

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, to**@marston-home.demon.co.uk (Tony
Marston) wrote:

Keith Bowes <do****@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/

[Tim Tyler]

Tony Marston <to**@marston-home.demon.co.uk> wrote or quoted:

I am afraid that allowing those buttons to be used annoys users even
more than not having them at all.
Doubtful. It is like taking away a child's favourite toy ;-)
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.

Your user is using a browser written in 1995? Otherwise, why can't he use
the drop-down menu?
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.

[Jochen Daum]

Hi Ralph!

On Sun, 19 Oct 2003 03:26:17 GMT, Ralph Freshour <ra***@primemail.com>
wrote:

Is it possible to inhibit the browser Back/Fwd buttons via PHP?

The following sketch of a solution gives you what you want:

1. Read user input from POST and/or GET
1a. If POST, redirect with:

if ($_POST){
$_SESSION["postvalue"] = $_POST;
header ("Location: ".BASE_URL.$sess->assemble(),true, 302);
exit();
}else{

if (isset($_SESSION["postvalue"])){
$_POST = $_SESSION["postvalue"];
unset($_SESSION["postvalue"]);
}
}
this gets you around the "page expired problem"
2. Read variables that define view from SESSION (see 4)
3. Process input
4. Save current view settings into a session. That means, every
variable that you use to display the current page, gets saved into a
SESSION variable.
5. Display page.
Have this control flow implemented in one page, ie. always use
index.php to run your script.

That way the Back button can be there, but users just get the same
page.

HTH, Jochen
--
Jochen Daum - CANS Ltd.
PHP DB Edit Toolkit -- PHP scripts for building
database editing interfaces.
http://sourceforge.net/projects/phpdbedittk/

[Tony Marston]

Tim Tyler <ti*@tt1lock.org> wrote in message news:<Hn********@bath.ac.uk>...

Tony Marston <to**@marston-home.demon.co.uk> wrote or quoted:

I am afraid that allowing those buttons to be used annoys users even
more than not having them at all.

Doubtful. It is like taking away a child's favourite toy ;-)

I write web applications for adults, not children.

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.

Your user is using a browser written in 1995? Otherwise, why can't he use
the drop-down menu?

In a dynamic web application it is sometimes necessary to force the
user to use the controls provided within each page to navigate
forwards to or return to another page. Using the browser 'back' button
(which, as someone else has pointed out was designed and implemented
when all the pages were static) can cause no end of problems. It one
thing to ask the users politely NOT to use the back button, but it is
much better to disable it in the first place. As I have already said,
it is possible to reject any attempt by the user to use the browser
'back' button, but it does require a bit of code on the server side.

Tony Marston
http://www.tonymarston.net/