When you emit the page that you don't want people to back into, include   Cache-control: no-cache in the header.

Also, when you're printing your header with CGI, you can use:

print $query->header ( ....
                             expires => 'now' );
[download]

Great suggestion, The page that is causing the problems is an HTML that is simply dumped into main. The issue comes when submit values on that page are mixed with values that are sent to the Perl Script Driving the interface after the back action. I think putting this line in the header of the template used to create these pages just might do the trick...THANKS SO MUCH!

TexasTess
"Great Spirits Often Encounter Violent Opposition From Mediocre Minds" --Albert Einstein

Your options:

• Use a session based system. Keep track of the last page each session was on. And then:
  • Encode both the source and destination in your URLS. If the source is wrong, you know something happened, or:
  • Keep a list of pages that may be accessed by each page. When somebody requests a page, make sure that it is valid from the last visited page.
• Encode a unique request ID with every page you server. If you see the same request ID twice, you know somebody made two requests from the same page. Or encode a unique key in your URLs such that each URL is only valid once.

UPDATE I guess this was post #200 for me. I thought I was going to come up with something meaningful for this special number, but I guess I'll wait till 250 now...

I should have been more specific. I have local anchor tags in an html file that are dumped into main by the CGI script. These tags are dynamically created and link to each entry that has been made on the page. There is also an action button if a user wants to add an entry. If they click a "link" to jump to an entry, then use the back button to go back to the top of the page..then click the link to jump to a different entry...the button for adding an entry is activated and the add an entry form is presented.
update: I would like to know how to either stop them from using the back button to get back to the top of the page...or stop the second click from activating the call to the add entry form..

TexasTess
"Great Spirits Often Encounter Violent Opposition From Mediocre Minds" --Albert Einstein

So if they click on link #1, click back, and then click on link #2, they are not being sent where #2 should have sent them? Sounds more like a bug than a design issue.

Update: Oh. Ok... I suppose that line about the back button implies a question of sorts.

One way to get around this sort of thing is to have a sequence number submitted with each request. If the CGI gets the a number less than the one it is expecting, it doesn't modify the user's state. This doesn't work for all situations. It won't work if the user wants to go back to the last form change something and resubmit, for instance. For that functionality, you could provide your own way to get back and forth between form and warn the user when they navigate via other methods. A savvy user might also easily foil this if they tried. You should consider the implications of that possibility.

-sauoq
"My two cents aren't worth a dime.";

--MrNobo1024
s]]HrLfbfe|EbBibmv]e|s}w}ciZx^RYhL}e^print