Tomcat: Disabling Directory Listings

This is the second in a series of posts detailing my efforts to stand up a Tomcat/ACF10 development environment next to my existing Apache/JRun/ACF9 stack. For background, see the first post in the series.

I will focus my initial configuration efforts on some basics for securing the Tomcat/ACF10 stack, addressing things I know the security scanning services on our network look specifically for. I will start with disabling directory listings provided by default when a browser requests a URL for a directory without a default document. In this post (and all future posts in the series, unless I specifically indicate otherwise), I will use paths based upon my installation of ACF10 in the default location on Mac OS X systems. By default ACF10 is installed in /Applications/ColdFusion10; you can translate as needed for your installation.

To disable directory listings, find the <servlet> element within file ./cfusion/runtime/conf/web.xml. Within that element, find (or insert) an <init-param> element with a child <param-name> element with a value of listings. Set the <param-value> element to false.

<servlet>
   <servlet-name>default</servlet-name>
   <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
   ...
   <init-param>
      <param-name>listings</param-name>
      <param-value>false</param-value>
   </init-param>
   ...
</servlet>

Restart the server, and we can check this one off our list.

Exploring Tomcat and ColdFusion 10

With the recent availability of a pre-release version of Adobe’s ColdFusion 10 CFML engine, I am going to be doing a bit of comparative exploring to see how this upcoming version lines up against the current 9.01 version. My intent is to install and configure ACF10 on one or more of my development systems in a manner where it can run alongside the currently-installed ACF9 so that I can get a feel, in particular, for any performance differences between these two versions and to ensure that when ACF10 is officially available, any compatibility issues with our CFML-based applications have been addressed.

My current development systems are Mac OS X and Linux boxes, running ACF 9.01 under Apache’s Web server. I will install ACF10 in a stand-alone mode in order to be able to run both servers concurrently. In this mode, ACF10 will be running with the bundled Apache Tomcat server for use as both its application server (replacing the JRun application server historically used with ACF) and as its Web server.

The first portion of this effort, then, will focus on getting ACF10 and Tomcat configured to function as needed in my development environment. With that in mind, I will be exploring the following Tomcat-related configuration needs and blogging about them (as well as anything else of interest I stumble into) in the coming days:

You can see that list is a mix of security-related settings and configuration settings related to how our application folders are structured (and the desire to run these applications through both the new Tomcat/ACF10 stack and the old Apache/JRun/ACF9 stack).

In terms of structure, all of the applications reside in a folder outside of the Apache webroot, and are found via a set of aliases. The folder structure below that top-level folder is set up as follows (with their corresponding application URL’s listed in parens):

  • appGroup1
    • common
    • app1a (http://localhost/app1a/)
    • app1b (http://localhost/appab/)
    • app1c (http://localhost/app1c/)
  • appGroup2
    • common
    • app2a (http://localhost/app2a/)
    • app2b (http://localhost/app2b/)
    • app2n (http://localhost/app2n/)
  • app3 (http://localhost/app3/)
  • shared

Within each of the application groups “appGroup1” and “appGroup2”, the “common” folder contains assets shared by the applications in the corresponding group; this folder is aliased into each of the individual applications within the group to appear as if it were nested below the application folder (e.g., http://localhost/app1a/common, http://localhost/app1b/common). All of the applications reference the “shared” folder as a root level folder “/shared” (i.e., as http://localhost/shared).

Further, most of the applications have a default document that relies on SSI to function properly as part of the applications’ respective authentication and security framework. I also do all of testing and prototyping in a folder immediately off of my home folder; I will need to have that folder served by Tomcat/ACF10 just as it is currently under the other stack.

Finally, a caveat: I am a complete noob when it comes to Tomcat, so I will be learning as I go. I am almost certainly going to find sub-optimal ways to make portions of the work. If you see such mis-steps and have recommendations for other and/or better ways, please point them out in the comments on each post.

We have our work cut out for us. Stay tuned.