you know... a couple years back when Robi and I threw the first CF conference in Colorado we gave out a plaque for "the biggest bonehead" to a guy who accidentally posted his credit card number to the cf-talk list. He said as soon as he read his posting he ran to the phone and canceled his card within about 45 seconds! hehe Steve Hal Helms wrote: > > Yep. Good point, Steve. > > I think we should have an annual award for "Outstanding Accomplishment in > Coming Up with a Truly Lame Idea". And though it may seem immodest to do so, > I nominate myself for this prestigious, first-ever award. > > -----Original Message----- > From: Steve Nelson [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 09, 2000 7:13 AM > To: Fusebox > Subject: Re: Idea? > > I think the real problem with using request scope variables for > everything (other than not having ANY local attributes) is that your > user could do harmful things like changing the datasource of your > queries, or a really scary one is the account of a bank that credit card > transactions go to. > > i.e. if all form and URL variables were request you could call this URL: > http://www.domain.com/index.cfm?maindsn=otherdsn&account=123456 > > <cfquery name="myquery" datasource="#request.maindsn#"> > ... > </cfquery> > > or > > <!---- credit card transaction ----> > <cf_authorizenet > account="#request.account#" > ....> > > You want some variables available to the end user (i.e. through URL, > form or cookies), but you want other variables only available to the > programmer. > > See what I mean? > > Steve > > Hal Helms wrote: > > > > This is a multi-part message in MIME format. > > > > ------=_NextPart_000_000B_01C03134.820A2FE0 > > Content-Type: text/plain; > > charset="iso-8859-1" > > Content-Transfer-Encoding: 7bit > > > > Right now, we turn all form and URL variables into attributes variables. > Now > > that we have the request scope (which wasn't available when Steve and Gabe > > did the original spec), can anyone think of a good reason not to turn them > > into request-scoped variables instead? It would still work with either > > <cfinclude> or <cfmodule>. > > > > The reason I'm thinking about this is that while I'm developing, I use a > > custom tag called "LogTest" that helps me track what's happening > internally > > by writing stuff to a log file. One thing I want to log is the fuseaction > > name, but if I'm calling this from a custom tag (say as a function), then > > the fuseaction isn't available to me unless I explicitly pass it in. I'd > > rather not have to do this. I can't think of a reason not to turn these > into > > request variables, but I might be missing something. > > > > Hal > > > > ------=_NextPart_000_000B_01C03134.820A2FE0 > > Content-Type: text/html; > > charset="iso-8859-1" > > Content-Transfer-Encoding: quoted-printable > > > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> > > <HTML><HEAD> > > <META content=3D"text/html; charset=3Diso-8859-1" = > > http-equiv=3DContent-Type> > > <META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR></HEAD> > > <BODY> > > <DIV><FONT face=3DArial size=3D2><SPAN class=3D790372518-08102000>Right = > > now, we turn=20 > > all form and URL variables into attributes variables. Now that we have = > > the=20 > > request scope (which wasn't available when Steve and Gabe did the = > > original=20 > > spec), can anyone think of a good reason not to turn them into = > > request-scoped=20 > > variables instead? It would still work with either <cfinclude> or=20 > > <cfmodule>. </SPAN></FONT></DIV> > > <DIV><FONT face=3DArial size=3D2><SPAN=20 > > class=3D790372518-08102000></SPAN></FONT> </DIV> > > <DIV><FONT face=3DArial size=3D2><SPAN class=3D790372518-08102000>The = > > reason I'm=20 > > thinking about this is that while I'm developing, I use a custom tag = > > called=20 > > "LogTest" that helps me track what's happening internally by writing = > > stuff to a=20 > > log file. One thing I want to log is the fuseaction name, but if I'm = > > calling=20 > > this from a custom tag (say as a function), then the fuseaction isn't = > > available=20 > > to me unless I explicitly pass it in. I'd rather not have to do = > > this. I=20 > > can't think of a reason not to turn these into request variables, but I = > > might be=20 > > missing something.</SPAN></FONT></DIV> > > <DIV><FONT face=3DArial size=3D2><SPAN=20 > > class=3D790372518-08102000></SPAN></FONT> </DIV> > > <DIV><FONT face=3DArial size=3D2><SPAN=20 > > class=3D790372518-08102000>Hal</SPAN></FONT></DIV> > > <DIV><FONT face=3DArial size=3D2><SPAN=20 > > class=3D790372518-08102000></SPAN></FONT> </DIV> > > <DIV><FONT face=3DArial size=3D2><SPAN=20 > > class=3D790372518-08102000></SPAN></FONT> </DIV></BODY></HTML> > > > > ------=_NextPart_000_000B_01C03134.820A2FE0-- > > > > -------------------------------------------------------------------------- > ---- > > To Unsubscribe visit > http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or > send a message to [EMAIL PROTECTED] with 'unsubscribe' in > the body. > ---------------------------------------------------------------------------- > -- > To Unsubscribe visit > http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or > send a message to [EMAIL PROTECTED] with 'unsubscribe' in > the body. > > ------------------------------------------------------------------------------ > To Unsubscribe visit >http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or send a >message to [EMAIL PROTECTED] with 'unsubscribe' in the body. ------------------------------------------------------------------------------ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
