in reply to CGI Refresh question

Make the hidden parameter the timestamp when the web page was generated. Have an empty, web-writable file for each button on the page. When you get a button push, compare the hidden field to the timestamp on that button's file. If the time stamp is between that timestamp and "now", then honor the request and "touch" that button's file (update the file's timestamp). If the timestamp is too old, don't honor the request and respond saying that that resource was recently change so their change was ignored. If the timestamp is in the future, complain and "do something appropriate".

Note that this also has the benefit of preventing me from updating an item that my web page says should be updated but that Adam update while I was looking at my page. This is probably a good thing.

Replies are listed 'Best First'.
RE: Re: CGI Refresh question
by atl (Pilgrim) on Jul 25, 2000 at 16:32 UTC
    Hang on, thereīs a trap you might fall into. Donīt forget, that multiple users might call the same cgi at the same time! That will mess up your time stamp files!

    To make things worse, since HTTP is stateless, you have to write a complete session management yourself if you need one (can be done with the hidden fields mentioned, among others). The initial description suggests (at least to me) that you need such a "session concept".

    Andreas

[reply]

      Yes, there is a race condition where multiple clients can reset the same counter in rapid succession and both succeed. However, this race doesn't affect the requested purpose, that is, people will not be allowed to reset a count by doing a refresh/reload of a page. That is mostly why I didn't mention the race condition originally.

      A more important flaw (to my eye), is that the solution doesn't distinguish between refusing my reset request because someone else beat me to it or because I resent a stale POST.

      The "right" way to remove the race condition is to lock the timestamp file across the test and set. However, that wouldn't fix the bigger flaw. My subconscious has been wondering if there was a (fairly) simple trick for solving both problems (like append the process ID/thread ID/client address&port to the time stamp file, check if you were first, etc.). This type of problem often looks simple but usually isn't. Anyway, I never came up with one.

      So lock the file, check the file's last modified time, and then either rewrite it with a unique ID that you also include hidden in each form or read the ID to determine which error to report, then unlock the file.

[reply]

In Section Seekers of Perl Wisdom