(/me cleans out the growing Cc: field and mutters [again] his
counter-culture preference regarding Reply-to and lists)
Use CGI::Session, this deals with session management and random IDs
But how would you use this to ensure a form hadn't been submitted twice,
in the case where a client could
Sounds cool, do you use cookies for that?
Nope, I have an irrational dislike of cookies. I just drop it in as a
hidden field to the form. Of course, this requires that your form be
generated dynamically as opposed to being flat HTML.
Of course, this still has a 1 in a (my pseudorandom
I am using PostgreSQL too, it's great DBMS!
Thanks for your comments guys!
best regards,
JJ
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
At 03:59 PM 06/13/2002, Brett Sanger wrote:
Another way to handle this is to have a two-part submission. The
first form creates a recrod in the database, but somehow marks it
as unconfirmed. You then return a confirmation form with the key for
I listed my objections to this earlier: it
On Thu, 13 Jun 2002, Juan Jose Natera Abreu wrote:
Hi guys!
I guess most of you have experienced the problem of duplicated
submissions due reload button I have seen some protections against it
on the web, and I would like to implement it on my apps.
My first thought is to compare the
In the case where the form is being used to insert some data into a
database, here's an easy trick that I like to use:
In the form display run mode, select the next available unique ID for
the item that will be it's primay key. When you submit the form, you
simply have to check to see if
On Thu, 13 Jun 2002, Brett Sanger wrote:
In the form display run mode, select the next available unique ID for
the item that will be it's primay key. When you submit the form, you
simply have to check to see if you've already inserted something with
the same ID (which your database may
Postgres handles this gracefully with it's SEQUENCES feature. After
user1 calls up the form, user2 will be returned ID 12 rather than 11. So
there's no possible conflict like that.
Okay. I'm just starting to play with with Postgres, so here are a few
questions (that presumably will have some
