fortunately just one "client" on the server. Although, this does spark some interesting thoughts.
I've already set the datasources (in the CFMX datasource manager) to only accept a certain type of query, select in the case of the outward facing server; so I don't see much danger there (Is there some I might not be aware of?). For this same "user" the database itself is "locked down" to only accept a specific type of query as well; in other words, "user_outside_X" can only execute select against "TableName". On the inside applications, such as the content management ToolBox I have queries limited to select, input and update. and internal user_internal_X (SQLServer side) is allowed only specific actions. datasourceA (myDatabase) (CFMX ODBC External user, essentially the website queries the db) - user_external allowed select permission, all others locked out datasourceB (sameDatabase) (CFMX ODBC Internal user, example, content management) - user_internal allowed select, insert and update permissions, all others locked out SQL Server permissions set by table with user_external allowed select and user_internal allowed select, insert, update all other permissions locked out so unless I'm mistaken, neither user can execute any other type query against the database unless I have specifically allowed it, no? but, I guess one more layer of security wouldn't hurt. :-) will ---- William H. Bowen Webmaster ALSTOM's T&D Energy Automation & Information Business "Your friendly neighborhood Webmaster!" [EMAIL PROTECTED] http://www.esca.com/ 425.739.3629 Voice 425.466.7016 Cell 425.739.3690 FAX ----- Original Message ----- From: "Phoeun Pha" <[EMAIL PROTECTED]> To: "CF-Community" <[EMAIL PROTECTED]> Sent: Friday, October 18, 2002 12:31 PM Subject: RE: Big "dummy" flags > Well if you already set CFMX to set automatically take care of > authentication with database then u dont need to set anything in > application.cfm to do the password. > > It's more of a security issue. For example, if you are hosting a bunch of > sites that use SQL server, and you set CFMX to connect to the DB at all > times without having to set PW or Login, anyone of your clients can look > into the other's DB provided they know the DB_names and tables/field names! > > Thats why you should turn off this feature and set your password and login > in application.cfm instead, and use it in your queries. That makes sure > that every query ran is checked for authentication. > > -----Original Message----- > From: William H. Bowen [mailto:william.bowen@;gte.net] > Sent: Friday, October 18, 2002 1:15 PM > To: CF-Community > Subject: Re: Big "dummy" flags > > > > Okay, so this question pops into my mind. > > I use the CFMX ODBC Datasources page to set usernames and passwords for > datasources, is there some logic (that I'm missing) to doing it again in my > application.cfm? I do use variables in my datasource="" that are set in > application.cfm, should I also be using usernames and passwords in my query > calls, etc.? > > Just wondering, would like to know if I'm doing something colossally stupid. > > ^_^ > > will > ---- > > William H. Bowen > Webmaster > > ALSTOM's T&D Energy Automation & Information Business > > "Your friendly neighborhood Webmaster!" > > [EMAIL PROTECTED] > http://www.esca.com/ > > 425.739.3629 Voice > 425.466.7016 Cell > 425.739.3690 FAX > ----- Original Message ----- > From: "Deanna Schneider" <[EMAIL PROTECTED]> > To: "CF-Community" <[EMAIL PROTECTED]> > Sent: Friday, October 18, 2002 6:14 AM > Subject: Re: Big "dummy" flags > > > > >What else? I don't know, maybe Deanna will chime in with what I normally > do > > that she has to clean up. :-) > > > > Nah, the stuff that Kevin normally doesn't do that I tell him to do are > the > > newer things that I haven't pounded into his head yet - like using > > cfqueryparams (which is more of a "bonus - this coder knows something" > flag > > than a "dummy" flag). > > > > Some other dummy things: > > Using static datasource names/usernames/passwords for your cfqueries. > These > > should always be variables that you set one place (Application.cfm or > > something else that's included in the Application.cfm). If you've ever had > > to change a database password without doing this, you'll know what I mean. > > > > Not using any caching anywhere - ie calling a query for a list of states > > over and over, instead of caching it. If I recall correctly, the list of > > states hasn't changed much in the last oh....50 or so years. > > > > Not checking for the existence of crucial variables (okay, Kevin does this > > one, but I forget sometimes, too). In other words, you have an action page > > that has to have a "recordid" passed to it. You forgot to either to set a > > default or check to see if it is defined. > > > > Oh, that reminds me of another one - using really old deprecated tags - > like > > parameterexists(). I still see that in code occasionally. > > > > Enough. > > -d > > > > > > > > > > > > Deanna Schneider > > Interactive Media Developer > > [EMAIL PROTECTED] > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=5 Subscription: http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_community Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm
