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 verificationSome 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:
- Having problems after applying a CF update? What to check, and how to recover!
- How to solve common problems with applying ColdFusion updates (in 10 and above)
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?
- Signup to get his blog posts by email:
- Follow his blog RSS feed
- View the rest of his blog posts
- View his blog posts on the Adobe CF portal
- 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
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?
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"/>
</cflogin>
<cfoutput>
logged in as #getauthuser()#<br>
</cfoutput>
<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.
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!
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!
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">
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 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.
Suggestions?
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.
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.
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.
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.
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.
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. :-)
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.
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 8.5.42.0
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">
</cfoutput>
.. began to fail in a variety of different ways.
Replaced with <cfloop>'s
Best,
Will
Folks seeing this post may want to be sure to check that post out, for other known bugs.