coldfusion 2023 debugging ip address list does not work

Forum|Forum|1 year ago
June 12, 2024
2 replies
2020 views

I am using Coldfusion 2023 (developer version, for now while I test it).

In the debugging IP address section (see image below) I have entered 127.0.0.1

But, it doesn't matter what IP address I connect from, I still see the debugging info when I test with a .cfm page that has an error in it.

I thought that debugging info would only show if I connected from the ip address in the debugging list.

Is there something else that I need to configure?

This topic has been closed for replies.

Correct answer Charlie Arehart

If I may step in, there's no bug here to report, for reasons I will explain. And I'll offer a couple alternatives besides your wise decision to go with an error handler. With all due respect to everyone trying to help so far, this issue is one that can trip up lots of folks--so don't feel bad for struggling with it, Jeff . 🙂

First and to the main concern you raised here, the debug output setting and ip address features in fact have ZERO to do with the error details you're reporting and are concerned to hide (rightfully so). Instead, note that on that Cf admin debug output settings page there is the "robust exception handling" option, which controls how much DETAIL is shown in error messages. Unchecking that, alone may have suited your need.

(It's indeed unfortunate that this setting is on that page. It can lead to reasonable confusion with other debug output which IS controlled by that debug ip list.)

Second, as you've now found, using an error handler (site-wide or app-level) is indeed the way to prevent a user seeing ANY error info from CF. And yes, you could send that error info to yourself in such an error handler (and/or log it, or store it in a db, etc.)

And finally to further address the reasonable security concern over error messages, note that cf10 and above offer a secure profile feature (in the admin security section), which if enabled would set a site wide error handler--if you've not set one yourself--and that would show the user a blue ball and only a very brief indication that there was an error (and it also logs the error).

Hope that's helpful, and sorry I'm only now seeing this. I was out of the country last week at the cfcamp conference in Germany. This is a great topic to help get clarified for the community every once in a while! 🙂

I welcome any feedback. As always, just trying to help. (Sadly, the intent behind words on screen can often be misconstrued. I've tried to write carefully here.)

Charlie Arehart

Correct answer

Community Expert

If I may step in, there's no bug here to report, for reasons I will explain. And I'll offer a couple alternatives besides your wise decision to go with an error handler. With all due respect to everyone trying to help so far, this issue is one that can trip up lots of folks--so don't feel bad for struggling with it, Jeff . 🙂

First and to the main concern you raised here, the debug output setting and ip address features in fact have ZERO to do with the error details you're reporting and are concerned to hide (rightfully so). Instead, note that on that Cf admin debug output settings page there is the "robust exception handling" option, which controls how much DETAIL is shown in error messages. Unchecking that, alone may have suited your need.

(It's indeed unfortunate that this setting is on that page. It can lead to reasonable confusion with other debug output which IS controlled by that debug ip list.)

Second, as you've now found, using an error handler (site-wide or app-level) is indeed the way to prevent a user seeing ANY error info from CF. And yes, you could send that error info to yourself in such an error handler (and/or log it, or store it in a db, etc.)

And finally to further address the reasonable security concern over error messages, note that cf10 and above offer a secure profile feature (in the admin security section), which if enabled would set a site wide error handler--if you've not set one yourself--and that would show the user a blue ball and only a very brief indication that there was an error (and it also logs the error).

Hope that's helpful, and sorry I'm only now seeing this. I was out of the country last week at the cfcamp conference in Germany. This is a great topic to help get clarified for the community every once in a while! 🙂

I welcome any feedback. As always, just trying to help. (Sadly, the intent behind words on screen can often be misconstrued. I've tried to write carefully here.)

/Charlie (troubleshooter, carehart. org)

J

jeff38011374seqkAuthor

Participating Frequently

Hi Charlie,

You are correct, I did think the two settings were linked (detailed info shown on error messages and the allowed debug IP addresses).

I agree - it would probably be better if the setting were on different pages so that there is no confusion about the relationship between the two (i.e. that there is no relationship between them).

In the meantime, I'm happy with the way I have things set now (site-wide error handler in place, no error details shown to end users and detailed error messages emailed to myself)

BKBK

Community Expert

Thanks for that, Jeff, and for marking that reply as an answer. (And understood, that your using the error handler solved things--as I'd acknowledged in my reply.)

Finally, for everyone following along, I have just created a tracker ticket for the issue, requesting that Adobe consider moving that setting out of that page: CF-4222564 . It really is important that people interested in the matter at least add a vote, as Adobe is motivated by those.

+1 voted for CF-4222564

D

Dave Watts

Community Expert

What IP address do you see in the CF debug output?

Dave Watts, Eidolon LLC

J

jeff38011374seqkAuthor

Participating Frequently

I'm testing from a remote computer (see below). So, I wouldn't expect the remote computer to get debugging messages since it isn't in the IP debugging list. I am assuming there must be something else that needs to get configured, but I can't figure out what that might be.