Re: [cgiapp] [OFF-TOPIC] Expiring Forms
(/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 fill it out twice identically? (frex: ordering a book online. Shopper might want the same book on two different occasions. Or s/he might have bounced on the process order button out of impatience and/or by accident. I haven't used CGI::Session (don't require session management yet), so if it has options directly applicable to this, I don't know them. - Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] [OFF-TOPIC] Expiring Forms
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 range) of failure, but I consider that worth removing faulty double submissions. I use the String::Random Module to generate a 32-Byte alphanumeric string for the Session IDs, and have a cron job running to delete sessions older than 1/2 an hour. (and presumably you check to ensure used sessionIDs aren't taken) Well, if you have stick an equally random field in your form, and check on submission to see if that user submitted a form with that value within the last 30 minutes, I think you're pretty safe about collisions, particularly if you are nice to detected collisions (bounce them to a new confirmation page). - Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] [OFF-TOPIC] Expiring Forms
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, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] [OFF-TOPIC] Expiring Forms
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 clutters up the database with unfinished unconfirmed entries. This may or may not be acceptable. In the case where the potential problem in the first case _is_ a problem, this is almost certainly the way to go. Likewise, if you have a problem with abandoned unconfirmed entries, go with the first solution. (OTOH, Marketing people _like_ the unconfirmed entries, because it gives them data about people who show some level of interest but are unwilling to commit. One way to mark something as unconfirmed is to place it in an unconfirmed table, and then the confirmation moves it to a confirmed table. This prevents the problem with gaps in the key sequence in the confirmed table. It does require that you clean out old entries, but this is the only method I have come up with that meets the requirements of: absolutely no unintentional duplicate submissions, absolutely no lost submissions due to the duplicate submission checks, absolutely no gaps in the key sequence of accepted submissions. -- Greg Marr [EMAIL PROTECTED] We thought you were dead. I was, but I'm better now. - Sheridan, The Summoning - Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] [OFF-TOPIC] Expiring Forms
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 values being submitted with those in the database, if they are exactly the same then abort the action... 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 you've already inserted something with the same ID (which your database may actually prevent you from doing anyway). -mark http://mark.stosberg.com/ - Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] [OFF-TOPIC] Expiring Forms
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 you've already inserted something with the same ID (which your database may actually prevent you from doing anyway). Doesn't that fail messily if you have concurrent submissions? user1 calls up form to submit, it sees that the DB has IDs 1-10 filled, so drops ID-11 in the form. user2 calls up form to submit, it sees that the DB has IDs 1-10 filled, so it drops ID-11 in the form. user1 submits, taking slot 11. user2 submits, get bounced because id-11 is used. Unless you mean that you put in a blank holding item in the database, which means you're doing an insert on an otherwise informational page (plus you have to worry aobut treating NOT NULL and UNIQUE fields correctly). Seems that would clutter your db with bad entries when users don't commit to actually submitting their forms. Unless your db supports a next_available() routine that doesn't clog the database and doesn't return the same value twice. What would the timeout on that be? - Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] [OFF-TOPIC] Expiring Forms
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 actually prevent you from doing anyway). Doesn't that fail messily if you have concurrent submissions? user1 calls up form to submit, it sees that the DB has IDs 1-10 filled, so drops ID-11 in the form. user2 calls up form to submit, it sees that the DB has IDs 1-10 filled, so it drops ID-11 in the form. user1 submits, taking slot 11. user2 submits, get bounced because id-11 is used. 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. Unless you mean that you put in a blank holding item in the database, which means you're doing an insert on an otherwise informational page (plus you have to worry aobut treating NOT NULL and UNIQUE fields correctly). Seems that would clutter your db with bad entries when users don't commit to actually submitting their forms. No, there are just some gaps in the unique ID sequence, which is fine with me. (and would happen anyway later when some items got deleted). Brett's idea about using a bit of random data also seemed reasonable for a general case. -mark http://mark.stosberg.com/ - Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] [OFF-TOPIC] Expiring Forms
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 value regarding the original question): -Does this work on a per-connection basis (i.e. it'd require mod_perl), or database-wide (CGI is fine) -I'm assuming nothing is freed, so once the sequence hits it's end, that's it? (which, granted, could be 30 years) No, there are just some gaps in the unique ID sequence, which is fine with me. (and would happen anyway later when some items got deleted). Brett's idea about using a bit of random data also seemed reasonable for a general case. I like the idea of combining them. The random data idea has two parts: the value has no use except to check for duplicate submissions, and it shouldn't repeat in the db. The problem is that there is a small chance it will repeat. The sequence works fine, but I'm inclined to dislike anything that further fragments my primary key data and shortens the time until my idspace runs out. I know MySQL supports a serial type that can be told to cycle back to 1 when it runs out, I'm sure the other databases do. If you have a submission_check sequence that does just as Mark suggested, but uses this value rather than the ID to check: -You will know about duplicate submissions -There will be no key duplication unless you experience more than submission_check sequences within your warning_window, and you can easily set that to an acceptable risk. -Your primary key space is not depleted. - Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
