The way I prefer to do this is by using Strored Procs. You only give the user access to execute stored procs, then you don't have to worry so much about hacking attempts where somebody tries to execute their own SQL..
You can usually verify size limits in the HTML for the form fields, and then you can do numeric and date validation using both JavaScript on the client and simple CF on the server. I have found this to be a very secure and stable way to do things. It also helps to speed up many operations and to a lesser extent helps to guarantee transactional integrity. just my $0.02 >The reasoning is very simple. Even supposing that you limit permissions as >much as possible, within a typical web application you're still going to >have a single user (and by user, I mean a database user account that you >specify within your CF datasource settings) with the rights to select, >insert, update and delete from all user tables. For various reasons, you may >not want to use individual database user accounts for each actual web >application user who runs your app. So, it may not be possible for a >malicious end-user to drop tables or run xp_cmdshell (my favorite, >personally), that end-user could potentially run code that you, the >developer, doesn't want them to. To prevent that, you need to filter input >before you use it in an SQL statement. The importance of input filtering is >hard to overemphasize - if you need further convincing, check out what CERT >(http://www.cert.org/) has to say about it. ______________________________________________________________________ Why Share? Dedicated Win 2000 Server � PIII 800 / 256 MB RAM / 40 GB HD / 20 GB MO/XFER Instant Activation � $99/Month � Free Setup http://www.pennyhost.com/redirect.cfm?adcode=coldfusionc FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
