Well the comment is much less about form variables (which would be validated in other ways) than it is about url variables. If a page is going to use url variables at all, there is always the risk of it producing a CF error if a user provides a url variable that's inappropriate. Some of this can be mitigated with things like <cfqueryparam> though it seems in my experience to be a generally not very talked about or examined issue, I think primarily because it just doesn't occur to people that something so seemingly simple and innocuous could actually be an issue.
> I can't see that being a problem if you are incorporating > proper > serverside form validation. Serverside you should be > checking all > validation rules, does it exist, is it the required > datatype, the > required length... > On Fri, 4 Mar 2005 12:42:38 -0500, S. Isaac Dealey > <[EMAIL PROTECTED]> wrote: >> Doesn't that just cause any ugly CF error if they don't >> provide the >> info? (required checkbox or radio button for instance)... >> >> This probably sounds rather silly, especially coming from >> a veteran >> like myself, but I've been noticing or rather more >> thinking about >> lately the idea of rethinking the way that I typically >> use <cfparam> >> for this reason alone... I've always in the past, and I >> think this is >> fairly common, used something like this: >> >> <cfparam name="attributes.objectid" type="numeric" >> default="0"> >> >> <cfif objectid>... do stuff ...</cfif> >> >> In my case the attributes scope is a combination of form >> and url >> variables... And at a first glance this looks really good >> because it's >> nice and validated, you know the data going in is >> correct. But here's >> the problem -- if a user happens to be muddling with the >> url and >> accidentally types a non-numeric character into that url >> variable, >> instead of being ignored the cfparam produces a big ugly >> cf-error that >> the user won't want to see... and using val() in the >> default attribute >> is no help of course because it's not the default value >> that's at >> fault. (and yea, I've made the mistake of type="numeric" >> default="" >> before too). >> >> So I'm starting to think that for the base templates or >> otherwise >> publicly accessible templates, this structure is better: >> >> <cfparam name="attributes.objectid" type="string" >> default=""> >> >> <cfif val(objectid)>... do stuff ...</cfif> >> >> Although the code is only very subtly different, this >> structure will >> never produce the ugly cf error message as a result of a >> user >> accidentally malforming the url, because they can't >> possibly provide a >> value to the server in the url that CF won't interpret as >> a string. >> >> I dunno... maybe I'm just tired and distracted and making >> a big deal >> out of nothing... anydoby else? s. isaac dealey 954.522.6080 new epoch : isn't it time for a change? add features without fixtures with the onTap open source framework http://macromedia.breezecentral.com/p49777853/ http://www.sys-con.com/story/?storyid=48229&DE=1 http://www.sys-con.com/story/?storyid=44477&DE=1 http://www.sys-con.com/story/?storyid=45569&DE=1 http://www.sys-con.com/story/?storyid=48229&DE=1 http://www.fusiontap.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:197501 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
