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
Re: [ACFUG Discuss] interesting issue
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 itssecurity? CFAdmin helps, somewhat, in that regard.-dhsDean H. Saxe, CISSP, CEH [EMAIL PROTECTED]"[U]nconstitutional behavior by the authorities is constrained onlyby 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> th
Re: [ACFUG Discuss] interesting issue
I recently learned some hosts require the username and pwd be sent in the cfquery tag.DKOn 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: >> >> 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
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 b
Re: [ACFUG Discuss] interesting issue
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: >> >> 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
Re: [ACFUG Discuss] Restart on ## unresponsive thread
It's Monday. I was looking at timeout after # seconds and not restart. Where is that coffee? TeddyOn 7/24/06, Teddy Payne < [EMAIL PROTECTED]> wrote:The second link refers to how to do it in CFMX 6.1. Also on my development servers at work, I have this setting under CFMX 6.1 as well.I have attached a screen shot. The server I pulled it fromw as using CFMX version 6,1,0,63958.Teddy On 7/24/06, Douglas Knudsen <[EMAIL PROTECTED] > wrote:that setting is not available in CF 6 or >. DK On 7/24/06, Teddy Payne < [EMAIL PROTECTED]> wrote: Would this help? http://www.adobe.com/devnet/server_archive/articles/cf_timeouts_and_unresponsive_requests.html http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_19438 TeddyOn 7/24/06, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: Greetings: I'm trying to find the "Restart on ## unresponsive thread" setting in ColdFusion 7. This setting restarted the server should ## thread become unresponsive and used to be on the settings page in CF Administrator. I'm running CFMX 7.0.1 under JRun4. My server seems to reset on the 3rd unresponsive thread and I want to verify this setting. I suspect that it is in an XML setting file somewhere on the server, but I can't find it. Sincerely, Brooks Wilson Golf is an awkward set of bodily contortions designed to produce a graceful result. - Thomas D. Armour (1898-1968) Federal Reserve Bank of Atlanta · 1000 Peachtree Street, N.E. · Atlanta Georgia 30309-4470 · 404.498.8178 · fax 404.498.8239 · [EMAIL PROTECTED] -- 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 - -- Douglas Knudsen http://www.cubicleman.com this is my signature, like it? - 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 - -- http://cfpayne.wordpress.com/ -- 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 -
Re: [ACFUG Discuss] Restart on ## unresponsive thread
that setting is not available in CF 6 or >. DKOn 7/24/06, Teddy Payne <[EMAIL PROTECTED]> wrote: Would this help? http://www.adobe.com/devnet/server_archive/articles/cf_timeouts_and_unresponsive_requests.html http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_19438 TeddyOn 7/24/06, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: Greetings: I'm trying to find the "Restart on ## unresponsive thread" setting in ColdFusion 7. This setting restarted the server should ## thread become unresponsive and used to be on the settings page in CF Administrator. I'm running CFMX 7.0.1 under JRun4. My server seems to reset on the 3rd unresponsive thread and I want to verify this setting. I suspect that it is in an XML setting file somewhere on the server, but I can't find it. Sincerely, Brooks Wilson Golf is an awkward set of bodily contortions designed to produce a graceful result. - Thomas D. Armour (1898-1968) Federal Reserve Bank of Atlanta · 1000 Peachtree Street, N.E. · Atlanta Georgia 30309-4470 · 404.498.8178 · fax 404.498.8239 · [EMAIL PROTECTED] -- 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 - -- Douglas Knudsenhttp://www.cubicleman.comthis is my signature, like it? - 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
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 r
Re: [ACFUG Discuss] Restart on ## unresponsive thread
Would this help?http://www.adobe.com/devnet/server_archive/articles/cf_timeouts_and_unresponsive_requests.html http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_19438TeddyOn 7/24/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Greetings: I'm trying to find the "Restart on ## unresponsive thread" setting in ColdFusion 7. This setting restarted the server should ## thread become unresponsive and used to be on the settings page in CF Administrator. I'm running CFMX 7.0.1 under JRun4. My server seems to reset on the 3rd unresponsive thread and I want to verify this setting. I suspect that it is in an XML setting file somewhere on the server, but I can't find it. Sincerely, Brooks Wilson Golf is an awkward set of bodily contortions designed to produce a graceful result. - Thomas D. Armour (1898-1968) Federal Reserve Bank of Atlanta · 1000 Peachtree Street, N.E. · Atlanta Georgia 30309-4470 · 404.498.8178 · fax 404.498.8239 · [EMAIL PROTECTED] -- 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 -
RE: [ACFUG Discuss] TEST - IGNORE
Please ignore this message. - 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 -
[ACFUG Discuss] Restart on ## unresponsive thread
Greetings: I'm trying to find the "Restart on ## unresponsive thread" setting in ColdFusion 7. This setting restarted the server should ## thread become unresponsive and used to be on the settings page in CF Administrator. I'm running CFMX 7.0.1 under JRun4. My server seems to reset on the 3rd unresponsive thread and I want to verify this setting. I suspect that it is in an XML setting file somewhere on the server, but I can't find it. Sincerely, Brooks Wilson Golf is an awkward set of bodily contortions designed to produce a graceful result. - Thomas D. Armour (1898-1968) Federal Reserve Bank of Atlanta · 1000 Peachtree Street, N.E. · Atlanta Georgia 30309-4470 · 404.498.8178 · fax 404.498.8239 · [EMAIL PROTECTED]
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):
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): >> password="#request.dsnPass#" name="tracks">>> SELECT >> *>> FROM>> myTable>> ORDER BY>> datestamp DESC>> 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: >> src="" ">> width="133" height="320" scrolling="
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): >> password="#request.dsnPass#" name="tracks">>> SELECT >> *>> FROM>> myTable>> ORDER BY>> datestamp DESC>> 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: >> 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 '
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): >> password="#request.dsnPass#" name="tracks">>> SELECT >> *>> FROM>> myTable>> ORDER BY>> datestamp DESC>> 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: >> 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, i
