Is it possible to inhibit the browser Back/Fwd buttons via PHP?
Thanks...
Thanks...
-
-
Re: Inhibiting Browser Back/Fwd Buttons via PHP?
Ralph Freshour wrote:[color=blue]
> Is it possible to inhibit the browser Back/Fwd buttons via PHP?
>[/color]
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.
-
Re: Inhibiting Browser Back/Fwd Buttons via PHP?
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 <ralph@primemai l.com>
wrote:
[color=blue]
>Is it possible to inhibit the browser Back/Fwd buttons via PHP?
>
>Thanks...[/color]
Comment
-
Re: Inhibiting Browser Back/Fwd Buttons via PHP?
I noticed that Message-ID: <6db5pv8k2tqdaa kf0mtjirmgsnda9 1u7vp@4ax.com>
from Ralph Freshour contained the following:
[color=blue]
>If anyone else replies please use my email address as I'm losing my
>ISP news server - thanks...[/color]
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/
Comment
-
Re: Inhibiting Browser Back/Fwd Buttons via PHP?
Keith Bowes <do.not@spam.me > wrote in message news:<106654970 4.905234@cache1 >...[color=blue]
> Ralph Freshour wrote:[color=green]
> > Is it possible to inhibit the browser Back/Fwd buttons via PHP?
> >[/color]
>
> No. Firstly, PHP is a server-side technology and could only be used to
> generate the appropriate client-side code.[/color]
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_scrip t'], 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_scrip t']. 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).
[color=blue]
> And secondly, those buttons
> are a necessary function for browsing in graphical browsers, and
> inhibiting them would annoy users.[/color]
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
Comment
-
Re: Inhibiting Browser Back/Fwd Buttons via PHP?
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.u k (Tony
Marston) wrote:
[color=blue]
>Keith Bowes <do.not@spam.me > wrote in message news:<106654970 4.905234@cache1 >...[color=green]
>> Ralph Freshour wrote:[color=darkred]
>> > Is it possible to inhibit the browser Back/Fwd buttons via PHP?
>> >[/color]
>>
>> No. Firstly, PHP is a server-side technology and could only be used to
>> generate the appropriate client-side code.[/color]
>
>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_scrip t'], 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_scrip t']. 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).
>[color=green]
>> And secondly, those buttons
>> are a necessary function for browsing in graphical browsers, and
>> inhibiting them would annoy users.[/color]
>
>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/[/color]
Comment
-
Re: Inhibiting Browser Back/Fwd Buttons via PHP?
Tony Marston <tony@marston-home.demon.co.u k> wrote or quoted:
[color=blue]
> I am afraid that allowing those buttons to be used annoys users even
> more than not having them at all.[/color]
Doubtful. It is like taking away a child's favourite toy ;-)
[color=blue]
> 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.[/color]
Your user is using a browser written in 1995? Otherwise, why can't he use
the drop-down menu?
--
__________
|im |yler http://timtyler.org/ tim@tt1lock.org Remove lock to reply.
Comment
-
Re: Inhibiting Browser Back/Fwd Buttons via PHP?
Hi Ralph!
On Sun, 19 Oct 2003 03:26:17 GMT, Ralph Freshour <ralph@primemai l.com>
wrote:
[color=blue]
>Is it possible to inhibit the browser Back/Fwd buttons via PHP?[/color]
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.$ses s->assemble(),tru e, 302);
exit();
}else{
if (isset($_SESSIO N["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.
Comment
-
Re: Inhibiting Browser Back/Fwd Buttons via PHP?
Tim Tyler <tim@tt1lock.or g> wrote in message news:<Hn2Anz.K8 x@bath.ac.uk>.. .[color=blue]
> Tony Marston <tony@marston-home.demon.co.u k> wrote or quoted:
>[color=green]
> > I am afraid that allowing those buttons to be used annoys users even
> > more than not having them at all.[/color]
>
> Doubtful. It is like taking away a child's favourite toy ;-)[/color]
I write web applications for adults, not children.
[color=blue][color=green]
> > 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.[/color]
>
> Your user is using a browser written in 1995? Otherwise, why can't he use
> the drop-down menu?[/color]
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
Comment
Comment