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.)
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/".
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 RedisUpdate: 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 authenticationThe 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?