Ask a Jedi: Password protecting CFIDE

coldfusion (This post is more than 2 years old.)

Andy asks:

What directories under CFIDE should be blocked/protected from public access on a public ColdFusion server? Is only preventing access to CFIDE/administrator good enough? How about CFIDE/adminapi? Any others that should be blocked? I tried searching the Adobe website, but I could only turn up a note regarding ColdFusion 4 and 4.5!

I'm pretty surprised by the fact that this hasn't been updated lately. I took a quick look at Livedocs, but didn't see anything that related to this.

I haven't done this myself in a while (I admit it - I'm lazy), but I'd think you would want to lock down these subfolders:

administrator
adminapi
classes (no need for folks to browse it)
componentutils

So I'm with you on administrator and adminapi. I mention classes and componentutils because there is no need for them to be visible anyway. But you can probablyg et away with just locking down the first two.

Any comments on this?

Hire Me!

I'm currently looking for my next role in developer evangelism and advocacy. I have a long history of helping companies work with developers and love to write, create demos, and present at conferences. You can find my resume to learn more and drop me an email (raymondcamden@gmail.com) to reach out.

Support this Content!

If you like this content, please consider supporting me. You can become a Patron, visit my Amazon wishlist, or buy me a coffee! Any support helps!

Want to get a copy of every new post? Use the form below to sign up for my newsletter.

Archived Comments

Comment 1 by Justice posted on 5/11/2007 at 7:41 PM

I prefer the method of blocking the entire directory other than local IP addresses or some other method, then copying the necessary scripts somewhere onto the web root and creating a mapping to them. By default: deny all. Safest that way =)

Chris

Comment 2 by Damon Gentry posted on 5/11/2007 at 7:54 PM

CFMX 7 provides another alternative. In the Administrator, you can simply specify the 'scripts' directory (defaults to /CFIDE/scripts). This directory is used by the CFFORM tag to reference JavaScript for client side validation. Simply change that value to /_cf/scripts and copy the contents of the /CFIDE/scripts directory into that location in your doc root.

At this point, you can remove the web server mapping (or Virtual Directory) to /CFIDE. You can still access the Administrator on port 8300 (or whatever you have it set to).

If you're still running CFMX 6, 6.1 or CF 5, then you can just copy the /CFIDE/scripts folder to the doc root and then eliminate the web server mapping.

Yet another method:
You can also disable the built-in JRun web server, and set up another virtual host that accepts requests on some odd port (like 8300, 8080, or whatever you want). This 'new' web server is connected to the JRun proxy port and has a mapping for /CFIDE. Then, you can use web server authentication or IP restrictions to restrict access to your CF Admin pages.

Finally, if you have any firewalls or proxies between your web servers and your clients, you can use rules in those devices to restrict access to only internal IPs.

Comment 3 by Joe Mastroianni posted on 5/11/2007 at 7:56 PM

We basically put CFIDE under the default website and make it available only from localhost and the internal network IP. Unless I'm mistaken people will never be able to hit it unless they're on the VPN.

Comment 4 by Steven Erat posted on 5/11/2007 at 8:03 PM

Good post and good comments. I'll be sure to point people in this direction when the question comes up.

Comment 5 by Raymond Camden posted on 5/11/2007 at 8:05 PM

@Damon - Nice one. I wonder if Charlie is covering this in his hidden gems class.

Comment 6 by DK posted on 5/11/2007 at 8:27 PM

like Joe said, putting cfide on its own site and limiting it to a non-routable ip (i.e. localhost or 127.0.0.1) is one of the first steps to locking it down imho.

Comment 7 by Michael White posted on 5/11/2007 at 11:01 PM

but how would that affect applications that use flash forms, flash remoting, etc.