Michael, this is not "new", and you can no longer workaround the issue with those tweaks that you (and others) have long used. Let me elaborate.
The change in behavior was implemented by Adobe starting with the CF updates released in Oct 2023 (cf2023 update 5, cf2021 update 11). So what's "new" for you must be that either a) you applied a more recent CF update than that sometimes since then and then you ran the wsconfig tool to either a) add a new connector or b) did a wsconfig "upgrade" operation on an existing connector. Either of those would have used the updated wsconfig (for the newer CF update) to upgrade your connector.
And THAT is when this "failure" would have started for you. If you will somehow disagree/contend, we can dig in further to prove things of course. But perhaps hearing the above will at least clarify how this came to be "new" for you.
As for the change (in Oct 2023), it was discussed above as well (in May) as being a security protection Adobe has implemented. And it's listed in the technotes for those CF updates from Oct 2023 with a box reporting: "In this update, for security reasons, the access to the Administrator to the connector port is blocked." Not great or clear wording, but that's what happened.
So what can you do? Well, as others above noted, they just stopped trying to access the CF Admin via a site in IIS or Apache (which was configured with this CF web connector). Instead they used the CF Built-in web server (by default at port 8500), which has been enabled in CF by default since CF2016.
I realize that some complain "I can't get to the server to run via that web server", but some can configure their firewall to allow access to that port from off the server, and then you may also need to tweak the CF Admin security page for "security>allowed ip addresses" to add your ip address to the second list of IPs, which controls who can access the CF Admin. (This is not to be confused with the CF Admin "debug output>allowed ip addresses".)
Some don't want to "have to do such tweaking to the CF Admin" or "don't have a statici ip addresss". In that case, I hope they would have taken efforts to limit in their web server configuration who COULD get to the CF Admin when it COULD be reached via IIS or Apache. And they may say "that's what I want to still be able to do".
Some people in desparation have resorted to finding the old isapi_redirect.dll (or mod_jk.so for Apache) from a server where they have NOT yet updated the connector, to put THAT into their config/wsconfig/ numbered folder for their connectors, to "force" CF to use the old connector. (You'd need to restart IIS or the site or app pool for that change to be picked up.) Beware that a future connector upgrade or new connector will again implement the new dll. Again, I hope that you'd also protect access to that ability to use the CF Admin, whether via the web server implementing protections and/or using the CF admin "security>allowed ips" discussed above.
Others have changed to using their web server to instead port forward to the CF built-in web server. In IIS, you'd need to enable the Application Request Routing/ARR (or "web farm") capability, to be able to setup such a forward. Apache people will find it easier, as will those using nginx or proxies like Traefik, ATS, etc. All these would circumvent using the "connector" which uses Tomcat's "ajp" port (which was the "port" being referred to in that quote from the technote I offered above).
All this is exposing you to vulnerabilities that Adobe has for years trying to protect you from. You have to be very careful. But I get it: people want to do what they want to do. These are among the options to do that. But again, it's not "new": it's something people trip over if/when they update CF and/or update or add new connectors using wsconfig.
Hope that helps.
/Charlie (troubleshooter, carehart. org)
2 Correct answers
15
Replies
AdChoices