[Looking for Charlie's main web site?]

Sep 2019 updates released for CF2018 and CF2016, with a strange twist

Note: This blog post is from 2019. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
Adobe has announced today Sep 24 2019 that there are new updates for CF2018 (update 5) and CF2016 (update 12).

As an update to this post, I have offered a new post, pointing out that many people are having problems with this set of updates here. So I would recommend folks hold off on applying it for now. I will update this (and that) if we hear new info from Adobe.

Beyond adding important security and bug fixes as seems typical, this update offers several new or changed features, as well as updated support for things (such as Java 12), as is also often the case.

Uniquely, though, this update is the first ever to require that you must first have updated to the PREVIOUS update before applying this new one. So those on CF2018 must first be on update 4 before going to this new update 5, while those on CF2016 must be first on update 11 before going to this new update 12.

As always, I share a bit more here, for my readers.

(FWIW, CF 11 received its last update in June 2019, when it and CF2018 and 2016 were last updated, as I posted then.)

The new update requirement is a twist/challenge

So as I said above, this update is requires that you first must be on the latest PREVIOUS update before applying it. That has never happened before, that I know of: certainly not since the new CF update mechanism introduced in CF10, but I don't recall it in any updates before that.

Update: I have learned since posting this that the problem is about the Adobe security certificate embedded in CF, which is used when pulling down the update file. This is very much like back in CF10, when within days of its release Adobe then too changed the cert. This means that the update download mechanism would fail to "verify" the download (and so not let you proceed to install), with the error:

Error occurred while downloading the update
Failed Signature verification

Some may recall that there was then a separate "mandatory update" jar for CF10--that had to be installed manually before any subsequent updates could be pulled down.

Again, to be clear in case you see this in the future and are planning to update CF, if you are not already on at least CF2018 update 4 or CF2016 update 11, you must get updated to either of those before applying any CF update to CF2018 or CF2016 from today's, forward.

Now back to what I had written originally...

Another aspect of this challenge is that this will affect not only those moving to this update (who are NOT yet on the previous update), but it will also affect those in the future who may SKIP this update but then move to later ones--if again they are NOT yet on the update previous to this. And worse, if future update technotes or comments in the updater UI don't make this point clear, in all of them going forward, I can see this causing heartache and confusion for years to come. :-(

I have asked about it in a comment on the Adobe blog post, to hear more, but so far it seems initial comments are being moderated. That may change by the time you read this.

What's in store for those who do the update

Anyway, everyone using CF2018 and 2016 should apply the updates at some point, if not soon because they do include security fixes. See that Adobe blog post above, and also the technote for the update (that's the link to the CF2018 one, there is of course a technote also for the CF2016 one, as well as links in each for bug fixes page for each release, and the security (CVE) bulletin, etc.

As often is the case, the updates include:

  • closing important security vulnerabilities
  • fixing over 60 bugs
  • adding new language and admin features
  • adding new platforms supported (like Java 12, and more)

Given the changes, it is important (as ever) for you to test the update in a non-prod environment first. The update is too new for there to yet be any discussion of compatibility issues, but they can happen. Watch the comments here or especially in the Adobe blog post (mentioned first above) for word from the community on how things are going with the update(s).

What if you are reluctant to apply the updates, or want help

I understand that some people are reluctant to apply updates as soon as they come out, preferring to let others be the guinea pigs. Since this one includes a security update, you need to weight that decision carefully. Again, see the technote and CVE info for more.

I will add first that if you DO try to do the update and have problems, I have a couple of cornerstone blog posts on dealing with problems applying CF updates, both here and on the Adobe CF portal:

And as I explain in both, I am available to help you also, remotely, quickly, and with satisfaction guaranteed.

What about the web server connector?

Yes, this update does provide an updated web server connector. You would want to update that after updating CF. Either use the "update" button on the CF web server configuration (wsconfig) UI, or the update flag for the wsconfig command-line equivalent.

Update: I had not noticed this need to update the connector when I made my original post.

What about updates to the Adobe CF Docker images

I don't yet see a new Docker image for the updates, but from past experience we should expect those later today or in coming days.

Yes, there are new Adobe CF Docker images for these two latest updates.

If you weren't aware, Adobe started offering Docker images for CF2018 and 2016 in 2018, as I discuss here, as well as for each of their updates.

Better still, you can hear more from me about using the CF Docker images a talk and a daylong workshop I'll be doing at CF Summit, as I discuss here.

We can also expect soon to see that Forgebox has a new set of CF engine updates for the new updates, for use with Commandbox and its available Docker image.

What about other updates?

Sometimes, when people are updating CF they stop to assess if perhaps they need to update related things.

First, as for Java, the Java update (as of my writing today) is update 4 for Java 11 and update 221 for Java 8. I have more on these (and getting and applying the update, as well as dealing with problems) in a post here.

Second, as for FusionReactor, its latest version is 8.2.1 (as of an update yesterday). For more on updating FR, see a post I did on that. And for more on its recent updates, see the release notes for FR 8.

Finally, what about the PMT (the CF2018 Performance Monitoring Toolset)? It required an update after CF2018 update 2 (if you had been running the PMT based on the original installer released with C2018 in July of 2018). I blogged about that PMT update, noting also that there was a new PMT installer released at that same time (Feb 2019). If you have installed the PMT since then, then it already includes that first PMT update. If you installed the PMT from the original PMT installer, you need to apply the update from Feb 2019 if you have not. I am not aware that there was an update to the PMT with this CF2018 update 5. If I learn something new, I will update this post to reflect that.

Update: I do notice that the jar in the PMT-hotfix folder (see my blog post in the last paragraph) is indeed differently sized and has some different contents compared to the one that appeared there since CF 2018 update 2. No word yet on whether it really is a required update, or what it contains (there had been a new update technote for that PMT update 1, but when I change that to use the number 2 in the URL, it gets a 404 currently.)

For more content like this from Charlie Arehart: Need more help with problems?
  • If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
  • See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed
After installation of this update on CF2018 (Windows, IIS) we're finding that the CFLOGIN attribute, allowconcurrent, seems to be 'stuck' on: FALSE.

According to the docs ALLOWCONCURRENT should default to: TRUE. In our applications it seems to be defaulting to FALSE. In addition, when we include ALLOWCONCURRENT=TRUE in the tag it seems to be ignored.

We are testing by logging into a site in one browser and then logging into the same site using a different web browser. Browser one is kicked out on subsequent page load.

Thankfully, we haven't installed this on production yet. Can you confirm?
# Posted By P Mascari | 9/25/19 10:10 AM
I do not see this, but it's not necessarily denying what you see.

First, let me say that really you ought to raise this on the Adobe blog post, so that others see it.

Second, I (and anyone there) would be having to create a sample to prove your case from your words alone. it is much more helpful if you would create your own standalone code, so that anyone could run it.

Doing that also often helps you spot that the problem is not what it seems after all. Or at least you can then easily test it in different places, or ask others to.

Indeed, I'd normally propose you also create and test code on the cffiddle.org site, but I find that it fails to support cflogin because of a permission issue on the underlying ehcache.xml file (which must be leveraged by this).

Anyway, I ran the following code, trying to first just to FORCE the allowconcurrent to be FALSE, so as to first prove that it works as we would expect from the docs (and as you are asserting is happening unexpectedly if it's true or not defined).

I did not find that it did what we would expect. I did not find that visiting in two browsers had the second rejected. Take a look at my code, and see what I may have messed up. I haven't worked with cflogin for some years. Obviously I simplified this to have no login form or real auth process.

checking login at <cfoutput>#timeformat(now())#</cfoutput>
<cflogin allowconcurrent="no">
logging in<br>
<cfloginuser name = "auser" password = "password" roles = "admin"/>
logged in as #getauthuser()#<br>

<cfdump var="#server.coldfusion#">

If it does work for you (blocking the second browser request), then take out the allowconcurrent (or set it to yes) and see if you see the unexpected behavior you are experiencing. Since I am not (on either update 4 or 5), I can't currently recreate your problem.
I did post to the Adobe blog.

You make some valid points, but I don't always have the time to go into such detail.

Thanks for all the CF work you do. I'll see you in your Docker class in Vegas this Monday!
# Posted By P Mascari | 9/25/19 11:10 AM
Thanks for all that, but did my code work or fail for you?

BTW, the Docker images make it very easy to test such things against the one update or the other. :-) Will show that on Monday, of course!
Yes, the code as you have it works as expected. Logging in one browser kicks out the session from another browser.

However, our sites usually allow concurrent logins. So, even with concurrent=true we're still getting kicked out when accessing from different browsers when using the same login info.

<cflogin allowconcurrent="true">
# Posted By P Mascari | 9/25/19 11:20 AM
OK, well, I won't be able to test that, since I said that the code as I offer it does NOT kick out the second browser. That is surely odd that it does for you and not for me.

But if you share such code with others, then you can have them confirm if a) it does kick them out if set to false, and then b) if it does ALSO kick them out if set to true (or left undefined).

CFLOGIN is one of those tough ones to test easily, for a number of reasons.
I just updated and with using Pingdom and StatusCake we are getting reports of 404 errors. I can't replicate, and as soon as I get the notice and am able to access the site without showing a 404 error.
I have a vague recollection we had this same issue some time ago. Checking the install log shows no errors or warnings.
Viewing Web Requests in FusionReactor I am not seeing any 404s but if I filter Requests Response codes 404 I am seeing 2 404s every minute and these are on pages that I know exist.
# Posted By Stick | 9/25/19 2:01 PM
Are you confirming that the url listed as a 404 does really work, not just that you "expect" it would? Did you copy the URL out of FR and run it? Worth a try.

Then also look in the FR request log, to find past calls to it to confirm they do NOT get a 404.

To be clear, I am not aware of any reason that the update should cause a 404 of a CF page, no.
BTW, about the 404's, if you had not said they were logged in FR, I would have wondered if instead they were 404's from the web server--which might indicate a problem with the web server connector (wsconfig).

If you are using IIS, for instance, when an error happens on a remote request, the user just gets a 404, not any detailed error or more accurate status code. (By default, one would get that detail if the request was made ON the server, and that's changeable in the IIS "error pages" page and its "edit feature settings".)

But we should not expect errors of THAT sort (in the connector, leading to a generic 404 to the client) to be logged by FR, as they would have to get THROUGH the connector to get TO FR.

Just some more thoughts for you to consider, Stick.
You are correct, when testing the given urls, "they should be correct" but after testing they are true 404s.

Though Pingdom's and StatusCake is still reporting 404s on the homepages randomly. If I refresh the domain enough times I can get a 404, but upon a refresh it goes away. So I can replicate it, it is just more noticeable with Pingdom and StatusCake because it doesn't retest for 1 minute. Homepage 404s are not showing up in Fusion Reactor.
# Posted By Stick | 9/25/19 2:18 PM
OK, so again, if you are getting 404s that are NOT showing up in FR, then that means they are NOT getting through to FR, or CF, or over the web server connector. That may be where your trouble is.

So first, did you catch that the new updates do include a new, updated connector? Did you apply that update? If using the wsconfig UI, there's an update button, otherwise there's an update flag for the wsconfig from the cmd line. (See my discussion above, "What about the web server connector?")

If you did not update it, perhaps there's some issue where the old connector is more troublesome with the new CF update? That's just a guess.

Next, I assume these are web sites that have long been setup for CF, right? Not recently created ones, or more important ones where you recently created a CF web connector for them?

Either way, are the connector settings properly "tuned"? This is something that's been needed since CF10, and for IIS or Apache. You may recall that Adobe did an extended blog post in 2014 about CF11 (none since) and though the title, text, and screenshots referred to IIS, they acknowledged that aspects of it applied to Apache as well. They just never documented that, either.

So this is why I ask if the connectors are new (which would be the defaults, only suited to a 2-site setup) or existing ones--which we might presume you had "tuned", but perhaps you did not and may need to. Again, I'm not aware of a "new" need to tune them since the update, if they are the same connector files as you had before the update.

Time will tell if there is some issue with the connector in this update. But the most important question for you (and folks hitting this sort of problem) is: did you update your web connector, after this update, as the technote (and my blog post) says is needed? Let's start there.
Yes, I used the GUI for the web connector and "Updated." ColdFusion actually would not start unless I updated the web connector.

I have not tuned the connector since you helped me with it in years ago.

These are both servers that have been running the same with very little issues for some time. No new sites.

This might be a Mura issue and I have reached out to BlueRiver. If you go to https://Domain/Site" target="_blank">https://Domain/Site you don't get the 404, but if you just go to https://Domain and let the Mura redirect to the first Site in its settings you will randomly get the 404 error every minute or two (depending on how often you are able to hit the domain without the Site.
# Posted By Stick | 9/25/19 2:39 PM
Thanks for the clarifications. To be clear, I was not thinking of any past experience when I asked: for one, I didn't take a look over my notes to remind me :-), bot then also things could have changed. So I had to ask.

Again, when I write here I am writing as much for anyone reading rather than only the person asking a question. That's part of why sometimes my answers are more elaborated than some may prefer. :-)

Interesting to hear your discovery about Mura. I doubt they would have had any advance access to the update, since Adobe doesn't offer that. So there may well be a coding issue impacted by the update, and it could take time for them (or any framework) to respond to that. You're a smart guy and I know you already realize that: again, I am writing that for all reading this. :-)
I wanted to provide an update. I reached out to Hostek because I was noticing this on one of my personal sites. Sites using a service like Cloudflare are not having this issue because they are cached. I have submitted a ticket to Hostek and see if we can implement the same temp fix until Adobe resolves the issue.

Hostek Support : This is due to a bug identified by our team and we are working with Adobe for a fix. Currently there is a work around in place for any pages that load to a default document. However, if you would like to submit a ticket we can investigate the issue to see if this is the case.
Stick Hazen : Oh, so it is a bug in the hotfix?
Stick Hazen : what is the work around or did you mean there is not a work around?
Hostek Support : Correct, the hotfix Adobe gave out has a bug that is causing these issues. We did implement a workaround for now that allows any page that loads a default document to load without error.
# Posted By Stick | 9/26/19 2:10 PM
Thanks, and yep. I had done just earlier today a follow-up blog post recommending people hold-off on this update: https://www.carehart... I have now updated this post to point folks to that one.
Version   2016,0,12,315717
Edition   Enterprise
Operating System   Windows Server 2012 R2
OS Version   6.3
Update Level   /F:/ColdFusion2016/cfusion/lib/updates/chf20160012.jar
Adobe Driver Version   5.1.4 (Build 0001)
Tomcat Version
Java Version   1.8.0_202

Update 12 to CF2016 on Windows went on smooth as you like. 11 was already in place and Java was up to date.

The thing that surprised me was all instances of
<cfoutput query="qSomething">
.. began to fail in a variety of different ways.

Replaced with <cfloop>'s

# Posted By Will | 10/1/19 5:34 AM
Yep, Will. See the follow-on post, linked to at the top, where I point out that others reported that problem (related to nesting), and some offered that workaround, and Adobe is offering a patch.

Folks seeing this post may want to be sure to check that post out, for other known bugs.
Copyright ©2024 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting