Hi,
Well Erik It is Absoloutely going cause security hazards if you are using
hidden varables in your page.
Conside this, for example you store price of a product as a hidden
variable. Now if the users saves the page to his system and reduces the
price and then submits the page you will never know that the price is
correct or incorrect as there will be no cross check with the price in the
database.
A better approach for such a database less site would be to use xml files to
store the data on the server side and only accessible to your application
not the end user. you can then write custom templates or tags to crosscheck
the data if the need be.
Regards,
Amit Talwar
Intellikaps
-----Original Message-----
From: Erik Schaareman [mailto:[EMAIL PROTECTED]]
Sent: Sunday, May 06, 2001 6:14 PM
To: Fusebox
Subject: Re: Managing program flow
Hi,
> 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" <[EMAIL PROTECTED]>
To: "Fusebox" <[EMAIL PROTECTED]>
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:[EMAIL PROTECTED]]
> > > 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:[EMAIL PROTECTED]]
> > > > 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:[EMAIL PROTECTED]]
> > > > 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?
> > > >
> > > > >>> [EMAIL PROTECTED] 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:[EMAIL PROTECTED]]
> > > > > 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/[email protected]/
> > > > > 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/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
