Wicket, Tomcat, Debian: Sometimes a little security goes way too far

Was up until 3am last night banging my head against another frustrating go-nowhere issue deploying Wicket on Debian Etch’s default Tomcat5.5.

Apparently the latest version (5.5.20-2etch1) has additional security headaches features which prevent wicket from functioning properly out-of-the-box:

  • First of all, there’s still an (as-yet-unsolved) mystery around why I couldn’t get Wicket to start up as a filter. Just the mysterious “ERROR: filterStart” which makes me want to feed Tomcat to angry lions. Worked around it by using Wicket in Servlet mode instead.
  • Tomcat’s juli.jar can’t access WEB-INF/classes/logging.properties. Fixed (in sledgehammer-like way) by adding “permission java.security.AllPermission;” to /etc/tomcat5.5/policy.d/03catalina.policy, in the Juli section.
  • Tomcat security prevents webapps from accessing all sorts of features and methods by default, including wicket.properties, methods inside shipped jars, etc. Not being a Tomcat expert, and trusting the innate security of the server and millions of lines of third party code (i.e. I’m an idiot) I again just popped a java.security.AllPermission; in appropriate spots in /etc/tomcat5.5/policy.d/04webapps.policy. Let the flames commence!

If Tomcat was a little more helpful in its error messages, this would never have been so painful. Jetty has always run my Wicket apps without complaint (though I’ve never tried the official Debian Jetty packages – maybe they’re crippleware secure too?).

The only reason I use Tomcat at all is the remote management and deployment features, which are well-supported by Cargo. Now that these issues are out of the way (mostly) I can take another few steps towards my dream of a seamless, fire-and-forget, auto-deploying, smoke-tested, pluggable and modular web app deployment system.

Oh, and have I mentioned recently how much I LOVE IInitializer?

Bless you, Wicket. Bless you.

3 thoughts on “Wicket, Tomcat, Debian: Sometimes a little security goes way too far

  1. Too bad you’re having troubles with Tomcat. Drop a note on the user list; maybe it will help others struggling with this, or maybe you’ll get some good feedback.

    I’m using Jetty for both development and as our production server, and we never really run into much trouble (couple of times, but it was easy enough to patch ourselves, and the Jetty people fixed the issues quick after).

    Just wondering: what are you using IInitializer for?

  2. IInitializer for initialising plugins to our in-progress CMS framework. Basically means we can drop in components which will automatically set up their own navigation entries, database entities, etc.

    Means I can construct a completely customised CMS with no code and no configuration – purely dependencies. Want a new feature? Just add a maven dependency.

    Sweet.

    Only thing to do now is keep a lid on complexity and make sure our component model makes sense. Am thinking back to the hazy University days and design patterns and IoC containers…

Leave a Reply

Your email address will not be published. Required fields are marked *