If you are hosting your application in a sandboxed environment, such as shared hosting, then you may find yourself coming up against the the following error, especially if your using FuseBox 5 which is what caused it in my case.

Security: The requested template has been denied access to C:\Inetpub\wwwroot\CFIDE\scripts\ajax\messages\cfmessage_en_US_.js.

There are 2 issues involved here.

1) This file doesn't actually exist, at least not on any servers I checked.

2) Your code wont have access to this path in a sandboxed environment.

Now the quick and easy solution to this (for the host) would be to add the above path to your default sandbox with READ permission so that all customers have access to it, even if the file is not there at least CF can look for it. But alas this is not possible as sandbox security is not this flexible and does not allow you to globally give access to paths in this way. Sadly you must explicitly put paths into each and every sandbox for each and every site. Why Adobe have still not addressed this I have no idea, as I have informed them of this issue since ColdFusion MX 6 as the same problem occurs with all paths that CF needs access to for certain tags, such as temp folders (for file uploads), the windows fonts folder (for cfdocument) etc.

Thankfully there is another solution, at least for those of us that do not actually need this file. It seems that the inclusion of this file is locale specific, so if you set your locale to UK then CF no longer tries to load this file and the error goes away.

SetLocale("English (UK)")

I have not tested other locales, but I am guessing here that different people will have different versions of that file depending on their installation locale. So because I am in the UK, perhaps I got the plain old cfmessage.js file, which seems to be the default. If your in the USA then perhaps you do have a cfmessage_en_US_.js.

This problem may also be specifically caused by FuseBox 5 setting the wrong locale somewhere in its core files, and the same may apply to other frameworks too. 

One of things I see a lot of in my various jobs and contracts is Content Management Systems (CMS), and they come all manner of shapes and sizes. The most common is where you are given nothing more than a textarea to edit your pages HTML content, some might implement a WYSIWYG editor such as HTMLAREA, TinyMCE or FCKEditor, but on the whole they are usually very simple and do not give the client any real control. Then you have the other end of the scale, where the CMS is so complex that no-one except the developer who wrote it knows how it works and even the client doesn't really know how to use it properly. 

One of common issues I have found with all the CMS systems I have worked on is "how to insert dynamic content". Dynamic content would be anything that is not static HTML and needs to be generated from code, whether it is just inserting a variable, including a file or calling a CFC. How do you allow this in your WYSIWYG HTML editor without having to insert actual code or rely on the client to do so or hard code routines between your content that the client has no control over, the answer is actually quite simple, lexicons (or macros to use a more generic term). All this really means is putting a placeholder in your HTML and at runtime substituting it with the code that generates the dynamic content, and even the code that does the substitution is not complex, so in this article I will be showing you how it's done.

Read more...

While investigating ColdFusion server stability issues I have recently discovered what I would consider a bug and a security issue with client variables.

As I am sure you know client variables can be stored in cookies, the registry or a database. The default storage method is the registry, but this is not suitable in many cases, especially on a shared server and should be changed. In such an environment you want to disable use of the registry and you do this with a security sandbox and deny use of the CFRegistry tag. This also means that trying to set client variables to be stored in the registry in the application.cfm would also fail with an access denied error,

E.G.

<cfapplication clientstorage="registry">

However, as I have now discovered this does not apply to application.cfc, which is still able to override the admin settings and the sandbox and is able to use the registry.

e.g.

<cfcomponent name="application.cfc">
<cfset this.clientStorage = "registry">
</cfcomponent>

I have tested and verified this on CF6,7 and 8 and the caveat of this is that if customers set this attribute in their application.cfc then the registry will be used and can easily fill up with client variables which can make the server unstable. Sadly it seems that some developers enable client variables and set the clientStorage=registry even if they are not using client variables, which results in a pointless waste of system memory and resources.

Currently the only way to avoid this problem is to deny access to the user under which ColdFusion runs  to the registry key where client variables are stored, which is

/HKLM/software/Macromedia/ColdFusion/CurrentVersion/Clients

I have just noticed something odd with ColdFusion 8 when you have security enabled in the enterprise edition.

CFinclude does not work by default and gives an access denied error. You *MUST* create a sandbox for every site in order for CFinclude to work.

The reason why this is so odd is because you cannot actually disable CFinclude even if you want to, as it is not included in the of enabled/disabled list of tags, it seems CF has just decided to disable it by default.

Now it turns out that CFinclude is also not sandboxable in CF6/7 either, but at least it worked by default without having to setup a sandbox.

I wonder why Macrodobe decided to exclude this tag? It is a security issue as it does provide filesystem access as it allows you to include a file from anywhere on the same drive as the template, or if using available mappings, anywhere on the entire server. Granted it is of limited use as you would also need cfcontent to easily make any file downloadable, but a clever developer could get around that.

I recently had the following error reported by a cfdeveloper member since upgrading to ColdFusion 8.

Security: The requested template has been denied access to
C:\Inetpub\wwwroot\CFIDE\scripts\ajax\messages\cfmessage_en_GB_.js.
The following is the internal exception message: access denied
(java.io.FilePermission
C:\Inetpub\wwwroot\CFIDE\scripts\ajax\messages\cfmessage_en_GB_.js read)

ColdFusion cannot determine the line of the template that caused this error.
This is often caused by an error in the exception handling subsystem.

Now the security error is partly to be expected as I use security sandboxes and this path is thus not allowed by default, but the unexpected thing is the path it is trying to use in the first place.

Now like any good host should, I do not use the default CFIDE folder as I do not want every web site to have access to the ColdFusion Administrator, so the path to my CFIDE folder is actually D:\wwwroot\CFIDE and this is where the virtual directory points to for each web site. As you can see ColdFusion 8 completely ignores this fact and is using the default C:\Inetpub\wwwroot\CFIDE instead, which seems like a bug to me.

So if you are running in a sandboxed or shared hosting environment then you need to consider this fact and will need to add the above path to your default sandbox or ask your host to do so.