Enabling debug info for specific IP addresses in "/admin/web/cfm"

Hi Team,
I need to enable the debug info in the application for a specific IP address(Admins of Application). I have performed the below:

  1. Enabled log result at the end of every request from “Debugging - Settings”
  2. Created a template from “Debugging - Templates”. Here in the “IP Range” field i have provided the My IPV4 IP address but i am not able to see the debug info below the requested url.
    PS: If i use “*” in “IP Range” everyone is seeing debug info. Which is not needed. I need to enable to specific IP addresses.

OS: Ubuntu 18.04.5
Java Version: Open jdk “11.0.7”
Tomcat Version: 9.0.35
Lucee Version:

any cdn / proxy involved?

otherwise, if debugging capture is enabled, you can always just toggle <cfsetting showdebugoutput="true/false"> in your own code

I am hosting application from apache via creating a site. Which is accessible via a custom port 7444. Here mod_proxy is also enabled.
I am able to see the debug info, If i mention “*” in IP Range at hostname:port/lucee/admin/web.cfm -> Debugging - Templates.But i want to enable debug only for few people.
We are going to production on this Friday, Any help is greatly appreciated.

Difficult to say, because depends on your scenario.

  1. What comes to my mind is to make use of cfsetting showdebugoutput attribute on application level (just like @Zackster mentioned) . You could do some type of session login, and enable their debugoutput to true in application.cfc. But as far as I know this only omits the debug information, and might be an overkill because all the debug tracing will still occur for the other users, but do debug output generated. But I’m not totally sure.

  2. Another idea would be to create a second virtual host with an alternative domain (e.g. a subdomain) for these users, make some type of basic auth via SSL, and set the web admin for this domains to enable debug.

Maybe others have more suitable solutions for you.

just try 5.3.7 :slight_smile:

if something doesn’t work and you are on an older release, first try the latest release, if it doesn’t try the latest snapshot, my Lucee support mantra

1 Like

I am using “”. I cannot switch at this position to 5.3.7.
Question: 5.3.7 is a stable build?
If i setup another virtual host, Can the same code base folder () be used in apache configuration for both the sites. Will it not create any problems?
If so, i can create one and enable debug info in it. And will not publish to user(s). Please confirm.

the latest stable is 5.3.7, you need to test it and confirm

multiple instances can point to the same code base with problems

I have to withdraw that suggestion: If you use the same docbase with two virtual hosts, Lucee will still create one web-context only. Just saw that on quick try on my local dev. Thus, if you change settings for one webcontext, the changes will apply also to the others. I think you’ll need to run another tomcat instance then, or run an server instance with commandbox on another port and connect those users to those ports, but I really can’t tell, it sound to me that suggestion is all too much. If IP filter doesn’t help, I’d go for a payed/sponsored help in your special situation and time pressure.

Another idea would be for the debugging templates to just work when you install Lucee. It sure gets tiring trying to get debugging output to work EVERY TIME we do an install. #Embarrassing.

@Scatterblak I’m not sure what you’re trying to add here. The debug templates and IP fitering work fine. I just spun up a new server an confirmed this. So, if you can’t get it to work, perhaps it’s user error? The actual issue the OP was reporting in this thread was also never determined so I can only assume this was user error on his part as well. I had no issues at all turning “on” debugging and adding a template to test.

If you believe you have a reproducible bug with how debug template work, then by all means please report it along with all the details. Making vague comments about how embarrassing the feature is doesn’t really do anyone any good.

@madhu.peyyala If you never did find a solution to this-- I would recommend temporarily setting your IP range to * and then looking at the “Remote IP” that’s being reported in the debug template. This is the IP that Lucee “sees” your traffic coming from.


Make sure the IP address restrcitions you have in place match this address. Also keep in mind, any proxies in your setup may be changing the way this remote IP is reported as Zac suggested in his first reply.

I apologize if my angst shown through on my original post – I’ve been banging my head against this issue for hours. The short answer is, I’ve added my IP (and also tried just a ‘*’), and tried both the classic and the modern templates - on one machine running everything works great, on another machine running the same version, nothing. No logs written, no debugging information, and everything in the administrators (caching, extensions, etc) all set exactly the same. Believe me, I’d LOVE for it to be a bonehead error on my end - I’d eat the crow and get back to work! I can’t even say it’s a bug because I don’t know if I can reproduce it (though I may spin up another virtual tomorrow and find out).

Short answer: I’ve done all that stuff. It works fine on one machine, and not at all on another.

The first thing I’d check is the “debugging” > “Settings” > “Enable debugging” setting. Make sure it’s set to “yes” or nothing related to your debugging templates will kick in.

This is another crosspost. I understand that enabling debugging might have some pitfalls. The most common are:

  • debugging needs to be enabled in the admin of the same web context.

  • you need to setup two things: 1. the parameters to be logged (as stated by @bdw429s) AND 2. the template for the output

  • you need to make sure you didn’t disable debug output at application level with cfsetting.

  • if you are using a specific IP instead of the wildcard * as IP filter, make sure your IP matches the IP Lucee is seeing. Your IP might be changed by proxy interceptions. Look into your acceee log files or cfdump cgi.remote_addr

Please see also this video from Mark Drew: