Note: This blog post is from 2018. 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.

This is a problem that has troubled many CF users for some years (especially as they have moved to later operating systems): they find that ColdFusion debugging output does NOT appear to them when testing using a URL with "localhost" for the domain name but it DOES appear if they use the 127.0.0.1 ip address instead.

TLDR (and update since initial post):
If you can add ::1 to the list of debugging IP addresses in the CF Admin, that should solve this problem. If you cannot, that problem was fixed a few months after I wrote this, in CF2018 update 2 and CF2016 update 8, released in Feb 2019 (and it's no longer a problem on CF2021 and above, of course). For those not yet running those, if you find that adding ::1 just turns into 0:0:0:0:0:0:0:2, read on.

For more on the matter, including why it happened, solving it, etc., read on.

[....Continue Reading....]

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.

I'm delighted to announce that I'll be presenting again this year at CFCamp, in Munich, Oct 20-21.

[....Continue Reading....]

Note: This blog post is from 2013. 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.

This topic came up on a discussion list, in the context of a larger thread, and I wanted to share here what I said there.

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.

1. 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.
2. 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.
3. 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.

[....Continue Reading....]

Note: This blog post is from 2010. 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.

Here's a quick tip (and some elaboration): if you've noticed that the CF step debugger (in CF 8 or 9) causes CF to listen on a randomly changing port, you can change that behavior (assuming you have good reason to do so, such as perhaps some challenges with firewall configuration).

It's a simple JVM tweak to cause it to use a fixed port:

-DDEBUGGER_SERVER_PORT=portNumber

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

[....Continue Reading....]

Note: This blog post is from 2010. 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.

Here's good news for folks seeking more documentation on how to configure, use, and troubleshoot the ColdFusion Builder debugger.

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.

(Update: It was previously offered as one of 3 chapters available at Ben's site. The link I had long used, (forta.com/books/0321679199/CFWACK9-2-echapters.pdf) no longer works, so I created my own version of it for posterity.)

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.

Note: This blog post is from 2010. 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.

Following on the heels of my "Ultimate Var Scope Resource list" last week, here now I present what I think is the ultimate list of CF debugging output template alternatives.

Yes, you CAN modify the debugging output. Some have even done it for you

Many 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 reload

You 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 site

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

Note: This blog post is from 2009. 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.

We all know that showing debug output to end users is a no-no, but sometimes don't you wish you (as an admin) could have access to what debugging info the users would have seen while their requests are running? What if you could capture the debugging info to view it for all running requests, and better still, keep it for a short time to view about hundreds of recent requests?

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.

Note: This blog post is from 2008. 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.

This may be a surprise to some: it was to me. I learned today for the first time that it's possible to find out (in code) for a given CFML app what client storage repository it's using:

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.

Note: This blog post is from 2008. 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.

Hey folks, if you've ever wished that the CF debugging output had some improvements, did you know you don't need to wait for Adobe to do it?

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.

Note: This blog post is from 2008. 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.

Folks, if you're trying to use the CF8 Debugger (something I've written about a lot), you may get this error when first setting things up:

Test Debugger Failed An RDS connection was established but the line debugger could not be contacted. The server gave the following message:

DBGREQUEST

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.