Bindings not Working on ColdFusion Server

cache web paths option + Adobe CF logo

Just a quick note here. If you are running ColdFusion and you know that your bindings are set up correctly, but web requests being sent to the default root of websites on your server other than the intended one, it it highly likely that the “Cache web server paths” option was mistakenly (or unwittingly) set, causing all manner of havoc in directing among multiple sites.

CFCaching Web Server Paths option

Turn it off, restart the ColdFusion Application Server service, and enjoy proper web routing once again!

Scheduled Tasks and Anonymous Access in ColdFusion 11

ColdFusion Scheduled Task setup form

I have been converting applications from ColdFusion 8 to CF 11 over the last several months, and some of the challenges have been quite a bit more daunting than this one. Even so, I felt this was worth mentioning.

After copying all the code for my most recent upgrade candidate from the old server to the new one and setting it up in IIS, I proceeded to set up the CF Scheduled Tasks on the new server.

One of the tasks that I set up runs under a blank user name. In order for that to work, you have to make certain that several settings related to authentication are set properly in IIS. First of all, if the app as a whole runs under anything other than Anonymous Authentication (such as Windows Integrated Authentication or Forms Authentication), your Scheduled Task URL will have to be inside a folder that has Anonymous Authentication enabled, even if it’s turned off for the rest of the app.

Secondly, you have to make sure that the “jakarta” virtual folder that is set up during IIS configuration of the website also has Anonymous Authentication enabled.

Having Anonymous Authentication disabled on the jakarta folder will cause no end of irritation if you don’t have the output of the URL sent to a file, as neither the application log file nor the Security log in Windows Event Viewer will tell you exactly why the task is failing. If you send output to a text file, you can rename that text file with an HTML extension (I’m still not sure why Adobe doesn’t just allow output as HTML for this…) and then see more clearly why your task was failing.

IIS authentication error

So set your authentication properties correctly to avoid this frustration!

Changes in the ColdFusion.window.create Function Require a Modern Browser

error dialog box

I’m still working on upgrading some older CF8 applications to CF11. I came across an interesting problem, the exact cause of which I have not found, but I do have a solution of sorts.

When the particular application I’m working on now was written, the standard browser that would be accessing it was Internet Explorer 8. Over time, as we have upgraded our browsers, but not had time to make changes to the application to accommodate those new browsers, we had used the dreaded Compatibility View to keep the look and feel of the application unchanged.

Since we are now several versions out from CF8, it is understandable that some things intrinsic to ColdFusion have changed. Somehow, the way that the function ColdFusion.window.create renders JavaScript to create the pop-up window does not work with IE 8 or a newer browser emulating IE 8 (as we forced with the X-UA-Compatible HTTP header in IIS). After copying the website to the CF11 server, setting up everything in IIS, and navigating to the website, everything was great until I clicked on a link that executed a function (named “createCFWindow”, as in the dialog box below) that called the ColdFusion.window.create function.

This is the result:

error dialog box

After stepping through the code using Internet Explorer’s Developer Tools, I determined that the reason this “createCFWindow” function threw an exception was because the ColdFusion.window.create function was returning null rather than a new window.

When testing the website on Chrome – which this application was not designed to use – I discovered that the error did not occur, and decided to turn off Compatibility View. Sure enough, this error disappeared in IE 11 – though a host of other issues have now developed.

Now, I’m working to upgrade the application to be HTML5-compliant so it will work on IE 11 or Chrome.

Apparently, using CF UI tags became unfashionable quite some time ago, but that type of advice isn’t always heard or heeded until long after it’s announced.

Any future applications I build will use jQuery instead for this sort of thing.