I tried this once before, maybe it was something I was doing but CF didn't want to use the variables db I specificed in the application tag - it did have the right tables in it.
Does the ODBC/OLE DB connection not have to be added as a Client Variable Store in the CFAdmin? >Thanks for your help, I owe you a beverage of your choice. By the time you finally make it out to Perth I'm going to owe >you a lot of those :) Lee will have it pretty sweet if he makes it over to Orlando this year - I reckon you wouldn't have to buy your own drinks the whole week due to your list 'celebrity' status ;) John. > -----Original Message----- > From: Tim Heald [mailto:[EMAIL PROTECTED]] > Sent: 24 April 2002 08:54 > To: [EMAIL PROTECTED] > Subject: RE: breaking out of an FB3-secured app > > > It doesn't need it's own db. I mean that's the best method > but as long as it contains the CDATA and the CGLOBAL tables > it should be all good. There structure is this: > > CDATA TABLE > cfid char allow nulls > app char allow nulls > data text allow nuls > > CGLOBAL TABLE > cfid char allow nulls > data text allow nuls > lvisit datetime allow nulls > > > Then you can add these tables to an already existing database > and be good to go :) > > Tim Heald > ACP/CCFD > Application Development > www.schoollink.net > > -----Original Message----- > From: Tim Heald [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, April 24, 2002 3:48 AM > To: [EMAIL PROTECTED] > Subject: RE: breaking out of an FB3-secured app > > > You can specify in your application tag a db to store the > client vars in and that will over ride the server settings. > Make sure you set up the tables exactly correct though or you > may break something. > > Tim Heald > ACP/CCFD > Application Development > www.schoollink.net > > -----Original Message----- > From: Kay Smoljak [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, April 24, 2002 3:41 AM > To: [EMAIL PROTECTED] > Subject: RE: breaking out of an FB3-secured app > > > OK, I think I'm starting to get an inkling of how I can do this. > > The idea of storing the session data in the database is > interesting. The security model is simple - you're either a > paying subscriber or you're out of luck. So I'm guessing I > can stick with the simplest possible method. I don't like > cookies, although I am using session-based cookies in this > site. Client variables I tend to avoid as I'm pretty sure my > current host is storing them in the registry. So I can log > them in the database? > > I don't know if this will complicate things, but concurrent > logins are not allowed, so I'm actually keeping an > application var with the current sessions. In application.cfm > I update this with the current "hit" and drop off any that > are over the timeout. Maybe I should put this in the database > rather than in the application variable, and have the inner > application check these details? It would be a little slower > I guess... I can probably live with that though. Have to give > it a try. > > Am I starting to talk sensible? > > K. > > -----Original Message----- > From: Lee Borkman [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, 24 April 2002 3:25 PM > To: [EMAIL PROTECTED] > Subject: RE: breaking out of an FB3-secured app > > > Now there are a few parts to this problem: > 1) How can these static files run stand-alone? > That's easy. Put them in there own directory, with their own > Application.cfm. No need for checking the filenames against > a list of permitted files. They are not part of a Fusebox app. > > 2) How can these files be secured against unauthorised > viewers? An external application (possibly FB3) can create > "session" data in an accessible place (eg, database, cookie, > file). There are simple, and complex ways of doing this. It > could be part of an enterprise authentication/authorisation > system, or purpose-built for this small requirement. Then > the Application.cfm in the stand-alone :static" directory > checks the user's credentials in this accessible "session" data. > > 3) How can accesses be logged? > As all of the files are hit *directly* (ie, not through a > "fusebox") the > > standard logging tools should have no problem at all. > > That all looks sweet to me. > > Oh, and when am I going west? As soon as we can work out the > details. I'm trying to come up with a schedule that would > interest a cross-section of the WACFUG without leaving my > children cold and hungry. > > thanks guys, > LeeBB > > > Nev wrote: > > --=_134EE4D8.D8B9D694 > > Content-Type: text/plain; charset=US-ASCII > > Content-Transfer-Encoding: 8bit > > > > Hi Kay, > > > > Is this little gem from a fellow fuseboxer of any value? > > > > I don't recall who it came from but maybe it will help? > > > > <cfscript> > > self = "index.cfm"; > > /*Put direct access cfm template names in this list*/ > > directAccessFiles = "#self#,test.cfm,"; > > AllowAccess = false; > > </cfscript> > > > > <cfloop list="#directAccessFiles#" index="file"> > > <cfscript> > > if (listFindNoCase(cgi.script_name, file, '/')) > > AllowAccess = true; > > </cfscript> > > </cfloop> > > > > <cfif not allowaccess> > > <cfinclude template="warning.cfm"><!--- ---> > > <!--- Run this code, including sending to request.self, or logging > > potential hack attempts ---> > > <!--- <cflocation url="#self#" addtoken="no"> ---> > > </cfif> > > > > > > And when exactly is LeeBB heading west? I'll certainly want > to be on > > the "buy him a beer or two" list for the magic he > contributes to the > > FB community. > > > > Nev > > > > > > >>> [EMAIL PROTECTED] 04/24/02 02:53pm >>> > > Hi Lee, > > > > Knew I could count on you to help me out! But then I guess > it's that > > time of the day when our Yank friends are slumbering. > > > > What you're describing is exactly the method we were using > before, but > > > with cfcontent not cfinclude. However, there's a few things > I need to > > keep in mind. Firstly, apart from changing the links to > ".cfm" instead > > > of ".html", I don't want to require anything else of the > content guy. > > He's finding it tough, I already made him use relative > links instead > > of absolute (his norm). Secondly, I have recently found out > that these > > > guys consider their visitor statistics to be vital, particularly > > exactly which pages are being requested most often. They > are on shared > > > hosting with LiveStats 5 and I already know from (painful) > experience > > that it refuses to watch URLs the way it's meant to. > > > > What I was wondering was if there is any other amazing > magical way... > > like maybe passing the login status to the application.cfm in the > > content directory, but in a secure way somehow. I don't know. It's > > been a long day, and I'm out of ideas. > > > > Thanks for your help, I owe you a beverage of your choice. > By the time > > > you finally make it out to Perth I'm going to owe you a lot of those > > :) > > > > K. > > > > > > > > -----Original Message----- > > From: BORKMAN Lee [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, 24 April 2002 2:40 PM > > To: '[EMAIL PROTECTED]' > > Subject: RE: breaking out of an FB3-secured app > > > > > > Hi Kay, > > > > If these "static" files are all stand-alone CFM templates, then you > > can CFINCLUDE them like any display fuse. > > > > How about a fuseaction called "static.showfile" which takes the > > filename as input, and dynamically includes the appropriate static > > file? Of course, you'd need to resolve any links within the static > > content. > > > > Is that the kind of thing you have in mind? > > > > LeeBB > > > > -----Original Message----- > > From: Kay Smoljak [mailto:[EMAIL PROTECTED]] > > > > Hi all, > > > > I have an interesting problem - well I think it's > interesting anyway. > > I have an FB3 app for a subscription-based content site. My app > > handles all the subscriptions, payments, logins, logouts, > permissions, > > > updating of details, forgotten passwords etc etc. The protected > > content, which someone non-CF handles, is static html. It > was going to > > > be stored outside of the web root, but during testing the > performance > > was quite bad, so I've decided to make the HTML person name all his > > files .cfm and store them in a particular directory within the web > > root. > > > > What I don't know is how I'm going to have access to these files > > controlled by my FB3 app, without requiring them to be in > in the FB3 > > framework. Has anyone done anything like this before? Any ideas? > > > > Thanks in advance, > > Kay. > > > > > > IMPORTANT NOTICE: > > This e-mail and any attachment to it is intended only to be read or > > used by the named addressee. It is confidential and may contain > > legally privileged information. No confidentiality or privilege is > > waived or lost by any mistaken transmission to you. If you receive > > this e-mail in error, please immediately delete it from your system > > and notify the sender. You must not disclose, copy or use > any part of > > > this e-mail if you are not the intended recipient. The RTA is not > > responsible for any unauthorised alterations to this e-mail or > attachment to it. > > > > > > > > --=_134EE4D8.D8B9D694 > > Content-Type: text/html; charset=ISO-8859-1 > > Content-Transfer-Encoding: 8bit > > > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> > > <HTML><HEAD> <META http-equiv=Content-Type content="text/html; > > charset=us-ascii"> <META content="MSHTML 5.50.4807.2300" > > name=GENERATOR></HEAD> <BODY style="MARGIN-TOP: 2px; FONT: 10pt > > Tahoma; MARGIN-LEFT: 2px"> <DIV>Hi Kay,</DIV> <DIV>�</DIV> > > <DIV>Is this little gem from a fellow fuseboxer of any value?</DIV> > > <DIV>�</DIV> > > <DIV>I don't recall who it came from but maybe it will help?</DIV> > > <DIV>�</DIV> > > <DIV><cfscript><BR>��self = "index.cfm";<BR>��/*Put > > direct access cfm template names in this list*/<BR>�� > directAccessFiles > > > = "#self#,test.cfm,";<BR>��AllowAccess = > > false;<BR>�</cfscript></DIV> > > <DIV>�</DIV> > > <DIV><cfloop list="#directAccessFiles#" > > index="file"><BR>�<cfscript><BR>��if > (listFindNoCase(cgi.script_name, > > file, '/')) <BR>���AllowAccess = true;<BR>� > > </cfscript><BR></cfloop></DIV> <DIV>�</DIV> > > <DIV><cfif not allowaccess><BR>�<cfinclude > > template="warning.cfm"><!---� ---><BR>�<!--- Run this > > code, including sending to request.self, or > logging<BR>potential hack > > attempts > > ---><BR>�<!--- <cflocation url="#self#" addtoken="no"> > > ---><BR></cfif></DIV> > > <DIV>�</DIV> > > <DIV>�</DIV> > > <DIV>And when exactly is LeeBB heading west? I'll certainly > want to be > > on the "buy him a beer or two" list for the magic he contributes to > > the FB community.<BR><BR>Nev</DIV> > > <DIV>�</DIV> > > <DIV>�</DIV> > > <DIV>>>> [EMAIL PROTECTED] 04/24/02 02:53pm >>><BR>Hi > > Lee,<BR><BR>Knew I could count on you to help me out! But > then I guess > > > it's > > that<BR>time of the day when our Yank friends are > > slumbering.<BR><BR>What you're describing is exactly the method we > > were using before, but<BR>with cfcontent not > > cfinclude. However, there's a few things I need to<BR>keep in mind. > > Firstly, > > apart from changing the links to ".cfm" instead<BR>of > ".html", I don't > > > want to > > require anything else of the content guy.<BR>He's finding > it tough, I > > already made him use relative links instead of<BR>absolute > (his norm). > Secondly, > > I have > > recently found out that these guys<BR>consider their visitor > statistics > > to be > > vital, particularly exactly<BR>which pages are being requested most > > often. They are on shared hosting<BR>with LiveStats 5 and I already > > know from > > (painful) > > experience that it<BR>refuses to watch URLs the way it's meant to. > > <BR><BR>What I was wondering was if there is any other > amazing magical > way...<BR>like > > maybe > > passing the login status to the application.cfm in the<BR>content > > directory, but in a secure way somehow. I don't know. It's > been<BR>a > > long day, and > I'm > > out of > > ideas.<BR><BR>Thanks for your help, I owe you a beverage of your > choice. > > By the > > time<BR>you finally make it out to Perth I'm going to owe > you a lot of > > > those > > :)<BR><BR>K.<BR><BR><BR><BR>-----Original Message-----<BR>From: > BORKMAN > > Lee [<A > > > href="mailto:[EMAIL PROTECTED]]";>mailto:lee_Borkman@r > ta.nsw.gov > .au]</A> > > > > <BR>Sent: Wednesday, 24 April 2002 2:40 PM<BR>To: > > '[EMAIL PROTECTED]'<BR>Subject: RE: breaking out of an FB3-secured > > app<BR><BR><BR>Hi Kay,<BR><BR>If these "static" files are all > > stand-alone CFM templates, then you can<BR>CFINCLUDE them like any > > display fuse.<BR><BR>How > > about a fuseaction called "static.showfile" which takes the > > filename<BR>as > > input, and dynamically includes the appropriate static file?� > > Of<BR>course, > > you'd need to resolve any links within the static content.<BR><BR>Is > > that the > > kind of thing you have in mind?<BR><BR>LeeBB<BR><BR>-----Original > > Message-----<BR>From: Kay Smoljak [<A > > > href="mailto:[EMAIL PROTECTED]]";>mailto:[EMAIL PROTECTED]] > </A><BR><B > R>Hi > > > > all,<BR><BR>I have an interesting problem - well I think it's > > interesting anyway. I<BR>have an FB3 app for a subscription-based > > content site. My > > > app > > handles<BR>all the subscriptions, payments, logins, logouts, > > permissions, updating<BR>of details, forgotten passwords > etc etc. The > > protected content, > > which<BR>someone non-CF handles, is static html. It was going to be > > stored<BR>outside of the web root, but during testing the > performance > > was > > quite<BR>bad, so I've decided to make the HTML person name all his > files > > .cfm > > and<BR>store them in a particular directory within the web root. > > <BR><BR>What I don't know is how I'm going to have access to these > files<BR>controlled > > by my > > FB3 app, without requiring them to be in in the > FB3<BR>framework. Has > > anyone done anything like this before? Any ideas?<BR><BR>Thanks in > > advance,<BR>Kay > > > > > > _____________________________________________________________________ > This message has been checked for all known viruses by UUNET > delivered > through the MessageLabs Virus Control Centre. For further > information visit http://www.uk.uu.net/products/security/virus/ > _____________________________________________________________________ This message has been checked for all known viruses by UUNET delivered through the MessageLabs Virus Control Centre. For further information visit http://www.uk.uu.net/products/security/virus/ ==^================================================================ This email was sent to: [email protected] EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^================================================================
