TIP: application.cfm usage
Chris Pearce
(eg: c:\inetpub\wwwroot\) for an "application.cfm" file.
In fact ColdFusion will continue looking all the way up to the servers root
directory (eg: c:\) to find an application file.
Remember this in multi-site installations of ColdFusion as unpredictable
events could occur.
Cheers!
Peter Tilbrook
ColdFusion Applications Developer
http://www.coldgen.com
stark
wrote:
So how then does this work in an application written using the Fusebox
methodology? I'm planning to use this on a new project and I heard the
same thing myself, causing me to pause. In Fusebox they use CFINCLUDE
to include a file called either "app_locals.cfm" or "app_globals.cfm"
depending on whether the calling template is part of the main
application or a circuit application. Nowhere in the documentation on
Fusebox.org does it say anything about application.cfm, except to not
use it because it doesn't get processed in CFMODULEs...
Jim Davis
application.cfm at the root of your application.
An application.cfm with a comment saying: <!--- I'm a fuseboxin'! Neener,
neener neener! ---> will eliminate the possibilty of picking up an external
one and speed up the application by eliminating the search for one (which
happens on EVERY template call).
Jim Davis
--
President, Depressed Press of Boston: http://www.DepressedPress.com/
Webmaster, Virtually Boston: http://www.vboston.com/
Webmaster, First Night Boston: http://www.firstnight.org/
Senior Consultant, Metlife eCommerce IT: http://www.metlife.com/
"stark" <sp...@nothere.com> wrote in message
news:biknst8kto7405b9c...@4ax.com...
Rod Serling
I'm not sure why you have those ideas about fusebox.
The Application.cfm file is very much a part of fusebox design.
The fusebox.org site's code is freely download-able.
Here's the Application.cfm they use in their root:
<!--- <b>Please try again shortly I'm upgrading the site</b>
<p>
<!--- <cfquery name="releaseDSN" datasource="fusebox">
select * from unlockdb
</cfquery> --->
<cfabort> --->
<cfif findnocase("cfm",cgi.CF_TEMPLATE_PATH) and not
findnocase("index.cfm",cgi.CF_TEMPLATE_PATH)>
<cflocation url="index.cfm?badfile=yes">
</cfif>
<cfsetting enablecfoutputonly="no">
<CFERROR TYPE="EXCEPTION" EXCEPTION="any" TEMPLATE="act_error.cfm">
<cf_formURL2attributes
displaybase="no">
<cfinclude template="app_server.cfm">
<cfinclude template="app_key.cfm">
<cfapplication name="fusebox" clientmanagement="yes"
setclientcookies="no" applicationtimeout="#request.timespan#">
<cfset request.urltoken=client.urltoken>
<cfset request.headerfile="#request.cfroot#/blocks/dsp_header.cfm">
<cfset request.footerfile="#request.cfroot#/blocks/dsp_footer.cfm">
<cfparam name="request.skiplist"
default="/members/index.cfm|logout=yes|rememberme=|/search">
<cfinclude template="members/act_logout.cfm">
<cfsetting enablecfoutputonly="no">
<cflock scope="application" timeout="30" type="readonly">
<cfset runrequest="no">
<cfif not isdefined("application.runrequest")>
<cfset runrequest="yes">
</cfif>
</cflock>
<cfif runrequest>
<cfquery name="variables.getstates" datasource="#request.maindsn#">
select * from states
</cfquery>
<cfset variables.statestruct=structnew()>
<cfloop query="variables.getstates">
<cfset variables.statestruct[state_id]=currentrow>
</cfloop>
<cflock scope="application" timeout="30" type="exclusive">
<cfset application.getstates=variables.getstates>
<cfset application.statestruct=variables.statestruct>
<cfset application.runrequest="no">
</cflock>
</cfif>
<cfif isdefined("client.user_id")>
<cfquery name="request.getuser" datasource="#request.maindsn#">
select *
from users
where user_id=#val(client.user_id)#
</cfquery>
</cfif>
RS
stark <sp...@nothere.com> wrote in message news:<biknst8kto7405b9c...@4ax.com>...
stark
wrote:
>Hi Mike,
>I'm not sure why you have those ideas about fusebox.
>The Application.cfm file is very much a part of fusebox design....
According to the documentation that they have available (Fusebox
Version 2.0 - Large Scale Applications (March 10, 1999, Steve Nelson):
"Technique 4: Application.cfm will _not_ be used. Why? because when a
file is called through a tag (using CFMODULE) the Application.cfm file
does not get called. Instead there are two applications files in a
Fusebox application. app_locals.cfm will be CFincluded at the top of
the index.cfm. app_globals.cfm wil be included in the app_locals.cfm
file...(cut)"
This is what has been confusing me. Has this been changed with the new
version of Fusebox? Is there any definitive text out there which goes
over all the latest conventions and practices regarding Fusebox?
Adam Cameron
>file is called through a tag (using CFMODULE) the Application.cfm file
>does not get called.
I've never understand why they keep banging at this one: it's about as
sensible as them saying "monkeys will not fly out of your butt when
you use a CFMODULE call".
OF COURSE application.cfm doesn't get called for a CFMODULE (oh, and
that monkey thing, too, for those that are worried ;-). Why the
*hell* would it? application.cfm is called at the beginning of the
request. Plain and simple. A CFMODULE call is not a request unto
itself.
And having said that, if you *must* refer to things set in the
application.cfm template, what's wrong with using request. or caller.
(depending on which is most apt for the situation). And isn't the
whole idea of CFMODULE to abstract reusable code? The why would one
by trying to rely on caller (or request, for that matter) scoped
variable in a custom tag anyhow. A custom tag *should* be a black
box.
Is there some way of calling a CFMODULE template other than from
another template (which itself would initiate the request and a call
to application.cfm)?
I see this as a non-issue.
Am I missing something? (Serious question).
Adam
Isaac Dealey
Application.cfm ... In an application I've worked on for a while now,
I use <cfinclude template="../application.cfm"> to accomplish the same
thing that they accomplish by using <cfinclude
template="../app_globals.cfm"> in their app_locals.cfm module for
their circuit apps...
I can only _imagine_ that what they were referring to re: cfmodule
calls was that if you put your custom tags in a subdirectory of the
root of the application and call them using <cfmodule
template="subdirectory/customtag.cfm"> that any Application.cfm file
in that subdirectory will not be processed -- which to me is a good
thing, and I wouldn't be putting an application.cfm module in that
directory anyway...
But then again, the FuseBox book itself, in the first few pages iirc
says words to the effect of "FuseBox ignores custom tags all-together
and will say nothing, good, bad or ugly about them. We will not define
any parameters for the use or exclusion of custom tags, whatsoever. If
you want to use custom tags (or not) we will offer no advice." ... so
this makes the comment re: the application.cfm module even more
strange, since they've already said that FuseBox has nothing to do
with cfmodule calls...
The only advantage that I can glean from not using Application.cfm is
that you have the ability to store base modules in the same directory
or in a subdirectory _without_ an Application.cfm file which _don't_
process all the application.cfm code which finds its way into the
app_globals.cfm or app_locals.cfm files...
The most obvious use of this to me is the login page... If you use
Application.cfm to determine if the current user is logged in and
redirect them to the login page if they're not, then you have to check
the current path in the Application.cfm to make sure the user isn't
looking at the login page, otherwise you wind up with an infinite loop
-- user not logged in -- go to login -- login page -- user not logged
in -- go to login... and so on...
If you use app_globals.cfm instead of Application.cfm you don't have
to verify that the user isn't on the login page before redirecting
them to the login page, simply by discluding the app_globals.cfm from
the login page in the first place... and this eliminates a sometimes
confusing bit of code...
But other than that, I can't really see any advantage to not using
Application.cfm...
Isaac Dealey
new epoch
Adam Cameron
>to verify that the user isn't on the login page before redirecting
>them to the login page, simply by discluding the app_globals.cfm from
>the login page in the first place... and this eliminates a sometimes
>confusing bit of code...
The only thing I'd add to that is that is you don't do login
validation in your application page, it's conceivable that someone
could go straight to a template - bypassing index.cfm - without
logging in. However in my experience they're not likely to get too
far as a template by itself is not likely to work without various
variables being set / passed / etc. But it's something to be mindful
of.
We "always" use application.cfm for our forcing-login, and - as you
say - check to see whether the user is already "en route" to the login
page before sending them to the login page again (if you see what I
mean). It's just one <cfif>.
Adam
Roger B.
>>Hi Mike,
>>I'm not sure why you have those ideas about fusebox.
>>The Application.cfm file is very much a part of fusebox design....
[snip]
>This is what has been confusing me. Has this been changed with the new
>version of Fusebox? Is there any definitive text out there which goes
>over all the latest conventions and practices regarding Fusebox?
Mike,
Application.cfm really only has one useful purpose in an FB app...
it's a handy place to put a couple lines of code that trap calls to
templates other than index.cfm, thus preventing anyone from calling
your dsp_ or act_ files directly from a browser.
--
Roger
Roger
======
http://www.section12.com/ - a BDSM community: free email, boards, chat
http://www.bdsmtalk.com/ - featuring the BDSMtalk Open Directory
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
Check out our new Unlimited Server. No Download or Time Limits!
-----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
Roger B.
<da_ca...@hotmail.com> wrote:
>Am I missing something? (Serious question).
Adam,
Yep. But it can be easy to miss... lots of FB adherents don't even get
it.
Because all requests in a Fusebox app are routed through index.cfm,
the entire functionality of such an app can be accessed via the custom
tag interface. For example, take a forum application and its list of
recently updated threads. You might call it via the browser with:
index.cfm?fuseaction=getNewMessages
But another CF app running on the same server could call the forum app
directly, like this:
<cfmodule template="index.cfm" fuseaction="getNewMessages">
That's where the avoidance of application.cfm comes in. Standard CF
practice is to set important request/application/session/client
variables in application.cfm, but if you try that with Fusebox and
call the app as a custom tag, none of those variables will be set...
this would obviously be A Bad Thing.
Same thing goes for the way Fusebox apps copy all url- and form-scoped
variables into the attributes scope... the practice makes it possible
to seamlessly expose a stand-alone app's guts.
--
Roger
Roger B.
<da_ca...@hotmail.com> wrote:
>Am I missing something? (Serious question).
Adam,
Roger B.
<da_ca...@hotmail.com> wrote:
>Am I missing something? (Serious question).
Adam,
Jochem van Dieten
> Application.cfm really only has one useful purpose in an FB app...
> it's a handy place to put a couple lines of code that trap calls to
> templates other than index.cfm, thus preventing anyone from calling
> your dsp_ or act_ files directly from a browser.
Also best place to do last-resort error trapping with cferror
Jochem
Adam Cameron
>Adam,
>Yep. But it can be easy to miss... lots of FB adherents don't even get
>it.
>
>Because all requests in a Fusebox app are routed through index.cfm,
>the entire functionality of such an app can be accessed via the custom
>tag interface. For example, take a forum application and its list of
>recently updated threads. You might call it via the browser with:
Aha! Clean forgot about that (never having done it or had call to do
it will cause that, I guess).
Good call.
Adam
Rod Serling
security-enforcing code such as this than in application.cfm? Unless
there's a better idea out there, then I'd say this is also information
that could/should be in application.cfm (or an include thereof).
<CFIF (CLIENT.LOGGEDIN IS "FALSE")
AND (CGI.Query_String IS NOT "")
AND (CGI.Query_String IS NOT "fa=Login")
AND (CGI.Query_String IS NOT "fa=LoginProcess")
AND (CGI.Query_String IS NOT "fa=Home")
AND (CGI.Query_String IS NOT "fa=Password")
AND (CGI.Query_String IS NOT "fa=PasswordProcess")>
<SCRIPT LANGUAGE="JavaScript">
alert("Session has expired. Please log in again.");
self.location='index.cfm?fa=Login';
</SCRIPT>
</CFIF>
Jochem van Dieten <nom...@dev.null> wrote in message news:<3BD6E0D4...@dev.null>...
Isaac Dealey
>
> Because all requests in a Fusebox app are routed through index.cfm,
> the entire functionality of such an app can be accessed via the custom
> tag interface. For example, take a forum application and its list of
> recently updated threads. You might call it via the browser with:
>
> index.cfm?fuseaction=getNewMessages
>
> But another CF app running on the same server could call the forum app
> directly, like this:
>
> <cfmodule template="index.cfm" fuseaction="getNewMessages">
>
> That's where the avoidance of application.cfm comes in. Standard CF
> practice is to set important request/application/session/client
> variables in application.cfm, but if you try that with Fusebox and
> call the app as a custom tag, none of those variables will be set...
> this would obviously be A Bad Thing.
This is great insight -- too bad the mention of it seemed to go
completely unexplained in the FuseBox book...
Hmmm.... It's a great idea for circuit-apps, although for the most
part, a root app will never be called as a custom tag / used as a
circuit app like this, i.e. the root app where all of your html
headers with banner ads, and footers with copyright info get placed --
although, I suppose these are probably included in the index.cfm in
most cases, but if you _NEVER_ access anything other than index.cfm
directly, then it seems to me there wouldn't be any significant
difference between the application.cfm and the app_globals.cfm accept
that you still have to <cfinclude template="../app_globals"> in a
subdirectory... But even if you're calling a circuit app as a custom
tag, i.e. <cfmodule template="circuit/index.cfm"
fuseaction="getNewMessages"> then what's wrong with using
<cfif isDefined("CALLER")>
<cfinclude template="application.cfm">
<cfelse>
<cfloop item="x" collection="#URL#">
<cfset Attributes[x] = URL[x]>
</cfloop>
</cfif>
at the top of the index.cfm? One way is an extra include tag if you're
not calling a custom tag, the other way is an extra include tag if you
are calling a custom tag... and hopefully nobody ever makes the
boneheaded mistake of defining a form or url variable called
"CALLER"... hmmm.... speaking of which... perhaps it's a good idea to
use a cached UDF to copy form and url variables to the attributes
scope... It should be significantly faster than a custom tag -- which
may not matter much for a single request, but could provide a decent
performance gain for a server receiving a high volume of traffic... In
any event -- I haven't been using the attributes scope, although I use
the fusebox naming conventions ... That's probably largely because I
haven't really been building circuit apps... I use the FuseAction
variable and the cfswitch tag, but often in documents not titled
index.cfm or Default.cfm...
Isaac Dealey
> Is there any better place than application.cfm (or method) to include
> security-enforcing code such as this than in application.cfm? Unless
> there's a better idea out there, then I'd say this is also information
> that could/should be in application.cfm (or an include thereof).
>
> <CFIF (CLIENT.LOGGEDIN IS "FALSE")
> AND (CGI.Query_String IS NOT "")
> AND (CGI.Query_String IS NOT "fa=Login")
> AND (CGI.Query_String IS NOT "fa=LoginProcess")
> AND (CGI.Query_String IS NOT "fa=Home")
> AND (CGI.Query_String IS NOT "fa=Password")
> AND (CGI.Query_String IS NOT "fa=PasswordProcess")>
>
> <SCRIPT LANGUAGE="JavaScript">
> alert("Session has expired. Please log in again.");
> self.location='index.cfm?fa=Login';
> </SCRIPT>
>
> </CFIF>
This isn't really related to the original subject of this thread, just
thought I'd comment ...
I originally used something similar to this for processing login
information, however, I found that, at least for my purposes, using a
<cftry> block around a set of code that coppies user information from
the client, session or application scope to the request scope and
validates a few simple variables was a lot simpler to develop... It
eliminated the need for a lot of complicated code, such as the extra
AND's in the cfif statement here... And ideally (at least in my
experience), login processing shouldn't occur in the default or
index.cfm page, especially in a fusebox application -- unless you put
the index in a circuit-app sub-directory, in order to reduce the
amount of extra "what if, what if, what if" processing you have to do
in order to have global processing in the application.cfm,
app_globals.cfm or index.cfm outside of the fuseaction switch ... When
the user's session expires, I just show an alert box, log them out and
<cfthrow> to redirect them back to the login page...
Isaac Dealey
new epoch
Rod Serling
this case.
The code below resides in application.cfm and just checks every page
request to make sure the user _is_ logged in, and if not, boots him to
a login page.
The IFs just act to say "Unless you're at a pre-login page, you're
CLIENT.LOGGEDIN must be positive." If they don't meet the criteria,
like your code, it logs them out, throws an alert box, and directs
them to log in again.
In the interests of evaluating the best way to maintain app security,
could you post some of the code you're using?...i'm interested in
comparing the code listed below to a system involving CFTRY and
CFTHROW...
Since both methods look at a login variable, analyze it, and boot you
if it doesn't meet conditions, I suspect they're pretty similar. But
I'm always eager to jump ship to the best solution.
RS
in...@turnkey.to (Isaac Dealey) wrote in message news:<add22df9.01102...@posting.google.com>...
Michael Camm
Fusebox 1.0 didn't want you to use application.cfm because it doesn't
get called if you use CFMODULE to *** call another fusebox or circuit
as a custom tag ***.
Big difference there. Whereas the use of "custom tags" is neither
here-nor-there; it is very important to be able to call other circuit
apps as if they were "custom tags"
So picture this:
- You made a FUSEBOX 1.0 site with APPLICATION.CFM
- You made a circuit that emailed your shopping list to a person.
- Its called /shoppinglist/index.cfm?fa=mailthis
- In the home application, you'd be fine, because the APPLICATION.CFM
sets the application.dsn to the name of your datasource.
Now suppose you wanted to REUSE that circuit from a different fusebox:
- you would :
<cfmodule
template="shoppinglist/index.cfm
fa=mailthis">
and the template would crash because the APPLICATION.CFM wouldn't fire
and establish the variable "application.dsn".
- If you had CFINCLUDED the appvars_global, it would have established
your application variables and worked.
Fusebox 2.0 is, in my opinion, completely different.
Every Circuit App is tied together with a CIRCUITS.CFM and another
custom tag with some fancy scripting. This scripting (courtesy of Hal
Helms) makes it so that your application variables can "cascade"
through however many levels deep you made your application. All of
the application variables are also CFPARAM'd not CFSET. This way
necessary variables don't get overwritten, but all necessary variables
get set. This being the case - there is no problem using
APPLICATION.CFM.
Hope that helps.
Michael
On Wed, 17 Oct 2001 06:01:40 GMT, stark <sp...@nothere.com> wrote:
Roger B.
>This is great insight -- too bad the mention of it seemed to go
>completely unexplained in the FuseBox book...
That's one of the love-it-or-hate it aspects of the Fusebox
community... the fundamentals get glossed over and forgotten in books
and whitepapers for the sake of the folks who just want someone to
tell them how to write their code.
There are an amazing number of people out there less interested in
"why" something is done than in whether or not they're "doing it
right." And for good or ill, those people are a big part of the book's
audience.
>Hmmm.... It's a great idea for circuit-apps, although for the most
>part, a root app will never be called as a custom tag / used as a
>circuit app like this...
I do just that all the time... instead of calling circuits directly, I
let the root index.cfm play the role of traffic cop, directing
requests to the necessary circuits via CFMODULE.
> ...i.e. the root app where all of your html
>headers with banner ads, and footers with copyright info get placed...
Those are easily turned off in the most basic of app_layout files...
there isn't automatically anything special about the root of a
Fusebox, other than the fact that it happens to be, well, the root. :)
>...but if you _NEVER_ access anything other than index.cfm
>directly, then it seems to me there wouldn't be any significant
>difference between the application.cfm and the app_globals.cfm...
Absolutely. If you're 100% certain that you'll never call an FB app
via CFMODULE, then the need for app_globals decreases substantially.
Ditto for the unified attributes scope, although I find it valuable
for other reasons. FB is a handy methodology, even reduced to nothing
more than a big CFSWITCH/CFCASE.
But to me, one of Fusebox's greatest strengths is the fact that it
takes advantage of CF's custom tag interface to provide a method of
seamlessly integrating FB and non-FB apps. So on all but the smallest
projects, I stick to app_globals and attributes.
>...what's wrong with using
>
><cfif isDefined("CALLER")>
> <cfinclude template="application.cfm">
If you're building a single-circuit Fusebox, there's nothing wrong
with it. As long as you're aware of the CFMODULE issue, how you
address it is a matter of personal taste, IMO. (Others may disagree
with that sentiment... many FB folks are big believers in rigid
standardization.)
For my part, my application.cfm seldom contains anything but:
<cfif #ListLast(GetTemplatePath(),'\')# is not "index.cfm">
<cflocation url="/index.cfm">
</cfif>
...which keeps the bored and/or curious from calling dsp_ and act_
files directly.
>perhaps it's a good idea to
>use a cached UDF to copy form and url variables to the attributes
>scope... It should be significantly faster than a custom tag...
No doubt. Some of us aren't using CF5 yet, though. :)
Roger B.
wrote:
>Is there any better place than application.cfm (or method) to include
>security-enforcing code such as this than in application.cfm?
"Better" is a judgement call, but I'd definitely put it elsewhere.
Based on your example, I'd have an index.cfm that looked something
like this:
<cftry>
<cfswitch expression="#attributes.fa#">
<cfcase value="Login">
<cfinclude template="app_secure.cfm">
<cfinclude template="dsp_foo.cfm">
</cfcase>
<cfcase value="LoginProcess">
<cfinclude template="app_secure.cfm">
<cfinclude template="dsp_foo.cfm">
</cfcase>
<cfcase value="SomethingElse">
<cfinclude template="dsp_foo.cfm">
</cfcase>
</cfswitch>
<cfcatch type="nologin">
<!--- handle the lost session --->
</cfcatch>
</cftry>
...with an app_secure.cfm containing this:
<CFIF (CLIENT.LOGGEDIN IS "FALSE")>
<cfthrow type="nologin">
</cfif>
Using this method, you can choose which fuseactions to secure by the
simple inclusion or omission of app_secure.cfm. In the above example,
you can tell at a glance which fuseactions are secured and which
aren't... one of the great things about FB is that it can provide you
with an effective roadmap of your entire app.
--
Roger