> you're wrong on this billy. by doing it this way, the only > thin a person can execute is the stored procedures that you > allow them to. they will not be able to use cfquery to do > queries directly against the database. i have been doing > this for around a year now, and have been trying to find a > "hack" it for a year now too. I haven't been able to do so > yet.
Either you're not trying very hard, or you misunderstood Billy's argument. Basically, if you've got a shared CF server, and the usernames and passwords for each individual datasource are stored persistently on that server, then the key to being able to access another database is to retrieve those usernames and passwords. By default, they're usually in the registry. So, if a developer can write code on the server, and that code can read the values from the registry, then they can gain the same level of access to the database that the other application can. Now, admittedly, by properly securing the SQL server you can limit what any CF applications can do (just calling the allowed stored procedures), but even being able to call those stored procedures is a serious security issue, as I'm sure you're aware. By the way, you ought to post your SQL Server presentation on your CFUG's web site, so that others can enjoy it - that sort of stuff is good for people to know, and there are often questions on this list about those things. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ______________________________________________________________________ Get the mailserver that powers this list at http://www.coolfusion.com 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
