CODEWITHSUNDEEP
http-post
mkoryak
mkoryak

Reputation: 57968

show "webpage has expired" on back button

What is the requirement for the browser to show the ubiquitous "this page has expired" message when the user hits the back button?

What are some user-friendly ways to prevent the user from using the back button in a webapp?

Upvotes: 12

Views: 37952

Answers (5)

shehzad
shehzad

Reputation: 11

use one of the following before session_start:

session_cache_expire(60); // in minutes 

ini_set('session.cache_limiter', 'private');

/Note:

Language is PHP

Upvotes: 1

Jeremy
Jeremy

Reputation: 21

Try using the following code in the Page_Load

Response.Cache.SetCacheability(HttpCacheability.Private)

Upvotes: 2

Chase Seibert
Chase Seibert

Reputation: 15851

I'm not sure if this is standard practice, but I typically solve this issue by not sending a Vary header for IE only. In Apache, you can put the following in httpd.conf:

BrowserMatch MSIE force-no-vary

According to the RFC:

The Vary field value indicates the set of request-header fields that fully determines, while the response is fresh, whether a cache is permitted to use the response to reply to a subsequent request without revalidation.

The practical effect is that when you go "back" to a POST, IE simply gets the page from the history cache. No request at all goes to the server side. I can see this clearly in HTTPWatch.

I would be interested to hear potential bad side-effects of this approach.

Upvotes: 0

Steve Wortham
Steve Wortham

Reputation: 22240

Well, by default whenever you're dealing with a form POST, and then the user hits back and then refresh then they'll see the message indicating that the browser is resubmitting data. But if the page is set to expire immediately then they won't even have to hit refresh and they'll see the page has expired message when they hit back.

To avoid both messages there are a couple things to try:

1) Use a form GET instead. It depends on what you're doing but this isn't always a good solution as there are still size restrictions on a GET request. And the information is passed along in the querystring which isn't the most secure of options.

-- or --

2) Perform a server-side redirect to a different page after the form POST.

Looks like a similar question was answered here:

Redirect with a 303 after POST to avoid "Webpage has expired": Will it work if there are more bytes than a GET request can handle?

As a third option one could prevent a user from going back in their browser at all. The only time I've felt a need to do this was to prevent them from doing something stupid such as paying twice. Although there are better server-side methods to handle that. If your site uses sessions then you can prevent them from paying twice by first disabling cache on the checkout page and setting it expire immediately. And then you can utilize a flag of some sort stored in a session which will actually change the behavior of the page if you go back to it.

Upvotes: 11

dusoft
dusoft

Reputation: 11469

you need to set pragma-cache control option in HTTP headers: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9

However, from the usability point of view, this is discouraged approach to the matter. I strongly encourage you to look for other options.

ps: as proposed by Steve, redirection via GET is the proper way (or check page movement with JS).

Upvotes: 2

Related Questions