Re: [PHP4BETA] Browser BACK/Forward Button with Form

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