However, while this will work, as the amount of data entered increases, it is probably better to save the state of the data in files or databases on your end, using a unique session id that you then pass to further URLs, and upon completion of the last page, actually transferring all that data from files or databased into the final storage location that it will be stored in. This will be less prone to security faults as well, since only one state item (the session id) is passed.

This post reminds me of a problem I am currently experiencing. . . If the state of the data is stored in a database, for example, and we pass around a session ID, how do we keep our database from becoming cluttered? How and when do we clean up the data left behind by no-longer used sessions? I imagine schedule a task to delete unused sessions, but by what criteria? Do we update the session timestamp every time a user performs and action, and delete only those sessions that haven't been touched in, for example, 30 minutes?

Just curious ;) Thanks!

MrCromeDome

You pretty much have the right idea. What you need to do if you go this route is have a sample selection of your users estimate the time it took to fill out the forms, and take a reasonable average and triple it. So if took the average user 15 minutes to do it, don't delete the entry for at least 45 minutes. Make sure to test this with remote users from a variety of connection types, and with users that have not filled out that form before, so that you get a good average. Of course, this time also could be a factor as determined by how many hits you get; if you expect that only one person a day will fill out a form, you probably can clear the database on a weekly basis. If, on the other hand, you get 100 people a minute filling the form, then yes, you want to minimize the time between database clearing.

---

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

Another method of cleaning out old entries is to do so every time you enter a new entry. (I use this a lot with shopping carts and the like.) Make sure every row in the table has a timestamp for when it was created and modified, then have a single DELETE statement remove all entries before a cutoff date. (half a day, 1 week, etc.)

-franknmonk

Thanks.

I toyed with the database idea last week but was missing the crucial piece of the puzzle you mentioned: having a unique session ID.

I think I'm going to need to purchase another O'Reilly book on this topic and get much more familiar with this topic.

$PM = "Perl Monk's";
$MCF = "Most Clueless Friar";
$nysus = $PM . $MCF;

As merlyn has pointed out in the past, you can use the following code to generate a unique session_id. If you are going to use it for generating a file to save the CGI object in, be sure to use Taint checks.

use MD5;

sub generate_id {
    return substr(MD5->hexhash(time(). {}. rand(). $$. 'blah'), 0, 16)
+;
}
[download]



You may find this recent discussion relevant.

-Lee

"To be civilized is to deny one's nature."

Jeff

R-R-R--R-R-R--R-R-R--R-R-R--R-R-R--
L-L--L-L--L-L--L-L--L-L--L-L--L-L--

Zenon Zabinski | zdog | zdog7@hotmail.com

Is this the best way to handle this? What if cookies are turned off?

$PM = "Perl Monk's";
$MCF = "Most Clueless Friar";
$nysus = $PM . $MCF;

Or you can pass the parameters from the previous form to the next form. You can set the parameters by using the param() routine similarly to this:

$q->param(-name=>'veggie',-value=>'tomato');

Update: My bad. You can pass the parameters to the next form by using the hidden input method. (See reply.)

Zenon Zabinski | zdog | zdog7@hotmail.com