in reply to Page expiration with unsynchronized clocks

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!

  • Comment on WHAT?!? No "back" button?? I just gotta hear the reason for this one...

Replies are listed 'Best First'.
Re: WHAT?!? No "back" button?? I just gotta hear the reason for this one...
by zakzebrowski (Curate) on Aug 07, 2001 at 19:33 UTC
    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
[reply]
      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

[reply]
        Absolutely correct... the hard problem here, however, is controling the way we increment the database variable..... (For this project, we are not using perl, (sigh), rather a different, poorer, language.) We are intending to eventually do this, but for now, the -1 trick works. The trick to getting the cache to expire on netscrape and internet exploder is putting the variables (no cache, pragma, and expires) in the right place and in the right order...

        ----
        Zak
[reply]

In Section Seekers of Perl Wisdom