HELP -> stop post data expiring?

[brendan]

Sorry this isnt a cross post .. i just didnt get any help from alt.php.

I have a website which utilises post forms for navigation in some areas.
Problem is, when *some* users hit the BACK button the POSTDATA
content has expired and they need to refresh the page then they get a
alert about refreshing expired data.

I am getting complaints that this is too annoying and limits the sites
useability.

For security reasons I cant swap post for get.

the header content of the page is
header('Expires : '.gmdate('D, d M Y H:i:s', time() + 600) .'GMT');

which seems to work on some browsers/systems but not others ...

I want to over-ride the users cache settings but am not sure how this
can be best achieved in respect of POST data

any help greatly appreciated.

[Erwin Moller]

Re: HELP -> stop post data expiring?

brendan wrote:
[color=blue]
> Sorry this isnt a cross post .. i just didnt get any help from alt.php.
>
> I have a website which utilises post forms for navigation in some areas.
> Problem is, when *some* users hit the BACK button the POSTDATA
> content has expired and they need to refresh the page then they get a
> alert about refreshing expired data.
>
> I am getting complaints that this is too annoying and limits the sites
> useability.
>
> For security reasons I cant swap post for get.
>
> the header content of the page is
> header('Expires : '.gmdate('D, d M Y H:i:s', time() + 600) .'GMT');
>
> which seems to work on some browsers/systems but not others ...
>
> I want to over-ride the users cache settings but am not sure how this
> can be best achieved in respect of POST data
>
> any help greatly appreciated.[/color]

Hi brendan,

I am not sure you can repair this.
AFAIK some browsers tell the visitor that the page they see is a result of a
posting (form). Which is a good thing, because it is the result of a
posting.
I am unsure if you can fix this by adding headers.. (hopefully for you
somebody knows. :-)

If you want to 'repair' this behaviour, you can add your own
navigationbutto ns to the page and implement a decent post for 'back'-button
behaviour. Allthough this is not always possible.

And honestly I don't understand the security-implementations you have with
GET that disappear by using POST.
POST data is also send over the network, it just doesn't show up in the URL,
but it is there.....

If you want more security, use encryption. (https)

just my 2 cents.

Regards,
Erwin Moller

[brendan]

Re: HELP -> stop post data expiring?

Erwin Moller wrote:
[color=blue]
> brendan wrote:
>
>[color=green]
>>Sorry this isnt a cross post .. i just didnt get any help from alt.php.
>>
>>I have a website which utilises post forms for navigation in some areas.
>> Problem is, when *some* users hit the BACK button the POSTDATA
>>content has expired and they need to refresh the page then they get a
>>alert about refreshing expired data.
>>
>>I am getting complaints that this is too annoying and limits the sites
>>useability.
>>
>>For security reasons I cant swap post for get.
>>
>>the header content of the page is
>>header('Expir es: '.gmdate('D, d M Y H:i:s', time() + 600) .'GMT');
>>
>>which seems to work on some browsers/systems but not others ...
>>
>>I want to over-ride the users cache settings but am not sure how this
>>can be best achieved in respect of POST data
>>
>>any help greatly appreciated.[/color]
>
>
> Hi brendan,
>
> I am not sure you can repair this.
> AFAIK some browsers tell the visitor that the page they see is a result of a
> posting (form). Which is a good thing, because it is the result of a
> posting.
> I am unsure if you can fix this by adding headers.. (hopefully for you
> somebody knows. :-)
>
> If you want to 'repair' this behaviour, you can add your own
> navigationbutto ns to the page and implement a decent post for 'back'-button
> behaviour. Allthough this is not always possible.
>
> And honestly I don't understand the security-implementations you have with
> GET that disappear by using POST.
> POST data is also send over the network, it just doesn't show up in the URL,
> but it is there.....
>
> If you want more security, use encryption. (https)
>
> just my 2 cents.
>
> Regards,
> Erwin Moller[/color]

Thanks Erwin,

the problem is that several string parameters are enrcypted using a
binary hash and this can result in some being longer than some of
browsers permissable GET string length. As there is no MIME control for
GET there I cant think of a workaround. Am I wrong on this one?

I am not sure that disabling browser buttons or using chromeless windows
would attract any less angst from users than the need to refresh.

your right about https: its just that our webserver uses some really
lame DN (ie https://www.yourreallysecurenow.com etc) and we want to keep
the product logo ... guess we could use frames ... but that causes
another set of problems when users refresh anything.

thanks for your response though ... its good to know Im not the only one
around.
cheers
brendan.

[Erwin Moller]

Re: HELP -> stop post data expiring?

brendan wrote:
[color=blue]
> Erwin Moller wrote:
>[color=green]
>> brendan wrote:
>>
>>[color=darkred]
>>>Sorry this isnt a cross post .. i just didnt get any help from alt.php.
>>>
>>>I have a website which utilises post forms for navigation in some areas.
>>> Problem is, when *some* users hit the BACK button the POSTDATA
>>>content has expired and they need to refresh the page then they get a
>>>alert about refreshing expired data.
>>>
>>>I am getting complaints that this is too annoying and limits the sites
>>>useability .
>>>
>>>For security reasons I cant swap post for get.
>>>
>>>the header content of the page is
>>>header('Expi res: '.gmdate('D, d M Y H:i:s', time() + 600) .'GMT');
>>>
>>>which seems to work on some browsers/systems but not others ...
>>>
>>>I want to over-ride the users cache settings but am not sure how this
>>>can be best achieved in respect of POST data
>>>
>>>any help greatly appreciated.[/color]
>>
>>
>> Hi brendan,
>>
>> I am not sure you can repair this.
>> AFAIK some browsers tell the visitor that the page they see is a result
>> of a posting (form). Which is a good thing, because it is the result of a
>> posting.
>> I am unsure if you can fix this by adding headers.. (hopefully for you
>> somebody knows. :-)
>>
>> If you want to 'repair' this behaviour, you can add your own
>> navigationbutto ns to the page and implement a decent post for
>> 'back'-button behaviour. Allthough this is not always possible.
>>
>> And honestly I don't understand the security-implementations you have
>> with GET that disappear by using POST.
>> POST data is also send over the network, it just doesn't show up in the
>> URL, but it is there.....
>>
>> If you want more security, use encryption. (https)
>>
>> just my 2 cents.
>>
>> Regards,
>> Erwin Moller[/color]
>
> Thanks Erwin,[/color]

Hi again,
[color=blue]
>
> the problem is that several string parameters are enrcypted using a
> binary hash and this can result in some being longer than some of
> browsers permissable GET string length.[/color]

Oh, is that still a problem?
I thought that was only a problem for (very old) webSERVERS.
In that case you should stick to POST indeed.
:-(
[color=blue]
> As there is no MIME control for
> GET there I cant think of a workaround. Am I wrong on this one?[/color]

Sorry, I wasn't aware that POST had MIME-control. I think of it as a bunch
of name/value pairs with a certain encoding, no MIME AFAIK.

Very well possible I am wrong on that one. :P
Maybe somebody who knows more about this can clarify this??
[color=blue]
>
> I am not sure that disabling browser buttons or using chromeless windows
> would attract any less angst from users than the need to refresh.[/color]

Hmm. ok.
If you get a response from a webserver after posting some formdata, it is
only logical that a browser warns you if you use your back-button. At least
that makes a lot of sense to me.

As a sidenote:
I think the problem is that many people using a browser (your customers) are
not aware of that, and don't have a clue what a posting is, don't have a
clue what 'expired' means, and above all: don't want to learn it either.
(Speaking from own experience).
So unless you can fix this browser-behaviour somehow, you should educate
your users that this is actually desired behaviour of an internetbrowser .
It is like somebody steps into a car for the first time in his life, starts
driving, and gets angry after he crashes because the gaspedal worked
differently than he 'expected'. He simply needs a driverlicence.

But that doesn't help you, does it? ;-)
[color=blue]
>
> your right about https: its just that our webserver uses some really
> lame DN (ie https://www.yourreallysecurenow.com etc) and we want to keep
> the product logo ... guess we could use frames ... but that causes
> another set of problems when users refresh anything.
>
> thanks for your response though ... its good to know Im not the only one
> around.
> cheers
> brendan.[/color]

If memory serves me well M$ Exploder has an option somewhere to disables
this question. (Not sure, using Mozilla right now.)

Sorry I cannot be of more help. :-/
I guess you have to dive into all kinds of extra headers to fix this.
And after that: test it on every major browser on all major OS's...

Good luck!
Regards,
Erwin Moller

[Kevin Thorpe]

Re: HELP -> stop post data expiring?

brendan wrote:[color=blue]
> Sorry this isnt a cross post .. i just didnt get any help from alt.php.
>
> I have a website which utilises post forms for navigation in some areas.
> Problem is, when *some* users hit the BACK button the POSTDATA content
> has expired and they need to refresh the page then they get a alert
> about refreshing expired data.
>
> I am getting complaints that this is too annoying and limits the sites
> useability.
>
> For security reasons I cant swap post for get.
>
> the header content of the page is
> header('Expires : '.gmdate('D, d M Y H:i:s', time() + 600) .'GMT');
>
> which seems to work on some browsers/systems but not others ...
>
> I want to over-ride the users cache settings but am not sure how this
> can be best achieved in respect of POST data
>
> any help greatly appreciated.
>[/color]

IIRC you can avoid this using redirects. The script which accepts the
posted data should process it (add to the database or such) and then
issue header('Locatio n: results.php'); which will ensure that there are
no pages in the browser cache relating to posted data.

[John Dunlop]

Re: HELP -> stop post data expiring?

Erwin Moller wrote:
[color=blue]
> If you get a response from a webserver after posting some formdata, it is
> only logical that a browser warns you if you use your back-button. At least
> that makes a lot of sense to me.[/color]

Will you explain why, please?

--
Jock

[Jeff Rodriguez]

Re: HELP -> stop post data expiring?

brendan wrote:[color=blue]
> Sorry this isnt a cross post .. i just didnt get any help from alt.php.
>
> I have a website which utilises post forms for navigation in some areas.
> Problem is, when *some* users hit the BACK button the POSTDATA content
> has expired and they need to refresh the page then they get a alert
> about refreshing expired data.
>
> I am getting complaints that this is too annoying and limits the sites
> useability.
>
> For security reasons I cant swap post for get.
>
> the header content of the page is
> header('Expires : '.gmdate('D, d M Y H:i:s', time() + 600) .'GMT');
>
> which seems to work on some browsers/systems but not others ...
>
> I want to over-ride the users cache settings but am not sure how this
> can be best achieved in respect of POST data
>
> any help greatly appreciated.
>
>[/color]
Good lord, everyone else posting in here is making it way too hard :)

It has to do with your caching. Check out your php.ini for an option called
"session.cache_ limiter", try setting that to "private" instead of the default
"nocache". Note that there ARE however quirks which I'm sure you'll experience
and decide that it's not worth it. For example, users may not end up getting the
latest version of the page because they're caching it. Trying to distribute the
idea to "Push CTRL+F5" to every Joe Average isn't worth "fixing" a quirk for
just a couple of users.

I don't know, if you tweak with the expiry date /and/ the cache limiter you
might be able to achieve the desired effect. By the way, expiry date can be
managed by "session.cache_ expire" which defaults to 180 minutes.

_Excerpt from my php.ini_
; Set to {nocache,privat e,public,} to determine HTTP caching aspects
; or leave this empty to avoid sending anti-caching headers.
;session.cache_ limiter = nocache

; Document expires after n minutes.
session.cache_e xpire = 180

Jeff

[Tim Van Wassenhove]

Re: HELP -> stop post data expiring?

In article <c828df$67j$1@p egasus.csx.cam. ac.uk>, brendan wrote:[color=blue]
> Sorry this isnt a cross post .. i just didnt get any help from alt.php.
>
> I have a website which utilises post forms for navigation in some areas.
> Problem is, when *some* users hit the BACK button the POSTDATA
> content has expired and they need to refresh the page then they get a
> alert about refreshing expired data.[/color]

And that alert should be there.


But you could add hidden field to you form that contains
<input type="hidden" name="lastupdat e" value="timestam p last update" />

And then also save the current time when you update the data in your
database.


Each time when the form is submitted, you can compare the value of lastupdate in
the hidden field with the timestamp in the database. If they are not
equal, the client was working with invalid data, and you should return
him a error message and the new data....


--

http://home.mysth.be/~timvw

[Erwin Moller]

Re: HELP -&gt; stop post data expiring?

John Dunlop wrote:
[color=blue]
> Erwin Moller wrote:
>[color=green]
>> If you get a response from a webserver after posting some formdata, it is
>> only logical that a browser warns you if you use your back-button. At
>> least that makes a lot of sense to me.[/color]
>
> Will you explain why, please?
>[/color]

Hi John,

Why I think that is logical?
Because the resulting response is based on the actions of a script that
received certain data (by the POST).
If that data changes, the response could also very well change, hence the
warning.
It is not carved in stone, but it makes sense to me.

What doesn't make sense to me is this:
A script might very well respond to the content encoded in the GET... but in
that case we don't get the warning.

Actually, I am not at all convinced I understand this behaviour. :-)
Can somebody explain this?
Why do we get a warning if we use the back-button for a page that was based
on a POST and not for a GET?

Regards,
Erwin Moller

[Tim Van Wassenhove]

Re: HELP -&gt; stop post data expiring?

In article <40a5f3a2$0$559 $e4fe514c@news. xs4all.nl>, Erwin Moller wrote:[color=blue]
> John Dunlop wrote:
>[color=green]
>> Erwin Moller wrote:
>>[color=darkred]
>>> If you get a response from a webserver after posting some formdata, it is
>>> only logical that a browser warns you if you use your back-button. At
>>> least that makes a lot of sense to me.[/color]
>>
>> Will you explain why, please?
>>[/color]
>
> Hi John,
>
> Why I think that is logical?
> Because the resulting response is based on the actions of a script that
> received certain data (by the POST).
> If that data changes, the response could also very well change, hence the
> warning.
> It is not carved in stone, but it makes sense to me.
>
> What doesn't make sense to me is this:
> A script might very well respond to the content encoded in the GET... but in
> that case we don't get the warning.
>
> Actually, I am not at all convinced I understand this behaviour. :-)
> Can somebody explain this?
> Why do we get a warning if we use the back-button for a page that was based
> on a POST and not for a GET?[/color]

The differences between POST and GET can be found in the relevant rfc's
on HTTP.

In short: each time you request data with a GET, the server should
return the same data each time. With a POST, the server will return
different data each time.


--

http://home.mysth.be/~timvw

[John Dunlop]

Re: HELP -&gt; stop post data expiring?

Erwin Moller wrote:
[color=blue]
> Because the resulting response is based on the actions of a script that
> received certain data (by the POST).
> If that data changes, the response could also very well change, hence the
> warning.[/color]

Now I've had time and have read the entire thread, I think I've
cottoned on. I had thought the discussion was about the browser's
behaviour upon the user moving backwards, not what happens when a
request is sent. Thanks for the clarification.

--
Jock

[Erwin Moller]

Re: HELP -&gt; stop post data expiring?

Tim Van Wassenhove wrote:
[color=blue]
> Erwin wrote:[color=green]
>>
>> Actually, I am not at all convinced I understand this behaviour. :-)
>> Can somebody explain this?
>> Why do we get a warning if we use the back-button for a page that was
>> based on a POST and not for a GET?[/color][/color]

Hi Tim,

Thanks for your response.
[color=blue]
>
> The differences between POST and GET can be found in the relevant rfc's
> on HTTP.[/color]

As usual. :-)
Why are them rfc's always so hard to read?
[color=blue]
>
> In short: each time you request data with a GET, the server should
> return the same data each time. With a POST, the server will return
> different data each time.[/color]

Tim, is it safe to conclude that the authors of the rfc's describing GET and
POST didn't expect a GET to have a bunch of encoded name/value pairs in it?
Is it like they expected you to use a POST for that?

(If that is the case I think I understand the difference in behaviour,
finally.)

Regards,
Erwin Moller
[color=blue]
>[/color]