ColdFusion 2016: Changes in the CF Administrator
Note: This blog post is from 2016. 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.As folks continue to explore ColdFusion (2016 Release), aka CF2016, regarding what's new or changed, I thought I'd put together a listing of what has changed in the CF Admin specifically. This is another in a series of posts I started last week on CF2016.
In the past, I've tracked these Admin changes in each release, in the various "Hidden Gems" talks I've done about each release. (Somehow I never did a blog post about those earlier releases, at least 9, 10, and 11. The last such post I did was about Admin changes in CF8.)
So without further ado, here are the changes I've found.
There really are only a few changes in the CF admin, but the first is a pretty significant one.
1) Admin not accessible in external web server by default
When you configure CF (during installation or using the wsconfig/web server config tool) to connect it to a site/sites in Apache, nginx, or IIS, it now no longer makes the CF Admin available within sites in your web server. You can (by default) only access the CF Admin using the built-in (or "internal" or "Tomcat") web server, whose port is selected during installation. The default would be 8500, unless it's already use, as could be the case if you have CF already running and had the built-in web server enabled for that. In that case, CF would choose 8501, 8502, or so on.
This is an important new security change, as it means that the CF Admin can be accessed only on the server by default (because most server firewalls would block ports other than 80 and 443 from being accessible from off the server) .
But I could see it leading to confusion for some, if they never used the built-in web server before. (In prior releases, it was disabled by default unless during installation you indicated that you did NOT plan to use an external web server at all. Otherwise, it could be enabled via manual configuration. I previously blogged about The built-in web server in ColdFusion 10: enabling it, configuring it, reconsidering it.)
1a) How to enable the Admin in your external web server, if you really (really, really) wanted to (but you probably should not)
Update since initial posting: Someone asked me in a support call, "what if we DO want to enable the CF 2016 Admin via our external web server?".
Well, let's be clear: you would be disabling a security protection that Adobe has added! You really shouldn't do it, but if you're determined...
Note that it's not enough to simply add back the CFIDE folder as a virtual directory or alias in IIS, Apache, or nginx (pointing to the coldfusion16\cfusion\wwwroot\CFIDE folder, for instance). If you do, your attempts to access the CF Admin using that virtual directory will result in a blank page.
Adobe is trying to protect you from yourself, seriously! :-) More likely it was done to prevent OLD existing CFIDE virtual directories from "working" as of CF2016, which would have circumvented this built-in protection.
You'll find that if you instead name your new virtual directory anything but CFIDE, like even "x", you could then get to the admin as yourdomain/x/administrator (or whatever domain name or IP address would work for the site in question).
So how/why is it being blocked if you use CFIDE? What it is is that Adobe has also added a line to the uriworkermap.properties file (as may be found in C:\ColdFusion2016\config\wsconfig\1, or whatever numbered connector folder your setup uses):
!/CFIDE/* = cfusion
That is preventing the web server connector from letting the request through (and why using any other folder name "works").
So, if you really (really, really) wanted to enable access to the CF Admin via your external web server as CFIDE, you'd want a) add back a CFIDE virtual directory (which again, Adobe's trying to PROTECT you from doing by not doing it for you), and then b) comment out that line in the file by putting a hashmark (#) in front of it. You may need to restart your web server or the app pool of the site you're modifying (if you have made requests against it), but there is no need to restart CF.
(And someone might cleverly propose that a solution is just to add a virtual directory named OTHER than CFIDE, and you could. Then you would think you don't need to remove the block in the properties file. But one problem is that SOME things in the admin would fail because some code or links within the Admin do go to a hard-coded /CFIDE path. One example is the check for updates which happens when you first login, assuming you have not disabled it. Another is the "system info" ("i" link in top right corner). Still others are some images. These fail even if you add a CFIDE virtual directory, as long as that CFIDE block remains in the properties file. [Thanks, Mark Quigley for your comment on this below.] But some may choose to leave it blocked, for security reasons, and probably shold, and just deal with working around the few failing links.)
Keep in mind, again, that if you go changing things to test them out, you may need to restart the app pool for the affected web site if you modify that properties file. (That's referring to IIS, of course. In Apache, you may just want to restart it to be sure.)
As for other CF admin changes, I will step through them from top down by sections in the Admin. First up are a couple under the "Server Settings" section.
2) "Default ScriptSrc Directory" changed from /CFIDE/scripts
The first change in the Server Settings section is regarding the "Default ScriptSrc Directory" setting. In prior releases, this has long defaulted to "/CFIDE/scripts", but in CF 2016 Adobe has changed the value to "/cf_scripts/scripts/".
This ScriptSrc directory is a folder that CF points to (as it generates HTML), if your CFML code uses any of certain CFML tags which rely on Javascript and other resources (mostly UI tags, like CFFORM, CFLAYOUT, etc.). The generated HTML would point back to this directory in script src tag, which was expected to be found via the web server serving your CF site.
2a) The first significant thing some will readily notice is that it no longer refers to the CFIDE folder. That was a sore spot in past releases, from a security standpoint, because the CFIDE folder held BOTH the CF Admin AND these UI script files. If one wanted to protect the Admin, but leave these scripts open, it was a challenge with the default configuration of them sharing the same parent CFIDE folder.
2b) A second thing, though not as obvious, is that CF2016 now pre-configures that /cf_scripts/ folder as a virtual directory in your external web server (IIS, Apache, nginx) if you tell CF to connect sites there (again, either at installation time or using the wsconfig tool). In the past, if YOU had changed the value of that "Default ScriptSrc Directory", then YOU would be responsible to remember to create such a virtual directory. (You also had to enable the same virtual directory within the built-in web server, because the CF Admin also relied upon this "Default ScriptSrc directory" for pages like the "Server Updates" page and its tabbed interface, or the various "Browse" buttons in the Admin, which use jQuery in CF10 and above.)
Well, people were often confused about this setting, and its connection to a needed virtual directory (in the external web server and/or the internal web server), and so often they did NOT change it, or if they did, they did not do all the needed changes, so some aspects of either their code or the CF Admin itself would not work correctly. Now that it's configured to something other than a folder shared by the CF Admin, and it's pre-configured by CF as a virtual directory when the web server config tool is run, and the new folder already exists within the built-in web server root.
2c) Finally, and related to that last point, in CF2016 there is now a real folder called /cf_scripts/scripts/, under the [cf2016]\wwwroot folder, as a sibling to the CFIDE folder there.
2d) Just note that if you DO change this value of the "Default ScriptSrc Directory" to anything OTHER than "/cf_scripts/scripts", then it WILL STILL be incumbent on you to change or create a virtual directory, a) in your external web server (to be found by users of sites where you DO use CFML tags that rely upon such scripts) and b) in the built-in web server of CF (discussed further, above), at least for things like the "browse" buttons to work, and the "server updates" page's tabbed interface.
3) New API Manager "Allow REST Discovery" option
The next change to discuss in the "Server Settings" section is in fact the last setting on the "Settings" page: an option to turn off the new API Manager's ability to auto-discover REST APIs.
To appreciate this change, you need to understand that CF2016 now includes a new (and technically, totally separate) product, called the API Manager (available only in the Enterprise, Trial, or Developer editions of CF 2016). The API Manager is much too broad for me to discuss it in any succinct way here.
Suffice it to say that one of the few CF-integrated features of the API Manager is that it can and will automatically explore and expose REST services defined within CF, unless you disable that capability with this new setting. (One might reasonably wonder why this changed setting is not on the separate "Rest Services" page, in the "Data & Services" section of the CF Admin.)
To learn more about REST Discovery and other aspects of integration of the API Manager and CF, see the CF docs on the topic.
4) Session storage in Redis
Update: I somehow failed to include this in my initial posting of this blog entry. Sorry.The final change to discuss in the "Server Settings" section may be perhaps the most interesting CF Admin change to most people: the new "Session Storage Settings" option of the Memory Variables page, where typically one would enable and manage application and session variables.
The new option lets one change the storage of ColdFusion sessions from the default of "memory" to a new alternative location, "Redis". Redis is a no-sql database which is embedded in CF 2016 (well, it's embedded in the new API Manager, which can optionally be installed with ColdFusion Enterprise. Otherwise, you can download it yourself and either way, you then point CF to it). If you choose "Redis" as the location, the CF Admin UI will change to show values to be filled in to indicate the Redis configuration location.
Once you configure CF to use Redis (and restart CF for the changes to take effect), sessions will now be persisted to this Redis database/server, which means that the sessions remain available even over subsequent restarts of CF. There is also support for pointing to a Redis server on another machine, so that even a restart of the box running CF would not lose session variables, and also so that multiple servers could share that session storage location.
Finally, note that the feature ONLY works (currently) with CF sessions, not when you have enabled the "Use J2EE session variables" at the top of this same page.
For more information on this feature, see the External session storage section of the CF docs.
5) Web services now support NTLM authentication
The next change is not in the "Server Settings" section but instead in the "Data & Services" section. Note the "Web Services" page, where one can optionally define web services (in addition to just using them without such pre-configuration, in the CFML tags and functions that can invoke web services, like CFINVOKE, CFOBJECT, and createobject).When defining a web service in the CF Admin, there is a new option for "Authentication Type", with choices of "Basic" or "NTLM", the latter being a safer way to transport passwords in a secure way, even without SSL.
This authentication capability can also be indicated in the aforementioned tags/functions as well, and there's documentation on that. For more on that, This is discussed further in the CF docs on the topic.
6) Features in the CF Admin that are Deprecated in CF 2016
Finally, as I noted in my post yesterday, there are various deprecated features of CF 2016, and several are in the CF admin itself:
- Event gateway - Jabber, Flash Media server
- Portlets (also "no longer supported", so no bugfixes)
- Server Manager
- Server Monitor
- System Probes
For more on deprecation of features (which is not REMOVAL of them), and especially to comment on the things deprecated, please see my other blog post.
So, as for changes to the CF Admin in 2016, hope that's helpful. Did I miss anything else?
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
1. SSL
2. Our admins would rather hit that in the browser from their desk without RDP. And none of these servers are accessible via the ports we are using for SSL (non-standard).
One other caveat to this. For all the interlinking to work (images, cfcs, etc) you will also need a virtual directory in your site /CFIDE - otherwise things will not work. So, 2 virtual directories.
/whateveryyourcfadminwillbecalled
/CFIDE - lots of references to /cfide/.....in the code
One note, Our CFAdmins are set up on their own websites over non-standard SSL Ports with a certificate. So, it's not the wild west!
I know you're presumption is that "still locking down the CFIDE/administrator" directory would not seem "necessary", because you don't see CF adding a CFIDE virtual directory to the web server.
But that doesn't matter. Check it out. You will find that you CAN still get to the CF Admin, even though you see "no CFIDE virtual directory" in your web server.
This is because of a long-existing and little-known but potentially troublesome "feature" in CF: if you request a file (or folder and file) in your web server that is "not found" as per the web server configuration, CF will STILL look for that file/folder in the CF instance's wwwroot.
Now, if you use the CF Admin feature (in 11 and above) to tell CF (in the Security>Allowed IP addresses page, at the bottom of that page) to only allow certain IP addresses to access to the Admin (and RDS and other secured features), that would at least limit your exposure.
And you could certainly ADD a CFIDE virtual directory yourself to your web server, and then lock things down in additional ways, such as requiring extra security/logins, etc.
So just be VERY careful about exposing the CFIDE via your web server, as I alluded to in the post. Again, I only mentioned it for those who really pressed to know the implications. Yours is another useful one to now discuss.
In fact, it may be worth noting that for RDS, what you REALLY need to secure especially is the URL /CFIDE/main/ide.cfm. That's what RDS uses: and no, there's never been a main folder or an ide.cfm file, but instead that is done as a filter, as defined in CF's \wwwroot\WEB-INF\web.xml file (nothing new or different about this in 2016, as it's been like this since CF6).
So if you do "open" that block in the uriworkermap.properties, it will still be protected if either you use the CF Admin security feature to block access to such things by IP address, or if you create a virtual directory called CFIDE and lock that down.
But really: people should be VERY VERY cautious about doing anything that exposes their CFIDE or ESPECIALLY the RDS feature on the web. Adobe is trying with these changes in CF2016 to PROTECT you from vulnerabilities related to that.
Undoing those "locks" is as risky as living in a house with locks on the doors and choosing to unlock them. You may not "think" you "live in a bad neighborhood", to stretch the analogy, but unlike a real home, web servers are under CONSTANT attack from people trying to find any way to get in. (Picture those "sentinels" in the Matrix movies, or the spider robots in Minority Report. Attackers are THAT perniciously persistent, so you don't want to give them even a crack in the door.)
But after it was reinstalled, white screen, no cfadmn except via 8500
It also seems to be a bit half-arsed, as there are still things that are still set to use the CFIDE folder by default, such as the missing template handlers, which are obviously no longer going to work is CFIDE is blocked.
As for your feeling that it "did work in the past" for you, you either were looking at CF11 or had by some combination of customizations gotten it to work. (See my last comment above, about how it's possible, but not generally recommended.)
As for your feeling that there would be a problem with the site-wide error handler, nope, there is none. That file (/CFIDE/administrator/templates/secure_profile_error.cfm, when enabled as the site-wide error handler as it is by default with the "secure profile" feature) is NOT served via IIS (or Apache or nginx). It's called from within CF, just like some other things that leverage CF Admin mappings. So the "block" in IIS has no impact on it.
You can confirm it yourself. Enable that sitewide error handler, and visit a page generating an error. Regardless of whether you visit the URL via CF's built-in web server or an external web server (like IIS), you will see the "blue ball" error page of the CF secure error handler.
If you still have some other aspect that you think is "wrong" about the approach, do share your thoughts. We should all be always learning.
I am a bit confused about how the "Session storage in Redis" really works. Since we cannot use J2EE session, which means that we need to use ColdFusion session and with that we will need to pass the CFID and CFToken in the URL's, right? Wont that be a security risk?
But no, you do not "need to pass the CFID and CFToken in the URL'" when you use CF sessions instead of J2EE sessions. The need to pass tokens in the URL is only for when the browser doesn't support cookies. And if you use J2EE sessions, you would then STILL need to pass a token in the URL, but it would be the jsessionid instead.
So yep, one difference between CF and J2EE sessions is the kind of token (though not whether it needs to be passed in the URL, as both do, if needing to support browsers that don't support cookies, which is rare these days).
But the more important difference that most complain about, in being "forced" to use CF sessions to leverage that Redis sessions feature (also set on the CF admin "memory variables" page), is that the cookies underlying J2EE sessions are more secure in many ways.
That can be addressed, though, in a way that it seems few realize. I hope to do a blog post (even perhaps today) to explain that. I think then that most people WOULD more readily be willing and able to consider leveraging things like the Redis sessions feature, which Adobe (curiously) set to work ONLY with those CF sessions (and not J2EE sessions).
If and when I DO post that blog entry (hopefully today), I will try to remember to come back and share that link here.
But you say you are "confused" how the Redis session feature "really works". If you're asking about something else (than this requirement to use CF sessions and not J2EE ones), do share what is confusing. (Then again, that's going beyond the real focus of this post. At some point, I want to do a new blog post on the Redis sessions itself, but until then, you can ask here.)