I've considered doing something along similar lines, the reason being to
mask the identity of various fuseactions.
I was thinking of creating some sort of hash table routine, with an
hourly/daily/whenever_you_panic scheduled routine to:
1.) stop client access to the app
2.) generate new hashes.
3.) do a global find-n-replace through the entire app.
4.) restart client access to the app.
The index.cfm file of the app would start with a call to take the current
hashed fuseaction, and retrive the unhashed fuseaction name from the db.
My situation is such that our current security is not so critical that this
is deemed necessary, so I didn't develop the idea beyond concept. It also
looked like a pretty big hit on performance to me.
Alan McCollough
Web Programmer
Allaire Certified ColdFusion Developer
Alaska Native Medical Center
> -----Original Message-----
> From: Patrick McElhaney [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, January 18, 2001 10:28 AM
> To: Fusebox
> Subject: Store Fuseactions in a Variable/Database
>
> Has anyone ever considered the idea of, rather than
> using a lengthy cfcase statement, storing fuseactions
> in variables?
>
> i.e.
>
> <cfif isDefined("application.fuseactions")>
> <cflock type="readonly" scope="application">
> <cfset request.fuseactions = application.fuseactions>
> </cflock>
> <cfelse>
> <cfscript>
> request.fuseactions["dothis"] = "act_doThis.cfm,dsp_showthat.cfm";
> request.fuseactions["dothat"] = "act_doThat.cfm,dsp_showThat.cfm";
> </cfscript>
> <cflock type="exclusive" scope="application">
> <cfset application.fuseactions = request.fuseactions>
> </cflock>
> </cfif>
>
> <cfloop list="#request.fuseactions[attributes.fuseaction]#" index="page">
> <cfinclude template="#page#">
> </cfloop>
>
> I'm sure I've seen someone do this, but can't find the post
> where I saw it. I've been thinking about it for a couple of
> days now and it's really starting to grow on me -- especially
> now that I'm starting to look at Fusebox less as a standard
> for CF coding, and more as a useful pattern for web
> development in general.
>
> The next step beyond this would be to take out the code
> altogether and store the information about fuseactions in a
> database or CFML file. I'm still stuck on the idea that the
> core of Fusebox should be wrapped up in a single tag (which
> almost everyone would customize), which would make this
> even easier to implement. Why write the same code over and
> over?
>
> I can see a lot of applications here that would take Fusebox
> to the next level. For example, we could turn fuses on and
> off like, well, circuit breakers. We could easily secure
> certain fuseactions via a simple admin tool that manipulates
> a database. We could make changes to live, production code
> without causing downtime by writing to the index.cfm file.
> We could even add in workflow features.
>
> What do you think?
>
> Patrick
>
>
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
