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 presiden
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
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. >> >> Te
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 >> >
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 &
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 i
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] >> >> >> &
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 v
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 ap
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>>
Re: [ACFUG Discuss] interesting issue
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, orthat 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&g
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): 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="mypage.cfm" width="133" height="320" scrolling="Auto" frameborder="0">, 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
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): > > 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: 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 > - > > > > > > ---
RE: [ACFUG Discuss] interesting issue
Dean I totally agree with the statement you made below ... Strange issue because there is indeed only 1 application.cfm file in this site and all the cfm files are in the root. The iFrame template runs fine on it's own (not being in the iFrame that is) with no debugging needed. As soon as I put it in an iFrame, it blows up. If I hard code the datasource values rather than using variable set in application.cfm it works fine (band-aid). My tired ol eyes could be missing something ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean H. Saxe Sent: Sunday, July 23, 2006 5:57 PM To: discussion@acfug.org Subject: 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): > > 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: 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
Re: [ACFUG Discuss] interesting issue
Dean,You are right that ColdFusion does not have understanding of IFrames. I just experienced a similar issue and was conveying my shared experience.Dusty,I agree with putting the DSN in the application scope in your application.cfm. I did not know if you wanted to change the DSN during the programmatic course of the application. If it indeed does not change, Application seems the most logical spot for the DSN assignment.Teddy On 7/23/06, Dean H. Saxe <[EMAIL PROTECTED]> wrote: Which would lead you to lock it... the REQUEST scope is fine for thissort of data.-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 onlyunpatriotic and servile, but is morally treasonable to the Americanpublic." -- Theodore RooseveltOn 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: > 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 prof
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): 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: 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 - -- 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
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): 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: 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 - -- 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
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: width="133" height="320" scrolling="Auto" frameborder="0">, 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 - -- 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
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. TeddyOn 7/23/06, Dusty Hale <[EMAIL PROTECTED]> wrote: Yes I only have one application.cfm in the webroot and the page that is inthe frame is also in the webroot. Strang one ... ???-Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John MasonSent: Sunday, July 23, 2006 2:28 PMTo: discussion@acfug.orgSubject: RE: [ACFUG Discuss] interesting issue Is the page that is in the frame on the same directory or sub directory ofthe application.cfm? Do you have any other application.cfm's floatingaround?John[EMAIL PROTECTED] -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dusty HaleSent: Sunday, July 23, 2006 12:33 PM To: discussion@acfug.orgSubject: [ACFUG Discuss] interesting issueI ran into something interesting and wondered if anyone had any insight onit. I have noticed that variables set in application.cfm, in this case inthe 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*FROMmyTableORDER BYdatestamp DESCThis 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 thatcalls the page it is in from an iFrame as in: width="133" height="320" scrolling="Auto" frameborder="0">, it won't run and throws an error:[Macromedia][SQLServer JDBC Driver][SQLServer]SELECT permission denied onobject '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 inthe iFrame tag. This is a band aid I guess but it would be nice tounderstand 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/mailinglistsArchive @ 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.edituserformFor more info, see http://www.acfug.org/mailinglistsArchive @ 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.edituserformFor more info, see http://www.acfug.org/mailinglistsArchive @ http://www.mail-archive.com/discussion%40acfug.org/List hosted by http://www.fusionlink.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] interesting issue
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): 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: , 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 -
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): 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: , 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 -
