ColdFusion 10 New Automatic (Sort-of) Update Process

Posted on March 13, 2013

This is an email entry submitted by Charlie Arehart in regards to the new CF10 Update Processes. Charlie points out information that may not be obvious to the average CF developer.

Posted to ACFUG Discussion Mail list on 03/06/2013:

As you may know, some of the CF10 updates DO require a rebuild of the connectors, while others do not. (Even more subtle is that for some of the updates it would suffice if one only used the –upgrade argument from the command-line wsconfig tool, which is faster, while other of the updates do require a full remove/re-add of the connector(s), whether using the command-line or GUI wsconfig tool.)

To your point, Cameron, I don’t think the latest couple have required any tweak of the web server config, but some earlier ones did.

And my point below was focused on that: for someone who is “migrating to 10” (Bettina’s topic), who therefore doesn’t have CF10 installed at all, they need to know that if they install it, they then have to do the “mandatory” update first, and then apply the latest update (8, for now, as they are said to be cumulative). It’s because those earlier ones would be included in that, that one would need to do the rebuild of the web server connectors as a last step. Make sense now?

In fact, some may notice that the hotfix notices have recently just said on each of update that one should redo the connectors. That’s kind of a “punt”, since as you note, it’s not really required for each update. My sense is that they only have space for (or only want to write) a few sentences there, so they are not explaining all these details (that it’s technically only needed depending on whether you’re including one of the earlier updates that DID require it).

For those really interested, I’ll add that I think there are pros and cons to this blanket assertion they now make in each update to rebuild the connectors.

On the one hand, an argument could be made that it’s better that they DO say to rebuild it with each, because otherwise someone who DID do a later one which included those earlier ones (that did require a rebuild), but who DID NOT do that rebuild, might then have problems caused simply by that failure to rebuild. (I’ve seen it happen a LOT! And often people are moaning about CF10 sucking when it’s this very issue. Or they thought did the rebuild, but it didn’t really happen for some reason.)

On the other hand, there’s a potential negative implication to “just having everyone do the rebuild on each CF10 update”. As you may already have in mind, Cam, it takes time. More specifically, though, the rebuild causes CF to remove and then add back the CFIDE virtual directory (which CF10 now always adds) in the site(s) that were connected to CF with that connector. What’s so wrong with that, some may ask? Well, two things.

First, if someone had applied the recently popularized security tweaks to secure (in the web server) the subdirectories of that CFIDE folder (like adminapi, administrator, and componentutils), such as adding IP and domain restrictions or requiring additional web server authentication, those tweaks are lost on the rebuild (since the tweaks are at the folder level, and lost when the CFIDE virtual directory is removed and added back by CF). (Fortunately, for those on IIS 7+, using the request filtering approach to block access to those dirs, those settings are NOT stored at the folder level but rather at the server and site levels.)

A second problem (with “just rebuilding the connectors after each update”) is that if one chooses to connect CF to “all sites” in the web server, then CF will add back a CFIDE folder to all sites–whether they are ones where a CFIDE was desired or not. Some folks have specifically removed the CFIDE from sites that they feel don’t need it (though hopefully they are not assuming it’s needed only for the CF Admin, as the CFIDE/scripts directory is also used by HTML code from many CFML tags!) Anyway, if someone DID intend that a given site would not have a CFIDE, so they removed it, and they rebuild the connector for “all sites”, that will then add the CFIDE BACK to that and all the other sites. And now the vulnerability caused by those admin dirs. being publicly accessible would be opened up again, if they were relying on folder-level protections that would now need to be added back. (Again, someone using IIS request filtering WOULD be protected in this case. And perhaps Apache also offers an approach that would not be affected by a connector rebuild.)