We just had an interesting problem here at work. We are building an eCommerce site that needs to be shut down on certain days. Normally, this would not be a problem - we'd just put some code in the Application.cfm or Application.cfc that would check the date on each request and either render the normal page or render a "Closed" page. The problem that we came up against was that we are implementing an existing software product in which the Application.cfm file is encrypted. This means that we can't go into the file and simply add the desired functionality.
At first, I wasn't sure what to do, but then something dawned on me: the Application.cfm code does NOT need to be in an Application.cfm. Well, ultimately it does, but the code itself doesn't have to be located in a file named Application.cfm. So, what we did was rename the existing, encrypted Application.cfm to be named "EncryptedApplication.cfm". Then, we created a new Application.cfm that simply included the old Application.cfm file:
- Include the template that handles the functionality and
- display of the "Sorry, We're Closed" page.
- <cfinclude template="site_down.cfm" />
- <!--- Include original Application file. --->
- <cfinclude template="EncryptedApplication.cfm" />
This way, our "site_down.cfm" template can execute on every page request and prevent the page load, if needed. And, we don't lose the functionality of our original Application.cfm file.
Small tip, but I thought this might inspire people who are working with any off-the-shelf products that have encrypted files.
Looking For A New Job?
Ooops, there are no jobs. Post one now for only $29 and own this real estate!
Remember that if a directory contains both Application.cfc and Application.cfm, only the CFC is run. So another option would have been to use onRequestStart() in Application.cfc. This would just avoid renaming the existing Application.cfm
Can't you just unencrypt it? The same exe that's worked since CF5 still works doesn't it?
Then we would have lost all of the functionality of the Application.cfm. But yes, if we built this thing form scratch, I would go with OnRequestStart().
I'm curious: if you're allowed to say, why do they want their eCommerce site shut down on certain days?
Most online vendors tremble at the thought of their ordering system being down for even an hour or two, lest they miss a sale.
Ah ya, the ever elusive terms and conditions... Sorry didn't realize this was a paid for app, I was just assuming this was something a prior developer did because they thought it would help.
Technically speaking, hasn't encrypting cfm files pretty much been a worthless security effort since about 99-00?
It's for religious reasons. There are certain days / times were the client is not supposed to be actively making money.
Yeah, sorry I was not clear on that. But, definitely, encrypting the file really does nothing. I (and I assume many others) have that CFDecrypt.exe program :)
I'm going to use this trick next time my wife is mad because I wasn't paying attention: "I wasn't ignoring you, honey! I was just cfincluding your conversation, which allows me to do what I'm working on now while still taking in your most excellent and awe inspiring wisdom."
Ha ha ha ha :)
<cfinclude template="Application.cfm" />
<!--- yadda yadda yadda --->
Just a thought but couldn't you add an OnRequestStart.cfm to your app which checked the date as you're using Application.cfm?
Good thought, but unfortunately, the two don't jive well together:
Is there an OnRequestStart.cfm? Or do you mean like a custom page in the app?
Sorry, Commented a bit too late last night (on UK time)! I meant that you would probably need to put the cfinclude that Adrian suggested in the OnRequestStart method of Application.cfc
Do you know of any way to use this trick to "extend" Application.cfm (analogous to what Application.cfc lets you do?)
e.g. you have:
/root/Application.cfm (general application stuff)
/root/mySubSection/Application.cfm (want to include root Application.cfm along with some sub section specific stuff.)
I tried <cfinclude template="/Application.cfm" /> but that did not have the desired effect.
Maybe use a relative path:
<cfinclude template="../Application.cfm" />
What error is it giving you?
Thanks! Using a relative path worked perfectly.
When I used an absolute path I was getting CF debug output in the content panel of the page - that may be specific to our Application.
You can't always decrypt CFM files anyway. I have a product I'm using, and some of the key components are encrypted with some sort of key, or hash or something, and running it through any of the decryption software just does nothing.
So, this post helped me greatly in modifying something encrypted.