Justtechjobs.com Find a programming school near you






Online Campus Both


php4-beta | 200004

Re: [PHP4BETA] Browser BACK/Forward Button with Form From: Flemming Funch (ffunch <email protected>)
Date: 04/19/00

At 11:29 AM 1/1/2000, Sascha Schumann wrote:
>On Fri, Dec 31, 1999 at 08:46:55PM +0100, Tilli Weissenberger wrote:
> > On some forms I created the user gets the following error message, when
> > trying to use the BACK or FORWARD buttons on the browser:
> >
> > Warning: Page has Expired The page you requested was created using
> > information you submitted in a form. This page is no longer available. As a
> > security precaution, Internet Explorer does not automatically resubmit your
> > information for you.
>
> Tell the user not to use back/forward buttons. I know it is
> kind of annoying, if you have to educate your users, but it
> is usually the only working method to ensure that the data on
> the client side and on the server side is in a consistent
> state (I presume you are using sessions).

That's the most common answer I've heard to the problem, here or on the
phplib list. But I can't really believe there isn't a better answer.

My problem is not so much with the user using a back button, but with my
ability to show them the problems in a form they're filling in.

My forms are generated by PHP, often based on entries in a previous form.
The user fills in the form and hits submit. I then notice if something is
missing, and if so I tell them what it is, I show the message for a few
seconds, and then send them back to the same form with a history.back() thing.

But if I'm using sessions, the form they just came from 1 second ago has
expired. And hitting reload will of course lose the entries they just made.
Which isn't exactly acceptable.

The only alternative I can see, if I can't modify the headers to avoid
this, is to store all the form entries and regenerate the previous form,
rather than just moving back to it. But that adds unnecessary complexity in
my opinion, when I'm just trying to show a quick error message.

Anyway, I'd much rather have my program on the server side check for
consistency, and catch when somebody submits the same form twice, rather
than relying on that their page has expired. I fail to see why the use of
sessions would necessitate that nothing can ever be cached locally. I use
sessions as an easy way to make configuration data persistent without
having to pass it around as post or get variables, and without having to
look it up every time. I don't use it to manage bank balances or anything
like that.

A related issue is that I often would want to look at the generated source
of a PHP page, for debugging purposes. Which, again, the standard session
scheme would stop me from doing if there are forms involved, because the
page instantly expires. I seem to be able to get around that by adding a
header like:
header("Expires: " . gmdate("D, d M Y H:i:s",time()+3600) . " GMT");
after calling the session_register() function.

But that doesn't handle the history.back() problem. The page would still be
expired.

So, please, does anybody have a better solution to this? I know I can just
change the source code for the headers that the session module produces,
and recompile, but that seems a little drastic, and a pain to have to do on
a whole bunch of servers.

- Flemming 

-- 
PHP 4.0 Beta Mailing List <http://www.php.net/version4/>
To unsubscribe, e-mail: php4beta-unsubscribe <email protected>
For additional commands, e-mail: php4beta-help <email protected>
To contact the list administrators, e-mail: php4beta-admin <email protected>