Re: back-button question

On Sep 18, 9:34 am, n...@xxxxxxxxxxxxx (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 help- 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 helps :)

.