[Looking for Charlie's main web site?]

Fixing CF: "Hey, how come ColdFusion debugging output is not showing up in my localhost testing?"

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

I'll be speaking at CFCamp 2016 in Munich, Germany, Oct 20-21. See you there!

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

"Use UUID for cftoken" in ColdFusion Admin does always not block use of 8-digit cftokens

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

CF911: Want to modify the CF Step Debugger's use of a random port?

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

My CFBuilder Debugger chapter (for CF9 WACK Vol 2) is online

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.

Ultimate list of CF debugging output template alternatives

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

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

Want to view CF debugging output for all running requests? Send it to FusionReactor

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.

How to determine your current client storage value

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.

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

Tweak your CF Debugging Output for better info about queries

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?

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

Solving CF 8 debugger error: the line debugger could not be contacted, DBGREQUEST

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.

More Entries

Copyright ©2024 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting