Hmm... so it doesn't matter if the client var tables weren't set up on the actual server itself? That's easy then!
-----Original Message----- From: Tim Heald [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 24 April 2002 3:48 PM 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:[EMAIL PROTECTED] .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 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 ==^================================================================
