• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
0

Issue with ColdFusion 2016 Debugging Error Output

Participant ,
May 10, 2017 May 10, 2017

Copy link to clipboard

Copied

Debugging error output isn't restricted to the IPs specified to receive debugging output in certain cases.

This is an issue that has been around since at least ColdFusion 9, as far as I know.

Within CFAdmin, we have disabled the global error template (/CFIDE/administrator/templates/secure_profile_error.cfm) in order to enable error debug output for our debugging-enabled IPs.  The problem is that the template that dumps out error information is loaded and processed regardless of whether or not the user's IP is in the debugging IP list.  The "normal" way to get around this, as far as I know, is to specify an error template within your application.  For example, we do something along the lines of:

<CFIF NOT isDevIP> <CFERROR TYPE="Exception" TEMPLATE="ErrorTemplate.cfm"> </CFIF>

However, this doesn't catch everything.  Exceptions that occur prior to the <CFERROR> tag being processed will still result in all users seeing the debugging error output regardless of their IP address.  This means you need to have the <CFERROR> tag near the beginning of each request (including AJAX requests) to minimize the potential for exceptions to be generated before the tag is processed.

The real trick, however, is that certain types of exceptions will be triggered before the <CFERROR> tag is processed regardless of where they are in the code.  Consider the following:

<CFERROR TYPE="Exception" TEMPLATE="ErrorTemplate.cfm">

<CFIF

Blah blah blah

The unclosed <CFIF> tag is parsed before the <CFERROR> tag is processed, and all users will see the error.  (Invalid CFML construct found at line ...).  This can lead to code leakage as the error detail template includes code segments, line numbers, and stacktraces (if enabled in CFAdmin).

On the other hand, something like this behaves as expected:

<CFERROR TYPE="Exception" TEMPLATE="OnError.cfm">

<CFIF undefinedvariable></CFIF>

Blah blah blah

The OnError.cfm template is loaded instead of the debugging error output being output to the screen.  You can combine this with a <CFIF> check against the user's IP being in the debugger IP list to achieve the desired result, but only for exceptions that are triggered after <CFERROR> is processed.

To work around this in the past, I edited the detail.cfm exception template at, for example, \ColdFusion9\wwwroot\WEB-INF\exception\detail.cfm , and made it fist read the neo-debug.xml file (where CFAdmin stored the debug IP list) and check the user's IP.  If the user's IP was not in the iplist in neo-debug.xml, then I simply ran a <CFABORT> to prevent any leakage from occurring.  This also worked for CF10.

<CFWDDX ACTION="WDDX2CFML" INPUT="#XMLPARSE('C:\Coldfusion9\lib\neo-debug.xml')#" OUTPUT="neodebugxmlwddx">

<CFIF NOT LISTFIND(neodebugxmlwddx[2].iplist, CGI.REMOTE_ADDR)><CFABORT></CFIF>

However, in CF2016, the detail.cfm template isn't the same.  In fact, it's encoded entirely differently and I can't properly edit it.  (ColdFusion Builder won't even open it.)

1)  Is there a way to edit the detail.cfm or other exception templates for CF2016 to achieve what I want?  By default, they're located at C:\ColdFusion2016\cfusion\wwwroot\WEB-INF\exception\ , I believe.

2)  If not, is there another way to make them respect the debugging IP lists defined in CFAdmin?

3)  If not, is there some other way to allow specific IPs to see debugging output (including for exceptions), but to restrict other IPs from ever seeing it?  Using a global error template isn't an option unless there's a way to modify that template to call the regular template (using the same IP check as above) and properly pass all the error information to it.

Thanks

Views

3.0K

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines

correct answers 1 Correct answer

Participant , May 11, 2017 May 11, 2017

I've found a workaround.

1) Use the "Site-wide Error Handler" in CF Administrator (Server Settings, Settings, Site-wide Error Handler).

2) In the specified template, check against the IPs in the neo-debug XML file (\cfusion\lib\neo-debug.xml under the CF installation directory).  (See the previous post and the CFWDDX call.)

3a) For IPs not in the neo-debug.xml file, show our generic error template.

3b) For IPs in the neo-debug.xml file, simply include the detail.cfm file ( \cfusion\wwwroot\WEB-INF\e

...

Votes

Translate

Translate
Participant ,
May 11, 2017 May 11, 2017

Copy link to clipboard

Copied

I've found a workaround.

1) Use the "Site-wide Error Handler" in CF Administrator (Server Settings, Settings, Site-wide Error Handler).

2) In the specified template, check against the IPs in the neo-debug XML file (\cfusion\lib\neo-debug.xml under the CF installation directory).  (See the previous post and the CFWDDX call.)

3a) For IPs not in the neo-debug.xml file, show our generic error template.

3b) For IPs in the neo-debug.xml file, simply include the detail.cfm file ( \cfusion\wwwroot\WEB-INF\exception\detail.cfm under the CF installation directory).

If you change the "Enable Request Debugging Output" setting, make sure your custom template is still defined for the "Site-wide Error Handler".

In my testing, this achieves exactly what we want:

CFError still works as before and handling can be customized per site/application/whatever.

Errors that cause processing to halt before CFError is processed are handled by the "Site-wide Error Handler" template. Debugging IP Addresses we set in CF Administrator get redirected to the generic template with the info they expect. Everyone else gets a generic message.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Advocate ,
May 11, 2017 May 11, 2017

Copy link to clipboard

Copied

For me, I either set the CFERROR immediately or I use the application onError event which seems to install almost immediately. The only time errors happen before my trap is installed is a strange syntax error in application.cfc and it can't compile or if the CF service does not execute for whatever reason. Now I have had issues with my error handler using application and/or session variable that did not exist - like my logging object. For this I've learned to wrap a last ditch try/catch around my error processing logic. Example (sorry for typos, this is more pseudo code):

Error.cfm

<cftry>

     <cfset variables.originalError=error />

     ...

      <cfcatch type="any">

          <h1>We're Truly Hosed!</h1>

          <cfdump label="Secondary Error" var="#cfcatch#" />

          <cfdump label="Original Error" var="#variables.originalError#" />

          <cfabort />

     </cfcatch>

</cftry>

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
LEGEND ,
May 12, 2017 May 12, 2017

Copy link to clipboard

Copied

LATEST

https://forums.adobe.com/people/Steve+Sommers  wrote

Now I have had issues with my error handler using application and/or session variable that did not exist - like my logging object.

I've noticed that onError() doesn't always have access to variables set within onRequestStart() or onRequest(), so I just copied/pasted the variables being set from onRequestStart() and onRequest() into onError().  It's a bummer that I have to remember to update the ones in onError() if changed in onRequestStart() or onRequest(), but it works.

V/r,

^_^

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Resources
Documentation