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.
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.