As an update since I first wrote this, it turns out this issue may or may not affect you depending on a couple of variables, which I will discuss, with a prefix of "update:" below. But don't dismiss this thinking you are not affected. I would propose that still far more CF servers may be exposed than not, as I will explain.
The CF Admin has (for several releases) offered an option called, "Use UUID for cftoken" (in the "Settings" section), and it's been intended as a security measure. Its purpose is to cause CF to use a UUID value (a long, complex string of numbers and letters) for the CFTOKEN cookie (and session variable) that CF generates, versus what used to be a simple, 8-digit value. This cookie, along with the simpler and incrementing CFID, is used to connect users to the session and/or client scope values created for that user in CF code.
Some may be surprised to learn, though, that while this setting DOES cause CF to *create* such UUID-formatted CFTOKEN values for requests that do not already present a CFTOKEN cookie, it does NOT necessarily cause CF to block any continued use of such simple, 8-digit cftoken cookies.
In other words, browsers which had visited your site before you turned on "use uuid for cftoken" would still send the 8 character cftoken they already had, not a uuid, and that could be accepted as valid by CF, even with that setting on, under certain conditions. (And the user will not be sent any new cftoken cookie in a UUID format, in CF's response, in those conditions.)
There's good and bad news related to this fact, which I will elaborate on below.
Update: Since writing this entry, I learned of a couple of factors that influence if and when this is a problem.
- It turns out that if you are using CF10, or CF9 or 8 with the "session fixation" hotfix (APSB11-04), then the problem only happens until you restart CF. The Admin does not currently warn you of this, so beware that you will have the exposure below until you do restart. (If you have added one of the later security hotfixes or cumulative hotfixes that came out since then, then you have gotten the fix.) This fix causes CF to create a new UUID-based CFTOKEN, if you turn on this feature at least (and after a restart) when a browser presents a previously created 8-digit cftoken.
- On the other hand, even if you are running CF 10, or running 8 or 9 and HAVE applied that hotfix, note that if you TURN OFF that fixation protection (by adding the -Dcoldfusion.session.protectfixation=false value to your jvm.config, as discussed in that technote), then you are back to the state that I discuss below.
- And of course, if you are on CF 8 or 9 and have NOT yet applied that APSB11-04 hotfix (or a later cumulative one that includes it), then you are indeed still vulnerable.
So that leaves still many people who could be affected by this. Even if it seems you may not be, you may want to continue reading this entry to understand what the issue is about, for you and others who may be impacted by it.
It's a simple JVM tweak to cause it to use a fixed port:
You can add this either in the "Java & JVM" page of the CF Admin (if in Standard or Enterprise Server), or on the java.args line in the jvm.config file (for any form of CF).
You do need to restart CF for this to take effect.
A few warnings are in order
My chapter on the topic, in the newly released CF 9 Web Application Construction Kit, Volume 2 Application development is available free online. It's one of 3 chapters at the end of the book (out of 21 total) that were forced online due to pagecount restrictions.
While it's a bummer for those who buy the print book and may not notice these are missing (though it should be mentioned in the TOC), the good news is that it means anyone can read the chapter.
You'll find the 25-page chapter (chapter 45, "Using the Debugger") online in a PDF of all 3 chapters available at Ben's site. Note that since mine is the last chapter of the PDF, you will want to skip to page 71 within the document. The following link should open the PDF directly to that page (if not, just use the Acrobat feature to go to a page):
Finally, some may notice on the Amazon page offered above that only Ben Forta is listed as author for the book. Of course, there were multiple authors. Ben, Ray Camden, and I were contributors to all 3 volumes, while there were still other contributors for volumes 2 and 3. Ben says that this oversight will be addressed soon.
Yes, you CAN modify the debugging output. Some have even done it for youMany may not realize that the CF debugging output (optionally displayed at the bottom of the page, as enabled in the CF Admin) is actually created by a CFML template that can be modified ([cf]\wwwroot\WEB-INF\debug\classic.cfm).
Fortunately, several people have offered various resources that explain how to work with this file and offer packaged alternatives with specific features to resolve particular problems (where people wish the debugging output did more, or could be seen differently than at the bottom of the page).
Just drop and reloadYou can just drop any of these files into the debug file directory to add to or replace the default file. If it's a new file you then need to select it as an alternative in the CF Admin Debugging Output page which offers a choice for "Select Debugging Output Format", which points to the classic.cfm by default.
Of course, since it's CFML source code, all the options mentioned here are free and open source.
The alternatives, discussed and downloadable
The alternatives include:
- "Another hack job", from Ray Camden, adding total query time, improved number formatting for individual query times, and highlighting queries that a given duration
- ColdFire, open source from Nathan Mische et al, a Firefox/Firebug extension to aid in viewing CFML debugging output by way of a new alternative debugging output template, coldfire.cfm
- ColdFusion Debug Templates, "in case you want to try something different than the default template", from Josh Knutson
- Debug2FusionReactor, from Intergral, for showing CF debugging output in FR Marker tab
- Improved Classic CF debugging template, from Aaron Longnion. Changes list of templates executed to show in order executed, rather than by order of duration. Also adds cfqueryparam variable values for queries shown.
- StarFish, from Ray Camden, a profiling tool built on the CF debugger. Stores debugging output in server scope, and adds an Admin customization interface to view reports based on gathered information.
- Stiletto, from John Mason, for logging CF debugging output to a file (inspired by a blog entry by Bilal Soylu
- Zoid, from Ray Camden. Changes the table of templates executed from a summary for each (even if called multiple times) to in individual display of each, in order.
- Note as well that another alternative to showing debugging output at the bottom of the page is a built-in option in CF. Note the available "dockable" option in the choice for "Select Debugging Output Format". While the aforementioned classic.cfm is the default, the dockable.cfm instead shows the debugging output as dockable/movable/floatable pane instead.
Also listed on my CF411 siteNote as well that I have just created a section in my CF411 site, called "CFML Debugging Output Template Alternatives/Mods". If anyone offers me additions or corrections as a comment below, I'll be sure to update the list in the CF411 page as well.
Finally, as I mention at the bottom of the list on that page, note that I have yet another section (following that one) on the site, called CFML Debugging Tools, which lists still other kinds of CFML debugging tools.
Well now you can, if you have FusionReactor, by way of a simple 2-step process to configure CF to do this. You can learn more about it in this article Capturing ColdFusion's Debug Output in FusionReactor by Darren Pywell, CTO of Intergral (makers of FusionReactor).
In it, he explains what this is all about (a combination of using FR's API and the "markers" feature of the FR Request Detail page, in conjunction with CF's built-in feature to let you add and use new debugging templates). More important, he gives you all you need to know to set things up, from the simple snippet of code needed (downloadable) to a walkthrough of the simple steps needed to configure CF to hand the debugging output to FR. You can be up and running with this new capability in a matter of minutes (skip to the bottom for the "fast track" steps he offers, for proof.) Check it out.
But what about the performance impact?
And yes, he addresses briefly the performance and memory implications of using such a feature in production. You should certainly take care to ensure that doing this isn't causing any harm, especially if doing this in production. That said, I see lots of shops that leave debugging turned on and use the IP address limiting feature in the CF Admin, which many will argue is equally detrimental. I think a point to make is that the negative impact may be more "theoretical" to some than to others.
The bottom line, as he recommends, is that you should test such things before rolling them into production. Sadly, many shops can't or don't bother with testing (which is very unfortunate).
If you can't test the impact, measure it...with FusionReactor
At least then you should try to have some measure you can watch to see if processing is being in any way harmed, whether it's tracking fewer requests being processed per day, requests taking longer to run each time on average, more CPU being used by CF per day, and so on.
The very good news is that those who have FusionReactor can use FR's own tremendous logging to help report this kind of information. I talk about how to report against that using a tool like Microsoft's free Log Parser, in this page on the google group for FusionReactor.
I'll do a future blog entry on the tremendous logging that's possible. It far exceeds anything provided by any other tool, including the CF8 Server Monitor (which does no logging at all), and it does it with very low overhead.
So if you're using FusionReactor, check out the debug tool. It's very easy to enable and disable (via the CF admin, once you've added the new debugging template). It's also a useful demonstration of the FRAPI.
And if you don't have FusionReactor, check that out, too. I use it or help people use it every day to solve CF problems. It's much more than "just a monitor". For more info, see the site's many resources (brief feature highlights, docs, online help, a live demo, mailing list, and more). See also some of the other entries I've done here on FusionReactor.
Thanks go to Paul Kenney, as I found it in a page of his while I was doing a google search for some related info.
Why is this interesting?
I'm sure some may be wondering what the excitement is. Can't you easily tell what client storage repository a given app is using by looking at the ClientStorage attribute (of CFApplication when using application.cfm), or as a property in application.cfc? Sure.
But sometimes you may be left wondering how to view that value programmatically. Maybe you can't open those files (ok, that's a stretch), or maybe they include or invoke other application files, and trying to track those down is a hassle.
Also, one might not set the value in ClientStorage, in which case CF takes the default from the CF Admin, but a developer may not have access to the CF Admin, so can't know which repository they're really using.
How I found it, why I was looking
This came up when someone raised a problem on the Adobe Forums, where they said that several apps using a given clientstorage DSN worked, while one using it failed (all on the same server). I thought that odd, and wondered if the others may not really be using the DSN he thinks they are.
So I set off to find an answer. I hoped it might be in the servicefactory clientscopeservice, but it was not, in any of its available methods. While looking for possible examples of folks using that in ways I had not thought to, I found Paul's page above. What's nice about it is that it DOES NOT rely on the ServiceFactory, which of course is undocumented and unsupported (and can be disabled).
Some other thoughts about this getPersistSettings approach
This getPersistSettings approach above is just an undocumented method in the regular client scope: you won't see the value or this method being exposed in a simple dump of the client scope. But at least (unlike the servicefactory) it can't be disabled.
And I've tested it in CF7 and 8, and it worked fine.
Of course, if you're going to run this to help someone determine what storage they're using, you need to run it in the directory of whatever app you're trying to check. Be careful about mistakenly running it in some test directory outside of the app's directory.
And don't bother looking for other properties to "get". The only key in the structure that's returned by getPersistSettings is this one.
That said, it would be nice if it might also identify info about the client variable storage repository, such as how many days at which it's set to purge expired visitors, and whether "disable global variable updates" is enabled or not. You can get that info using the undocumented ClientScopeService in the ServiceFactory (just do some googling for info on it, and its available getclientstores method.) But it would be nice to have this info using the method above.
In fact, I've filed a feature request to get even this current clientstorage setting (and the info about the storage repository) available in a more direct and supported manner.
In the meantime, hope this may help some.
Ray Camden has written an entry which has an available download of an improved debugging template, which you can easily drop into your CF setup and immediately get the improved info (focused on better tracking query time info). This improvement doesn't require any change in your browser (like the ColdFire alternative, which I'll mention at the end below).
The additional debugging benefits
Ray implemented some ideas I posed as improvements for Adobe to consider adding, such as to offer a total of all query time spent (by default we see the time in each query, but not totaled). I also thought it would be nice to see highlighting of those queries that exceed a given amount of time, just like we get with included files and CFC methods. I mentioned a couple other things as well. Ray went ahead and made the changes for some of them.
How he did it
How'd he do that? Well, many may not realize that the debugging output we see is in fact editable because it's enabled by way of a CFML template (the default one's called classic.cfm). It's just CFML.
I've known for years that the file was editable, but I just didn't think to go ahead and edit it, or to share it with others. My focus was to get Adobe to consider it for an upcoming release. But, sure, if we can have it now (until they do), I suppose that's better than nothing, so thanks, Ray. :-)
How to get it
You can read more about the update, and download it, at Ray's entry.
(BTW, some folks might miss the download link on Ray's entry. It's at the bottom of his entry, just before the comments, on the line listing the entry's time/date and number of comments. Here's the URL for it, also.)
How to implement it
You can drop Ray's updated version into the place where these debugging templates live, which is under the [cf root]\WEB-INF\debug\). The improved info will be immediately available in any browser. Again, it's just a tweak of the normal debug output.
In a Server deployment on CF8 in Windows, the location to drop it would typically be C:\ColdFusion8\wwwroot\WEB-INF\debug\, or something like C:\JRun4\servers\[instancename]\cfusion-ear\cfusion-war\WEB-INF\debug\ if you're running on the Multiserver/multi-instance deployment mode.
Be sure to save a copy of the old one first under a new name, in case you want to revert back.
You could also give this new file a new name, and then just select it in the CF Admin Debug Output Settings page (as it's named in CF8). As soon as any cfm file is put in that directory above, it will be shown the drop-down of "Select Debugging Output Format".
Some other info
Note that the version he's offered at first there is known to work only for CF8 for now. Update: I just tested it in CF7 and it worked as well.
There's been interest expressed in creating an open source project on RIAForge, and that should offer versions for different versions (and perhaps different CFML engines). I'll share more news if that comes to pass.
And Ray would want to also point out ColdFire, a Riaforge project that uses yet another debug template in conjunction with a ColdFire Firefox add-in (that works in conjunction with the Firebug add-in). For more, see http://coldfire.riaforge.org/.
While ColdFire offers some neat features, I still myself like the idea of tweaking the classic template instead, as it's cross-browser and requires no changes to the browser. For a lot of developers, the easier it is to provide a benefit, the more likely they are to implement it. I hope to see this capability evolve still more over time.
Test Debugger Failed An RDS connection was established but the line debugger could not be contacted. The server gave the following message:
javax.servlet.ServletException: Operation not supported: DBGREQUEST
You may be quite stumped, as I was myself, since it's not a terribly informative message. I figured it out, though.
In my case, at least, it's that the default setting when you install the Adobe CF 8 Extensions for Eclipse has the localhost RDS server configuration set to talk to CF on port 8500. If you've installed CF to use the external server, as was done on this server I was helping with, then you need to change that to port 80.
Bottom line: whatever port your CF admin is accessed on, use that in the setup of the RDS configuration in Eclipse.
If you're not familiar with where to find that RDS configuration in Eclipse, see Window>Preferences>Adobe>RDS Configuration (or it may be Window>Preferences>ColdFusion>RDS Configuration). Select "localhost" from the "currently configured RDS Servers" and note the "Server Information" fields now populated on the form. Make sure the settings are correct for the server you're connecting to. And of course, if you mean to connect to a server other than your localhost, you can choose "New" and define different server settings.
These details are discussed in places I point to in the resource discussed above.
In the 45 minute talk, we discuss both talks I'll be doing at the conference, first "Hidden Gems in the CF8 Monitor" and then "Step Debugging in CF 6/7/8". The first is a condensation of my 4-part series of articles in the Adobe DevCenter, where I highlight the most compelling tips, tricks, and traps I found. I think many will be surprised by them, and in the interview I share several from the talk.
Matt also asked me about how it compares to FusionReactor and SeeFusion, and I shared my thoughts for why there's a place for all, and along those lines (of how competing things fit together), he also asked me my thoughts on the open sourcing of BD/J2EE.
Of course, one of the things I clarified was that I left New Atlanta nearly 2 years ago (next week). Many seem not to have gotten that memo! But I explain more, including why I'm not so sure it will light the world on fire as a "free CFML engine" though it may well help a lot of people, so check out the discussion if you're interested in that topic.
I also shared some news that I've never blogged about nor spoken much about: the fact that when the roles of CF Product Manager (when Tim stepped down 2 years ago) and CF Evangelist (when Ben knew a few months ago that he was moving up to lead all the Evangelists in Adobe) first became available, I had the distinct honor of having been asked first (so I was told) if I wanted those roles. It's hard for that not to sound self-aggrandizing, which is why I've not mentioned it publicly, but I mentioned it in the interview to make the point to listeners that I really am all about CF now, and that plenty of folks at Adobe did realize I was still very much a CF community guy all along.
Anyway, I explained that I didn't take the roles simply because in the first case, the product manager role, it would have involved relocation to Boston (love Atlanta's weather too much, plus I was enrolled in an Atlanta-based seminary at the time). In the second case, Ben's role, it would have been awesome, but we all know it involves a LOT of travel. My wife and I just didn't want to be apart so much and so often (and again there are those seminary studies). It was tough to say no, but as I mentioned in the interview, of course Adobe got great folks for the roles ultimately, in Jason and Adam, respectively.
The interview concluded with my discussion of the Step Debugging talk I'll give at cf.o. I explained how it will cover both the CF8 Debugger (useful only on CF8) and FusionDebug (which can run on 6, 7, and 8). I explained (as I have many times) how though they're both based on Eclipse, that needn't be a show-stopper.
I explained how FusionDebug even offers an installer that bundles Eclipse, CFEclipse, and FusionDebug all at once, which is a great help for those challenged to install it (though it's also available as an add-in). I noted that the CF8 debugger is available only as an add-in, which can be a challenge to some, but I pointed out (as I have previously) that my 25-page chapter on the CF8 debugger, in the CFWACK, is available online. That should really help those who've been challenged to get started with the CF8 debugger. Anyway, I'll explain a lot more about using the debugger, and when/why/how one should, in the talk at the conference.
So, though I didn't plan it, I guess this interview was as much a show about how I'm not any one company's guy. :-) Whether it's supporting the CF8 monitor or FusionReactor/SeeFusion, the CF8 debugger or FusionDebug, CF or the other CFML engines, or even the consulting I do (done mostly on my own, but also some for Intergral and for Universal Mind, as I mentioned), I'm out here just trying to help where I can, whoever I can, however I can. :-) I just want to share info or tools and let folks make their own decisions. (In that regard, be sure also to check out my list of 400+ tools/resources for CFers and the CF Meetup that I run.)
Anyway, it took only a few minutes for you to read this entry. I think you'll enjoy the full 45 minute version in the podcast, which you can just click here to listen to the MP3 (no need to have an Ipod!).