Re: Prevent Browser From Going Back

Joe,

The HTTP headers I sent you will go a long way to fixing this but there
may still be a problem. If you are passing all of the data from page to
page, someone can refresh the browser and still see the values.

When I did our B2B eCommerce site, the add to cart links had a similar
problem -- you could refresh the page and it would keep adding the same
item to the shopping cart. The way that I fixed this was by making the
add to cart process work in two stages and passing in a value that the
program looked for to allow it to add items. Here's the simplified
version of how it works:

- A request comes in (either a GET or POST) with the name/value pair of
op=add (you can use anything you want, this is just what I used). If
this name/value pair is not passed in, the CGI program will display the
contents of the shopping cart.
- The passed in items are added to the shopping cart which is a regular
physical file.
- The CGI program sends back HTTP headers that make it redirect back to
itself. This redirection keeps the browser from storing the information
used to add items in it's history.
- Since I don't include the name/value pair op=add when I redirect, the
contents of the cart are displayed.

Here are the headers that I use to do the redirection:

Location: shopcart.pgm
Status: 301

The Location header should have the name of your CGI program in it. You
can also pass additional name/value pairs and/or specify full URL's if
you need to. Note that you will need to URL encode the values on your
name value pairs. The Status header is result of the request. Normally,
it comes back with 200 which means success. 301 means moved permanently
which is what keeps the original request from being stored by the
browser. Also, when you send these headers back, these are the only ones
you should send. Sending back anything else will cause unpredictable
results.

You can find more information about HTTP status' at
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html and the HTTP
headers at http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html.

My order form program works in the same way but it also checks to see if
the shopping cart is empty or not. If it's empty, it doesn't display
anything other than a message saying it's empty regardless of what was
passed in. I also store last updated timestamps in my shopping related
files so I can clean up old records easily.

Another approach is to use sessions. It's a bit more work in RPG than
Java but it can be done without too much trouble. Basically, what you'd
do is this:
- At the start of a transaction, you generate a session id. I use UUID's
for this but you can use any unique id you want.
- Store the session id in a cookie or a form field AND store it locally
(as in on the server) with an expiration time stamp (30 minutes is
usually a good value). If you store the session in a cookie, make sure
to use a session cookie so it goes away when the browser is closed. If
you've never used cookies before, you set them by adding another HTTP
header to the response you write and you get the value from the
HTTP_COOKIE environment variable. The Easy/400 site has code available
for working with cookies and I would guess that Brad Stone's and Bob
Cozzi's tools do as well.
- On every request, check that the session id exists locally and that
it's not expired. If either of these checks fail, you can do something
to let the user know. If they didn't fail, you'll want to update the
expiration time.
- When a transaction completes, remove the session id from your local
store.

You can also use this technique to do forms based authentication.

Here's the prototype for generating a UUID:

DGenUUID          PR                  extpgm('GENUUID')
D UUID                          32

To comment on the JavaScript example below, this is probably a bad idea
for a couple of reasons. First, all you have to do is turn off
JavaScript and it doesn't work. Second, if you need to redisplay the
page to the user (like if they enter a bad credit card number or some
other validation error happens), it will blow away those form values
which will annoy your users.

Matt

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]
On Behalf Of Joe Giusto II
Sent: Thursday, January 26, 2006 7:15 PM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Prevent Browser From Going Back

RPG.  I carry the order number from page to page and use that to make
sure that
an order is not submitted twice.  this is an internal web site used only
by
employees.  the main thing they do not want is for people to be able to
hit the
back button after the order has completed to see the customer's credit
card
number in case the employee using the browser does not close it after
the order
has been completed.  what I have done for now is prevent them from going
back to
that page at all and placed an edit button on the payment confirmation
screen
that will take them back to the credit card entry screen if changes are
needed
before submitting the order.

----- Original Message ----- 
From: "Sarah Poger Gladstone" <listmember@xxxxxxxxxxxxxx>
To: "Web Enabling the AS400 / iSeries" <web400@xxxxxxxxxxxx>
Sent: Thursday, January 26, 2006 9:40 AM
Subject: Re: [WEB400] Prevent Browser From Going Back


Joe-

What server-side language are you using to handle the order? Assuming
you have some sort of session tied to the user, you can place
"orderstatus" and a "requested_action" variables in the session. Then
no matter what page the user is on ( and no matter how they got there
ie using the back button) your server side program can validate that
the "requested_action" is appropriate based on the current
"orderstatus"

HTH,
Sarah


On 1/25/06, Jeffrey Lee <jeff@xxxxxxxxxxx> wrote:
> On the page that you do not want them to go back to you could put an
onload
> event that would set the value of all of the fields.
>
> < body onLoad="return empty()" >
> <!--
> <!--
> function empty()
> {
>
> document.CCForm.CCNumber.value=""
> document.CCForm.CCExDate.value=""
>
> return true
> }
> //-->
> // -->
>