I'a writing first time so sorry if i reapeat but
i wanted to say this in my own words and angle.

My question is :

Lets assume that we'r going throught php/html files

a-----> b ------> c
|<--------|


1)From a to b through a link

2)from b to c through a submit button (post method)

3) c is a php script which does some mysql queries and changes
some session variables and outputs a location header to
return to b.


While back in b we press the back button
when back button is pressed
my icewiesel browser gets me to 'a' page.

Trying to find some sense i postulated
that a browser holds in its history (for back/forward)
only requests made explicitly by the user and not the ones
made from withing php files (with header commands) .
Is my theory right..

I'm searching in the broader context of trying to control
how my bookstore website will react to random events from
the user (back/forward, links etc) while in a middle of
a series of php files that i want to act as a transaction.


Any - recommendations for study on the subject would be very
welcomed. I have 3 books on mysql/php but that issues
r not examined,



Prekates Alexandros
Trikala Greece

prekates,

there is no way to block or control the back-button with php.
you may manipulate the entry of the last visited site (and only the
last visited!) in your browsers history using
javascript:location.replace(). open the site in a browser window
without a menubar and block the right mouse button. of course, modern
5- or more button mouses often doesn't need a right click to perform a
history.back() event.

giving a script full access to your browsers history opens an giant
security hole.

lorenz

The general rule is to create or maintain every page on your server of what you
what the client to see. Then send it for every submit. That way you don't have
to worry about satisfying every browser and configuration there is.

ÎÏ�εκατÎÏ‚ ΑλÎξανδÏ�ος wrote:
> I'a writing first time so sorry if i reapeat but
> i wanted to say this in my own words and angle.
>
> My question is :
>
> Lets assume that we'r going throught php/html files
>
> a-----> b ------> c
> |<--------|
>
>
> 1)From a to b through a link
>
> 2)from b to c through a submit button (post method)
>
> 3) c is a php script which does some mysql queries and changes
> some session variables and outputs a location header to
> return to b.
>
>
> While back in b we press the back button
> when back button is pressed
> my icewiesel browser gets me to 'a' page.
>
> Trying to find some sense i postulated
> that a browser holds in its history (for back/forward)
> only requests made explicitly by the user and not the ones
> made from withing php files (with header commands) .
> Is my theory right..
>
> I'm searching in the broader context of trying to control
> how my bookstore website will react to random events from
> the user (back/forward, links etc) while in a middle of
> a series of php files that i want to act as a transaction.
>
>
> Any - recommendations for study on the subject would be very
> welcomed. I have 3 books on mysql/php but that issues
> r not examined,
>
>
>
> Prekates Alexandros
> Trikala Greece

On Sep 18, 9:34 am, n...@ridersite.org (Al) wrote:
> The general rule is to create or maintain every page on your server of what you
> what the client to see. Then send it for every submit. That way you don't have
> to worry about satisfying every browser and configuration there is.
>
> wrote:
> > I'a writing first time so sorry if i reapeat but
> > i wanted to say this in my own words and angle.
>
> > My question is :
>
> > Lets assume that we'r going throught php/html files
>
> > a-----> b ------> c
> > |<--------|
>
> > 1)From a to b through a link
>
> > 2)from b to c through a submit button (post method)
>
> > 3) c is a php script which does some mysql queries and changes
> > some session variables and outputs a location header to
> > return to b.
>
> > While back in b we press the back button
> > when back button is pressed
> > my icewiesel browser gets me to 'a' page.
>
> > Trying to find some sense i postulated
> > that a browser holds in its history (for back/forward)
> > only requests made explicitly by the user and not the ones
> > made from withing php files (with header commands) .
> > Is my theory right..
>
> > I'm searching in the broader context of trying to control
> > how my bookstore website will react to random events from
> > the user (back/forward, links etc) while in a middle of
> > a series of php files that i want to act as a transaction.
>
> > Any - recommendations for study on the subject would be very
> > welcomed. I have 3 books on mysql/php but that issues
> > r not examined,
>
> > Prekates Alexandros
> > Trikala Greece

We've ran into this type of situation a lot in some of the
applications I've been writing for an insurance company. I use two
methods to handle this:

First, set a token on each page or delete the token depending on where
you are in the rotation of pages. Then, at the top of each display
page, check for the required tokens. If they are not set, do a
die(header("Location: /urlToGoto")); to the page you might allow them
to.

The next thing to do requires handling form submissions. So, if you
are posting from page 1, and then need to show page 2, post to
page1.process, and verify all the data and store it in a session or
db. THen use a header / location to get to page 2. This way, if the
user clicks back, the browser interprets the destination as page 1
instead of page1.process.

Let me give you a real world example:

Page 1: enter user's new email address - posts to page1.process. If
session contains a previously posted e-mail address, fill our form
with that address.

Pag1.process. Store emaila ddress in session right away (see end of
page 1 description). Verify that e-mail address is valid. if not,
redirect back to page 1 with error. If so, set a token saying we're
allowed to goto page 2 (or on page 2, you could just check for e-mail
address in the session too...).

Page2 - check for token (or the e-mail addressi n session). If not
exist, redirect back to page 1. If exists, show e-mail address on
screen and ask user to confirm. Button 1 goes to page 1. Button 2
goes to page2.process

Page2.process checks for e-mail address in session. (just in case
they served here directly). If not, redirect back to page 2 (see it
could be a legiimate mistake... but if the user surfed here
immediately, page 2's redirection will handle getting them all the way
back to page 1... so remember, always send them back to the closest
possible valid page and trust that page's logic). If set, call db
connection and change the e-mail address. Set token that we can goto
page 3.

Page 3, check for token. If not, redirect them back to page 2, if so,
show e-mail address from session with confirmation message. Then
unset e-mail address and token. Also suggest the next place for them
to go with a link or button or text.

I hope that s

Στις 17-09-2007, ημÎÏ�α Δευ, και ÏŽÏ�α 23:33 -0400, ο/η Eric Butera ÎγÏ�αψε:
> On 9/17/07, ÎÏ�εκατÎÏ‚ ΑλÎξανδÏ�ος <aprekates@gmail.com> wrote:
> > I'a writing first time so sorry if i reapeat but
> > i wanted to say this in my own words and angle.
> >
> > My question is :
> >
> > Lets assume that we'r going throught php/html files
> >
> > a-----> b ------> c
> > |<--------|
> > .
> > .
> >
> >
>
> Browsers will not store a page that contains a header redirect in the
> history. In fact what you're talking about even has a name for it:
> http://en.wikipedia.org/wiki/Post/Redirect/Get

Thanks very much for your responses. The above link was very full
and the advice of Al. I have started studying PRG , model-view-control
and web application frameworks, areas that i didnt know they exist!!


Alexandros Prekates.
Trikala Greece