> One thing I've done in the past is write all of the form fields to a > WDDX packet and pass that as a hidden form field instead of a client > variable. No database access at all.

Isn't there a possibility that a user can create a form almost the same as yours but changes some values in your hidden field?

One of the main things I'm worried about is the possibility that a user can somehow change values in my form, creating a possible security hazard :-)

With kind regards, Erik Schaareman

----- Original Message ----- From: "Steve Nelson" <m@secretagents.com> To: "Fusebox" <Fusebox@houseoffusion.com> Sent: Friday, May 04, 2001 02:27 Subject: Re: Managing program flow

> I think it's actually more elegant. Nothing is written to the server > until it's finalized. > > One thing I've done in the past is write all of the form fields to a > WDDX packet and pass that as a hidden form field instead of a client > variable. No database access at all. > > Then you can have multiple page forms and only pass a single variable > from page to page. It makes the variable passing very easy. Then when > the user is finished, save it all to the db. This takes load off of your > server and more importantly it doesn't leave a lot of dangling data. > > Steve Nelson > > Erik Voldengen wrote: > > > > Back in the old days, I just populated all previous form field values > > into hidden form variables of the next form. > > > > For example, step one took name, address. Step 2 (another fuse) > > checked for those values, put them in hidden form variables (there > > is a nice custom tag in the dev-x for this), and took all step 2 > > information. Step three, again, populated all existing form variables > > into hidden fields, and took further info....etc etc etc. > > > > I did it to avoid using session variables, and to avoid making a write > > to the DB until the user actually committed to the purchase by entering > > their cc number. It seemed to work pretty good, and has been for a > > couple years. > > > > Not the most elegant, but I wonder if this approach is any less/more > > expensive than writting client variables to do the job. I would say > > less. Hmmm. > > > > -Erik > > > > > -----Original Message----- > > > From: McCollough, Alan [mailto:amccollough@anmc.org] > > > Sent: Thursday, May 03, 2001 9:15 AM > > > To: Fusebox > > > Subject: RE: RE: Managing program flow > > > > > > > > > I was installing a 3rd party web-based app, and lacked the > > > serial number. We > > > had the number, however, it was buried somewhere in a mound > > > of paperwork. > > > > > > The package installed via the web, using a step variable. I > > > was able to > > > overcome the lack of a registration number by simply manually > > > incrementing > > > the step variable in the URL! > > > > > > sOoOoO, you do need to be careful on how you use those step > > > vars. You'll > > > still need another way of determining if User Joe Shmoe is where they > > > belong... > > > -----Original Message----- From: Hans Omli [SMTP:list@redmondstudios.com] Sent: Wednesday, May 02, 2001 4:12 PM To: Fusebox Subject: RE: RE: Managing program flow > > > > I store all submitted form variables in a client variable > > > (using wddx). Then on each template I check that the client variable > > > includes all form variables that should have been entered thus far, and send > > > the user back if not. > > > > A step variable would obviously be a more simple solution. > > > So, now I'm considering whether I'd have any security concerns with > > > step variables. Thoughts? > > > > Hans > > > > -----Original Message----- From: Jim Stahlin [mailto:jstahlin@ezh.com] Sent: Wednesday, May 02, 2001 4:13 PM To: Fusebox Subject: Re: RE: Managing program flow > > > > > > > > I agree that you have this problem in non-CF sites. But > > > the program flow is much more apparent in a Fusebox site than in other sites. > > > I restricted access using session variables and am in the process of > > > converting the site to fusebox. Other than using a step variable does anyone > > > know of another way to do this? > > > > >>> nat@webthugs.com 05/02/01 18:06 PM >>> Couldn't they do that in a non-CF site too? > > > > What you're talking about sounds to me like a regular > > > programming process problem. You could set a client variable on each page with the step number, and send bad users to the right page. > > > > NAT > > > > > -----Original Message----- > From: Jim Stahlin [mailto:jstahlin@ezh.com] > Sent: Wednesday, May 02, 2001 1:50 PM > To: Fusebox > Subject: Managing program flow > > > I have a problem in getting my mind around how you can restrict > the flow of actions in fusebox. I have a site that in the > checkout process requires the user to pick shipping method, then > Credit Card info, then Shipping info, then approve the order. If > I use Fuseactions to do this the user could pass the last > fuseaction in the URL variable and skip all the entry screens. > > Archives: http://www.mail-archive.com/fusebox@houseoffusion.com/ > Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=sts > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm

Archives: http://www.mail-archive.com/fusebox@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists