Re: [ACFUG Discuss] interesting issue
I'm with dean, i always put this stuff in the request scope... seems to make more sense.On 7/23/06, Douglas Knudsen [EMAIL PROTECTED] wrote:lock if a race condition is expected, eh? a DSN setting that is never expeced to change on a regular basis wouldn't need a lock. But if other things are being set/read in a shared scope ( frames can be suspect here) locking may need to be used. http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_18235DKOn 7/23/06, Dean H. Saxe [EMAIL PROTECTED] wrote: Shared scope variables are generally locked.I know this changedwith CFMX and I'm not sure what the latest thinking is.Its beenhabit for so long I can't seem to break it.-dhsDean H. Saxe, CISSP, CEH [EMAIL PROTECTED]To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the Americanpublic. -- Theodore RooseveltOn Jul 23, 2006, at 6:29 PM, Dusty Hale wrote: Why would an application scope variable need to be locked (it never changes)? I was always under the assumption that only session scope variables need to be locked. I could have this wrong but I thought as a best practice, persistent variables values that never change (like a datasource name) should be application scope and persistent variables that do change (like specific user info) should be client or session scope (client scope preferred) and that only session scope variables need locks. Do you recommend also locking client scope? These are best practices I learned years ago with Hal Helms but it has been a while and could be a little fuzzy in my head ... Dusty -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Dean H. Saxe Sent: Sunday, July 23, 2006 5:58 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue Which would lead you to lock it... the REQUEST scope is fine for this sort of data. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public.-- Theodore Roosevelt On Jul 23, 2006, at 5:02 PM, Dusty Hale wrote: Now that I think of it since things like datasource names don't change at all ever, I should probably be using the application scope . Dusty From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Teddy Payne Sent: Sunday, July 23, 2006 4:45 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue Dusty, IFrames are buggy to begin with.In the past to overcome this, I used a more persistent scope like CLIENT or SESSION scope to persist into the IFRAME. I remember something to the effect that the loading page will get the request scope, but the IFrame is created by the browser, so that is the client browser creating the request and not the application. Teddy On 7/23/06, Dusty Hale [EMAIL PROTECTED] wrote: Yes I only have one application.cfm in the webroot and the page that is in the frame is also in the webroot. Strang one ... ??? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John Mason Sent: Sunday, July 23, 2006 2:28 PM To: discussion@acfug.org Subject: RE: [ACFUG Discuss] interesting issue Is the page that is in the frame on the same directory or sub directory of the application.cfm? Do you have any other application.cfm's floating around? John [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Dusty Hale Sent: Sunday, July 23, 2006 12:33 PM To: discussion@acfug.org Subject: [ACFUG Discuss] interesting issue I ran into something interesting and wondered if anyone had any insight on it. I have noticed that variables set in application.cfm, in this case in the request scope, do not work when pages are in an iFrame. For example (request variables are set in application.cfm): CFQUERY datasource=#request.dsnName# username=#request.dsnUser# password=#request.dsnPass#name=tracks SELECT * FROM myTable ORDER BY datestamp DESC /CFQUERY This query runs fine on its own and the datasource, user, pass are set up in the application.cfm file. However, if I use this same query on a page that calls the page it is in from an iFrame as in: iframe src="" width=133 height=320 scrolling=Auto frameborder=0/ iframe, it won't run and throws an error: [Macromedia][SQLServer JDBC Driver][SQLServer]SELECT permission denied on object 'myTable', database 'myDataBase', owner 'dbo'. When I hard code the datasource, username, password into the cfquery tag instead of using the variables set in application.cfm, it then runs fine in the iFrame tag. This is a band aid I guess but it would be nice to understand why it is really happening. Anyone have any insig
Re: [ACFUG Discuss] interesting issue
sorry useless point, have you tried getting any variable from the request scope in your iframe?On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote:I'm with dean, i always put this stuff in the request scope... seems to make more sense. On 7/23/06, Douglas Knudsen [EMAIL PROTECTED] wrote:lock if a race condition is expected, eh? a DSN setting that is never expeced to change on a regular basis wouldn't need a lock. But if other things are being set/read in a shared scope ( frames can be suspect here) locking may need to be used. http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_18235DKOn 7/23/06, Dean H. Saxe [EMAIL PROTECTED] wrote: Shared scope variables are generally locked.I know this changedwith CFMX and I'm not sure what the latest thinking is.Its beenhabit for so long I can't seem to break it.-dhsDean H. Saxe, CISSP, CEH [EMAIL PROTECTED] To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the Americanpublic. -- Theodore RooseveltOn Jul 23, 2006, at 6:29 PM, Dusty Hale wrote: Why would an application scope variable need to be locked (it never changes)? I was always under the assumption that only session scope variables need to be locked. I could have this wrong but I thought as a best practice, persistent variables values that never change (like a datasource name) should be application scope and persistent variables that do change (like specific user info) should be client or session scope (client scope preferred) and that only session scope variables need locks. Do you recommend also locking client scope? These are best practices I learned years ago with Hal Helms but it has been a while and could be a little fuzzy in my head ... Dusty -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Dean H. Saxe Sent: Sunday, July 23, 2006 5:58 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue Which would lead you to lock it... the REQUEST scope is fine for this sort of data. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public.-- Theodore Roosevelt On Jul 23, 2006, at 5:02 PM, Dusty Hale wrote: Now that I think of it since things like datasource names don't change at all ever, I should probably be using the application scope . Dusty From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Teddy Payne Sent: Sunday, July 23, 2006 4:45 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue Dusty, IFrames are buggy to begin with.In the past to overcome this, I used a more persistent scope like CLIENT or SESSION scope to persist into the IFRAME. I remember something to the effect that the loading page will get the request scope, but the IFrame is created by the browser, so that is the client browser creating the request and not the application. Teddy On 7/23/06, Dusty Hale [EMAIL PROTECTED] wrote: Yes I only have one application.cfm in the webroot and the page that is in the frame is also in the webroot. Strang one ... ??? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John Mason Sent: Sunday, July 23, 2006 2:28 PM To: discussion@acfug.org Subject: RE: [ACFUG Discuss] interesting issue Is the page that is in the frame on the same directory or sub directory of the application.cfm? Do you have any other application.cfm's floating around? John [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Dusty Hale Sent: Sunday, July 23, 2006 12:33 PM To: discussion@acfug.org Subject: [ACFUG Discuss] interesting issue I ran into something interesting and wondered if anyone had any insight on it. I have noticed that variables set in application.cfm, in this case in the request scope, do not work when pages are in an iFrame. For example (request variables are set in application.cfm): CFQUERY datasource=#request.dsnName# username=#request.dsnUser# password=#request.dsnPass#name=tracks SELECT * FROM myTable ORDER BY datestamp DESC /CFQUERY This query runs fine on its own and the datasource, user, pass are set up in the application.cfm file. However, if I use this same query on a page that calls the page it is in from an iFrame as in: iframe src="" width=133 height=320 scrolling=Auto frameborder=0/ iframe, it won't run and throws an error: [Macromedia][SQLServer JDBC Driver][SQLServer]SELECT permission denied on object 'myTable', database 'myDataBase', owner 'dbo'. When I hard code the datasource, username, password into the cfquery tag instead of using the variables set in application.cfm, it then runs fine in the iFrame tag. This is a
Re: [ACFUG Discuss] interesting issue
I just tested creating a dummy query in my application cfm and dumping it in my iframe and it worked fine...On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote:sorry useless point, have you tried getting any variable from the request scope in your iframe? On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote:I'm with dean, i always put this stuff in the request scope... seems to make more sense. On 7/23/06, Douglas Knudsen [EMAIL PROTECTED] wrote:lock if a race condition is expected, eh? a DSN setting that is never expeced to change on a regular basis wouldn't need a lock. But if other things are being set/read in a shared scope ( frames can be suspect here) locking may need to be used. http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_18235DKOn 7/23/06, Dean H. Saxe [EMAIL PROTECTED] wrote: Shared scope variables are generally locked.I know this changedwith CFMX and I'm not sure what the latest thinking is.Its beenhabit for so long I can't seem to break it.-dhsDean H. Saxe, CISSP, CEH [EMAIL PROTECTED] To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the Americanpublic. -- Theodore RooseveltOn Jul 23, 2006, at 6:29 PM, Dusty Hale wrote: Why would an application scope variable need to be locked (it never changes)? I was always under the assumption that only session scope variables need to be locked. I could have this wrong but I thought as a best practice, persistent variables values that never change (like a datasource name) should be application scope and persistent variables that do change (like specific user info) should be client or session scope (client scope preferred) and that only session scope variables need locks. Do you recommend also locking client scope? These are best practices I learned years ago with Hal Helms but it has been a while and could be a little fuzzy in my head ... Dusty -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Dean H. Saxe Sent: Sunday, July 23, 2006 5:58 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue Which would lead you to lock it... the REQUEST scope is fine for this sort of data. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public.-- Theodore Roosevelt On Jul 23, 2006, at 5:02 PM, Dusty Hale wrote: Now that I think of it since things like datasource names don't change at all ever, I should probably be using the application scope . Dusty From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Teddy Payne Sent: Sunday, July 23, 2006 4:45 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue Dusty, IFrames are buggy to begin with.In the past to overcome this, I used a more persistent scope like CLIENT or SESSION scope to persist into the IFRAME. I remember something to the effect that the loading page will get the request scope, but the IFrame is created by the browser, so that is the client browser creating the request and not the application. Teddy On 7/23/06, Dusty Hale [EMAIL PROTECTED] wrote: Yes I only have one application.cfm in the webroot and the page that is in the frame is also in the webroot. Strang one ... ??? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John Mason Sent: Sunday, July 23, 2006 2:28 PM To: discussion@acfug.org Subject: RE: [ACFUG Discuss] interesting issue Is the page that is in the frame on the same directory or sub directory of the application.cfm? Do you have any other application.cfm's floating around? John [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Dusty Hale Sent: Sunday, July 23, 2006 12:33 PM To: discussion@acfug.org Subject: [ACFUG Discuss] interesting issue I ran into something interesting and wondered if anyone had any insight on it. I have noticed that variables set in application.cfm, in this case in the request scope, do not work when pages are in an iFrame. For example (request variables are set in application.cfm): CFQUERY datasource=#request.dsnName# username=#request.dsnUser# password=#request.dsnPass#name=tracks SELECT * FROM myTable ORDER BY datestamp DESC /CFQUERY This query runs fine on its own and the datasource, user, pass are set up in the application.cfm file. However, if I use this same query on a page that calls the page it is in from an iFrame as in: iframe src="" width=133 height=320 scrolling=Auto frameborder=0/ iframe, it won't run and throws an error: [Macromedia][SQLServer JDBC Driver][SQLServer]SELECT permission denied on object 'myTable', database 'myDataBase', owner 'dbo'. W
RE: [ACFUG Discuss] interesting issue
I have no doubt that the problem must lie somewhere else From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Ross Sent: Monday, July 24, 2006 8:53 AM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue I just tested creating a dummy query in my application cfm and dumping it in my iframe and it worked fine... On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote: sorry useless point, have you tried getting any variable from the request scope in your iframe? On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote: I'm with dean, i always put this stuff in the request scope... seems to make more sense. On 7/23/06, Douglas Knudsen [EMAIL PROTECTED] wrote: lock if a race condition is expected, eh? a DSN setting that is never expeced to change on a regular basis wouldn't need a lock. But if other things are being set/read in a shared scope ( frames can be suspect here) locking may need to be used. http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_18235 DK On 7/23/06, Dean H. Saxe [EMAIL PROTECTED] wrote: Shared scope variables are generally locked.I know this changed with CFMX and I'm not sure what the latest thinking is.Its been habit for so long I can't seem to break it. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt On Jul 23, 2006, at 6:29 PM, Dusty Hale wrote: Why would an application scope variable need to be locked (it never changes)? I was always under the assumption that only session scope variables need to be locked. I could have this wrong but I thought as a best practice, persistent variables values that never change (like a datasource name) should be application scope and persistent variables that do change (like specific user info) should be client or session scope (client scope preferred) and that only session scope variables need locks. Do you recommend also locking client scope? These are best practices I learned years ago with Hal Helms but it has been a while and could be a little fuzzy in my head ... Dusty -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Dean H. Saxe Sent: Sunday, July 23, 2006 5:58 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue Which would lead you to lock it... the REQUEST scope is fine for this sort of data. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt On Jul 23, 2006, at 5:02 PM, Dusty Hale wrote: Now that I think of it since things like datasource names don't change at all ever, I should probably be using the application scope . Dusty From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Teddy Payne Sent: Sunday, July 23, 2006 4:45 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue Dusty, IFrames are buggy to begin with.In the past to overcome this, I used a more persistent scope like CLIENT or SESSION scope to persist into the IFRAME. I remember something to the effect that the loading page will get the request scope, but the IFrame is created by the browser, so that is the client browser creating the request and not the application. Teddy On 7/23/06, Dusty Hale [EMAIL PROTECTED] wrote: Yes I only have one application.cfm in the webroot and the page that is in the frame is also in the webroot. Strang one ... ??? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John Mason Sent: Sunday, July 23, 2006 2:28 PM To: discussion@acfug.org Subject: RE: [ACFUG Discuss] interesting issue Is the page that is in the frame on the same directory or sub directory of the application.cfm? Do you have any other application.cfm's floating around? John [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Dusty Hale Sent: Sunday, July 23, 2006 12:33 PM To: discussion@acfug.org Subject: [ACFUG Discuss] interesting issue I ran into something interesting and wondered if anyone had any insight on it. I have noticed that variables set in application.cfm, in this case in the request scope, do not work when pages are in an iFrame. For example (request variables are set in application.cfm): CFQUERY datasource=#request.dsnName# username=#request.dsnUser# password=#request.dsnPass#name=tracks SELECT * FROM myTable ORDER BY datestamp DESC /CFQUERY This query runs fine on its own
Re: [ACFUG Discuss] interesting issue
Hmm.. i just tried this with basically your same setup... iframe calls a query to SQL server and the DSN is in the application.cfm in the request scope and it works fine. running CF 7,0,1,116466 On 7/24/06, Dusty Hale [EMAIL PROTECTED] wrote: I have no doubt that the problem must lie somewhere else … From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Steven Ross Sent: Monday, July 24, 2006 8:53 AM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue I just tested creating a dummy query in my application cfm and dumping it in my iframe and it worked fine... On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote: sorry useless point, have you tried getting any variable from the request scope in your iframe? On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote: I'm with dean, i always put this stuff in the request scope... seems to make more sense. On 7/23/06, Douglas Knudsen [EMAIL PROTECTED] wrote: lock if a race condition is expected, eh? a DSN setting that is never expeced to change on a regular basis wouldn't need a lock. But if other things are being set/read in a shared scope ( frames can be suspect here) locking may need to be used. http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_18235 DK On 7/23/06, Dean H. Saxe [EMAIL PROTECTED] wrote: Shared scope variables are generally locked.I know this changed with CFMX and I'm not sure what the latest thinking is.Its been habit for so long I can't seem to break it. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt On Jul 23, 2006, at 6:29 PM, Dusty Hale wrote: Why would an application scope variable need to be locked (it never changes)? I was always under the assumption that only session scope variables need to be locked. I could have this wrong but I thought as a best practice, persistent variables values that never change (like a datasource name) should be application scope and persistent variables that do change (like specific user info) should be client or session scope (client scope preferred) and that only session scope variables need locks. Do you recommend also locking client scope? These are best practices I learned years ago with Hal Helms but it has been a while and could be a little fuzzy in my head ... Dusty -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Dean H. Saxe Sent: Sunday, July 23, 2006 5:58 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue Which would lead you to lock it... the REQUEST scope is fine for this sort of data. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt On Jul 23, 2006, at 5:02 PM, Dusty Hale wrote: Now that I think of it since things like datasource names don't change at all ever, I should probably be using the application scope . Dusty From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Teddy Payne Sent: Sunday, July 23, 2006 4:45 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue Dusty, IFrames are buggy to begin with.In the past to overcome this, I used a more persistent scope like CLIENT or SESSION scope to persist into the IFRAME. I remember something to the effect that the loading page will get the request scope, but the IFrame is created by the browser, so that is the client browser creating the request and not the application. Teddy On 7/23/06, Dusty Hale [EMAIL PROTECTED] wrote: Yes I only have one application.cfm in the webroot and the page that is in the frame is also in the webroot. Strang one ... ??? -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of John Mason Sent: Sunday, July 23, 2006 2:28 PM To: discussion@acfug.org Subject: RE: [ACFUG Discuss] interesting issue Is the page that is in the frame on the same directory or sub directory of the application.cfm? Do you have any other application.cfm's floating around? John [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Dusty Hale Sent: Sunday, July 23, 2006 12:33 PM To: discussion@acfug.org Subject: [ACFUG Discuss] interesting issue I ran into something interesting and wondered if anyone had any insight on it. I have noticed that variables set in application.cfm, in this case in the request scope, do not work when pages
Re: [ACFUG Discuss] interesting issue
You can also create multiple datasources to do the same thing. If you keep the username/password around, how do you ensure its security? CFAdmin helps, somewhat, in that regard. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] [U]nconstitutional behavior by the authorities is constrained only by the peoples' willingness to contest them --John Perry Barlow On Jul 24, 2006, at 3:47 PM, Teddy Payne wrote: One reason to do that is if the data security is being managed from the database. You can have users who have access to certain tables and stored procedures. It allows for granule level security on data. Teddy On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote: I don't know why I didn't notice this before but, why do you have the DSN, username and password info in the cfquery? Maybe this is causing some strange problem? I don't really get why you would send the UNAP in the query when you can just set it up in the CF Admin. On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote: Hmm.. i just tried this with basically your same setup... iframe calls a query to SQL server and the DSN is in the application.cfm in the request scope and it works fine. running CF 7,0,1,116466 On 7/24/06, Dusty Hale [EMAIL PROTECTED] wrote: I have no doubt that the problem must lie somewhere else … From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Ross Sent: Monday, July 24, 2006 8:53 AM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue I just tested creating a dummy query in my application cfm and dumping it in my iframe and it worked fine... On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote: sorry useless point, have you tried getting any variable from the request scope in your iframe? On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote: I'm with dean, i always put this stuff in the request scope... seems to make more sense. On 7/23/06, Douglas Knudsen [EMAIL PROTECTED] wrote: lock if a race condition is expected, eh?a DSN setting that is never expeced to change on a regular basis wouldn't need a lock. But if other things are being set/read in a shared scope ( frames can be suspect here) locking may need to be used. http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_18235 DK On 7/23/06, Dean H. Saxe [EMAIL PROTECTED] wrote: Shared scope variables are generally locked. I know this changed with CFMX and I'm not sure what the latest thinking is. Its been habit for so long I can't seem to break it. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt On Jul 23, 2006, at 6:29 PM, Dusty Hale wrote: Why would an application scope variable need to be locked (it never changes)? I was always under the assumption that only session scope variables need to be locked. I could have this wrong but I thought as a best practice, persistent variables values that never change (like a datasource name) should be application scope and persistent variables that do change (like specific user info) should be client or session scope (client scope preferred) and that only session scope variables need locks. Do you recommend also locking client scope? These are best practices I learned years ago with Hal Helms but it has been a while and could be a little fuzzy in my head ... Dusty -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of Dean H. Saxe Sent: Sunday, July 23, 2006 5:58 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue Which would lead you to lock it... the REQUEST scope is fine for this sort of data. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt On Jul 23, 2006, at 5:02 PM, Dusty Hale wrote: Now that I think of it since things like datasource names don't change at all ever, I should probably be using the application scope . Dusty From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] ] On Behalf Of Teddy Payne Sent: Sunday, July 23, 2006 4:45 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue Dusty, IFrames are buggy to begin with. In the past to overcome this, I used a more persistent scope like CLIENT or SESSION scope to persist into the IFRAME. I remember something to the effect that the loading page will get the request scope, but the IFrame is created by the browser, so that is the client browser creating the request and not the application. Teddy On 7/23/06, Dusty Hale [EMAIL PROTECTED] wrote
Re: [ACFUG Discuss] interesting issue
A couple of things here. Multiple datasources can use different users in different roles on the same DB. SQL credentials are generally considered to be less secure than using Windows domain credentials unless you are using an encrypted DB connection. Mixed mode authentication should be disabled, generally speaking. DB auditing is only one level of auditing. Secure systems audit at multiple levels to distinct log/audit servers. One cannot depend on DB auditing in lieu of application level auditing. Both are required to truly build an effective audit trail. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] Great spirits have often encountered violent opposition from weak minds. --Einstein On Jul 24, 2006, at 4:31 PM, Teddy Payne wrote: For example in SQL Server, you create SQL users that can access only certain table and have certain roles. SQL Server stores the username and password in a nice encypted field for you when you create a SQL user. Then from ColdFusion, you use username and password on queries and stored procedures. You catch the exceptions due to lack of access to prevent users from accessing parts of your web site. Also, since you are logged using SQL credentials, you can audit the data change to the user and not the generic user used to connect to the datasource from the CF Administrator. You can do this without using SQL authentication, but why create your own audit system when the database has it built in? This is only the premise when you want user level auditing of data for regulated datasources. I just listed this example a use case of a previous client that implemented it. Most applications don't need this level of granularity. One authenticated user for the datasource works just fine. On 7/24/06, Dean H. Saxe [EMAIL PROTECTED] wrote: You can also create multiple datasources to do the same thing. If you keep the username/password around, how do you ensure its security? CFAdmin helps, somewhat, in that regard. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] [U]nconstitutional behavior by the authorities is constrained only by the peoples' willingness to contest them --John Perry Barlow On Jul 24, 2006, at 3:47 PM, Teddy Payne wrote: One reason to do that is if the data security is being managed from the database. You can have users who have access to certain tables and stored procedures. It allows for granule level security on data. Teddy On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote: I don't know why I didn't notice this before but, why do you have the DSN, username and password info in the cfquery? Maybe this is causing some strange problem? I don't really get why you would send the UNAP in the query when you can just set it up in the CF Admin. On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote: Hmm.. i just tried this with basically your same setup... iframe calls a query to SQL server and the DSN is in the application.cfm in the request scope and it works fine. running CF 7,0,1,116466 On 7/24/06, Dusty Hale [EMAIL PROTECTED] wrote: I have no doubt that the problem must lie somewhere else … From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Ross Sent: Monday, July 24, 2006 8:53 AM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue I just tested creating a dummy query in my application cfm and dumping it in my iframe and it worked fine... On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote: sorry useless point, have you tried getting any variable from the request scope in your iframe? On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote: I'm with dean, i always put this stuff in the request scope... seems to make more sense. On 7/23/06, Douglas Knudsen [EMAIL PROTECTED] wrote: lock if a race condition is expected, eh?a DSN setting that is never expeced to change on a regular basis wouldn't need a lock. But if other things are being set/read in a shared scope ( frames can be suspect here) locking may need to be used. http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_18235 DK On 7/23/06, Dean H. Saxe [EMAIL PROTECTED] wrote: Shared scope variables are generally locked. I know this changed with CFMX and I'm not sure what the latest thinking is. Its been habit for so long I can't seem to break it. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt On Jul 23, 2006, at 6:29 PM, Dusty Hale wrote: Why would an application scope variable need to be locked (it never changes)? I was always under the assumption that only session scope variables need to be locked. I could have this wrong but I thought as a best practice
Re: [ACFUG Discuss] interesting issue
Which would lead you to lock it... the REQUEST scope is fine for this sort of data. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt On Jul 23, 2006, at 5:02 PM, Dusty Hale wrote: Now that I think of it since things like datasource names don’t change at all ever, I should probably be using the application scope … Dusty From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Teddy Payne Sent: Sunday, July 23, 2006 4:45 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue Dusty, IFrames are buggy to begin with. In the past to overcome this, I used a more persistent scope like CLIENT or SESSION scope to persist into the IFRAME. I remember something to the effect that the loading page will get the request scope, but the IFrame is created by the browser, so that is the client browser creating the request and not the application. Teddy On 7/23/06, Dusty Hale [EMAIL PROTECTED] wrote: Yes I only have one application.cfm in the webroot and the page that is in the frame is also in the webroot. Strang one ... ??? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Mason Sent: Sunday, July 23, 2006 2:28 PM To: discussion@acfug.org Subject: RE: [ACFUG Discuss] interesting issue Is the page that is in the frame on the same directory or sub directory of the application.cfm? Do you have any other application.cfm's floating around? John [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dusty Hale Sent: Sunday, July 23, 2006 12:33 PM To: discussion@acfug.org Subject: [ACFUG Discuss] interesting issue I ran into something interesting and wondered if anyone had any insight on it. I have noticed that variables set in application.cfm, in this case in the request scope, do not work when pages are in an iFrame. For example (request variables are set in application.cfm): CFQUERY datasource=#request.dsnName# username=#request.dsnUser# password=#request.dsnPass# name=tracks SELECT * FROM myTable ORDER BY datestamp DESC /CFQUERY This query runs fine on its own and the datasource, user, pass are set up in the application.cfm file. However, if I use this same query on a page that calls the page it is in from an iFrame as in: iframe src=mypage.cfm width=133 height=320 scrolling=Auto frameborder=0/ iframe, it won't run and throws an error: [Macromedia][SQLServer JDBC Driver][SQLServer]SELECT permission denied on object 'myTable', database 'myDataBase', owner 'dbo'. When I hard code the datasource, username, password into the cfquery tag instead of using the variables set in application.cfm, it then runs fine in the iFrame tag. This is a band aid I guess but it would be nice to understand why it is really happening. Anyone have any insight? Dusty - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com - -- cf_payne / http://cfpayne.wordpress.com/ - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink
Re: [ACFUG Discuss] interesting issue
IFRAME is a client-side issue that has nothing to do with the processing scope on the server. CF has no concept of an IFRAME, its just another http request. Dusty, make sure you do a thorough search for any rogue Application.cfm files. That will cause this behavior. Otherwise, debug the IFRAME template and see if the Application.cfm file you think should be called was indeed called. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] Free speech exercised both individually and through a free press, is a necessity in any country where people are themselves free. -- Theodore Roosevelt, 1918 On Jul 23, 2006, at 4:45 PM, Teddy Payne wrote: Dusty, IFrames are buggy to begin with. In the past to overcome this, I used a more persistent scope like CLIENT or SESSION scope to persist into the IFRAME. I remember something to the effect that the loading page will get the request scope, but the IFrame is created by the browser, so that is the client browser creating the request and not the application. Teddy On 7/23/06, Dusty Hale [EMAIL PROTECTED] wrote: Yes I only have one application.cfm in the webroot and the page that is in the frame is also in the webroot. Strang one ... ??? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Mason Sent: Sunday, July 23, 2006 2:28 PM To: discussion@acfug.org Subject: RE: [ACFUG Discuss] interesting issue Is the page that is in the frame on the same directory or sub directory of the application.cfm? Do you have any other application.cfm's floating around? John [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dusty Hale Sent: Sunday, July 23, 2006 12:33 PM To: discussion@acfug.org Subject: [ACFUG Discuss] interesting issue I ran into something interesting and wondered if anyone had any insight on it. I have noticed that variables set in application.cfm, in this case in the request scope, do not work when pages are in an iFrame. For example (request variables are set in application.cfm): CFQUERY datasource=#request.dsnName# username=#request.dsnUser# password=#request.dsnPass# name=tracks SELECT * FROM myTable ORDER BY datestamp DESC /CFQUERY This query runs fine on its own and the datasource, user, pass are set up in the application.cfm file. However, if I use this same query on a page that calls the page it is in from an iFrame as in: iframe src=mypage.cfm width=133 height=320 scrolling=Auto frameborder=0/ iframe, it won't run and throws an error: [Macromedia][SQLServer JDBC Driver][SQLServer]SELECT permission denied on object 'myTable', database 'myDataBase', owner 'dbo'. When I hard code the datasource, username, password into the cfquery tag instead of using the variables set in application.cfm, it then runs fine in the iFrame tag. This is a band aid I guess but it would be nice to understand why it is really happening. Anyone have any insight? Dusty - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com - -- cf_payne / http://cfpayne.wordpress.com/ - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -
RE: [ACFUG Discuss] interesting issue
Why would an application scope variable need to be locked (it never changes)? I was always under the assumption that only session scope variables need to be locked. I could have this wrong but I thought as a best practice, persistent variables values that never change (like a datasource name) should be application scope and persistent variables that do change (like specific user info) should be client or session scope (client scope preferred) and that only session scope variables need locks. Do you recommend also locking client scope? These are best practices I learned years ago with Hal Helms but it has been a while and could be a little fuzzy in my head ... Dusty -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean H. Saxe Sent: Sunday, July 23, 2006 5:58 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue Which would lead you to lock it... the REQUEST scope is fine for this sort of data. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt On Jul 23, 2006, at 5:02 PM, Dusty Hale wrote: Now that I think of it since things like datasource names don't change at all ever, I should probably be using the application scope . Dusty From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Teddy Payne Sent: Sunday, July 23, 2006 4:45 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue Dusty, IFrames are buggy to begin with. In the past to overcome this, I used a more persistent scope like CLIENT or SESSION scope to persist into the IFRAME. I remember something to the effect that the loading page will get the request scope, but the IFrame is created by the browser, so that is the client browser creating the request and not the application. Teddy On 7/23/06, Dusty Hale [EMAIL PROTECTED] wrote: Yes I only have one application.cfm in the webroot and the page that is in the frame is also in the webroot. Strang one ... ??? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Mason Sent: Sunday, July 23, 2006 2:28 PM To: discussion@acfug.org Subject: RE: [ACFUG Discuss] interesting issue Is the page that is in the frame on the same directory or sub directory of the application.cfm? Do you have any other application.cfm's floating around? John [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dusty Hale Sent: Sunday, July 23, 2006 12:33 PM To: discussion@acfug.org Subject: [ACFUG Discuss] interesting issue I ran into something interesting and wondered if anyone had any insight on it. I have noticed that variables set in application.cfm, in this case in the request scope, do not work when pages are in an iFrame. For example (request variables are set in application.cfm): CFQUERY datasource=#request.dsnName# username=#request.dsnUser# password=#request.dsnPass# name=tracks SELECT * FROM myTable ORDER BY datestamp DESC /CFQUERY This query runs fine on its own and the datasource, user, pass are set up in the application.cfm file. However, if I use this same query on a page that calls the page it is in from an iFrame as in: iframe src=mypage.cfm width=133 height=320 scrolling=Auto frameborder=0/ iframe, it won't run and throws an error: [Macromedia][SQLServer JDBC Driver][SQLServer]SELECT permission denied on object 'myTable', database 'myDataBase', owner 'dbo'. When I hard code the datasource, username, password into the cfquery tag instead of using the variables set in application.cfm, it then runs fine in the iFrame tag. This is a band aid I guess but it would be nice to understand why it is really happening. Anyone have any insight? Dusty - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com - - To unsubscribe from this list, manage your profile @ http
Re: [ACFUG Discuss] interesting issue
Shared scope variables are generally locked. I know this changed with CFMX and I'm not sure what the latest thinking is. Its been habit for so long I can't seem to break it. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt On Jul 23, 2006, at 6:29 PM, Dusty Hale wrote: Why would an application scope variable need to be locked (it never changes)? I was always under the assumption that only session scope variables need to be locked. I could have this wrong but I thought as a best practice, persistent variables values that never change (like a datasource name) should be application scope and persistent variables that do change (like specific user info) should be client or session scope (client scope preferred) and that only session scope variables need locks. Do you recommend also locking client scope? These are best practices I learned years ago with Hal Helms but it has been a while and could be a little fuzzy in my head ... Dusty -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean H. Saxe Sent: Sunday, July 23, 2006 5:58 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue Which would lead you to lock it... the REQUEST scope is fine for this sort of data. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt On Jul 23, 2006, at 5:02 PM, Dusty Hale wrote: Now that I think of it since things like datasource names don't change at all ever, I should probably be using the application scope . Dusty From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Teddy Payne Sent: Sunday, July 23, 2006 4:45 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue Dusty, IFrames are buggy to begin with. In the past to overcome this, I used a more persistent scope like CLIENT or SESSION scope to persist into the IFRAME. I remember something to the effect that the loading page will get the request scope, but the IFrame is created by the browser, so that is the client browser creating the request and not the application. Teddy On 7/23/06, Dusty Hale [EMAIL PROTECTED] wrote: Yes I only have one application.cfm in the webroot and the page that is in the frame is also in the webroot. Strang one ... ??? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Mason Sent: Sunday, July 23, 2006 2:28 PM To: discussion@acfug.org Subject: RE: [ACFUG Discuss] interesting issue Is the page that is in the frame on the same directory or sub directory of the application.cfm? Do you have any other application.cfm's floating around? John [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dusty Hale Sent: Sunday, July 23, 2006 12:33 PM To: discussion@acfug.org Subject: [ACFUG Discuss] interesting issue I ran into something interesting and wondered if anyone had any insight on it. I have noticed that variables set in application.cfm, in this case in the request scope, do not work when pages are in an iFrame. For example (request variables are set in application.cfm): CFQUERY datasource=#request.dsnName# username=#request.dsnUser# password=#request.dsnPass# name=tracks SELECT * FROM myTable ORDER BY datestamp DESC /CFQUERY This query runs fine on its own and the datasource, user, pass are set up in the application.cfm file. However, if I use this same query on a page that calls the page it is in from an iFrame as in: iframe src=mypage.cfm width=133 height=320 scrolling=Auto frameborder=0/ iframe, it won't run and throws an error: [Macromedia][SQLServer JDBC Driver][SQLServer]SELECT permission denied on object 'myTable', database 'myDataBase', owner 'dbo'. When I hard code the datasource, username, password into the cfquery tag instead of using the variables set in application.cfm, it then runs fine in the iFrame tag. This is a band aid I guess but it would be nice to understand why it is really happening. Anyone have any insight? Dusty - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com - - To unsubscribe from this list
