zakzebrowski has asked for the wisdom of the Perl Monks concerning the following question:

Hi.

In an attempt to prevent users from using the "back" button, I use pragma, cache control and expires html directives. I have it working both for my machine and my other friends machine, whose clocks are closely syncronized together. However, I also use a lab computer. This lab computer's clock is not closely syncronized to the server, and as a result, the expiration does not work as it should. The expiry comand is: http-eqiv="expires" content="-1".

Anyone have any clue what is going on, or how I can fix what is going on? (I know this post is slightly off topic from perl, but the w3c site is unacessiable from work today... damn red alert.)
Thanks

----
Zak
  • Comment on Page expiration with unsynchronized clocks

Replies are listed 'Best First'.
WHAT?!? No "back" button?? I just gotta hear the reason for this one...
by dragonchild (Archbishop) on Aug 07, 2001 at 19:19 UTC
    My first reaction is one of horror. What on earth could possess you to attempt to violate one of the primary rules of WWW design?!? The "back" button is probably the most clicked button in any browser! Part of the compact that the WWW has with its users is that you can always return to where you came from. If you want your site to be the most popular one in the playground, I would very strenuously urge you to redesign in some fashion. If you MUST simulate some sort of one-way state machine, then don't use HTML/CGI to do so. Write it in Java.

    As for your issue, you seem to have given the solution on your own. Just synchronize the server and the lab computer (which should be done anyways) and you'll be just fine. (Of course, that's assuming you've presented the problem in its entirety...)

    ------
    /me wants to be the brightest bulb in the chandelier!

    Vote paco for President!

      Well, this is special case handeling. If a person edits a form, submits it, then they should not be able to use the back button to resubmit because it will violate database contraints... (And yes, we could have a script that would catch the relativeness of where the form is currently based on time or an incremental number, but that's not going to be done by tomorrow when we ship.)

      ----
      Zak
        There's a much better way that is less falliable to problems/hacking on the user's end: include a uniqueid in a hidden field on the form, and sort a list of these uniqueid's in a second table when they are created. Upon submission of a form, remove that unique id from the table if it's there and process the form normally, otherwise, tell the user they've already submitted their data and move on elsewhere.

        You can sufficently munge data into this uniqueid such as the localtime on your server, user id, random numbers, etc, if you want to reduce the chance of someone faking a request to your server.

        -----------------------------------------------------
        Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain

Re: Page expiration with unsynchronized clocks
by c-era (Curate) on Aug 07, 2001 at 19:18 UTC
    Use a meta tag with javascript. That will set the time based on the user's computer instead of the server's time.