Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@jakarta.apache.org Received: (qmail 56372 invoked by uid 500); 2 Aug 2001 04:41:30 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: tomcat-dev@jakarta.apache.org Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 56363 invoked from network); 2 Aug 2001 04:41:29 -0000 To: tomcat-dev@jakarta.apache.org Subject: Re: Cert Lockdown - 3.3 Integration Message-ID: <996727295.3b68d9ff1e0bd@www.mhsoftware.com> Date: Wed, 01 Aug 2001 22:41:35 -0600 (MDT) From: Christopher Cain References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 216.17.139.153 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Quoting cmanolache@yahoo.com: > On Wed, 1 Aug 2001, Christopher Cain wrote: > > > I followed the whole startup routine from Tomcat.startTomcat() all > the > > way through where the ContextManager calls the > > ServerXMLReader.addInterceptor(). That's where the whole > hairy-chested > > XML parsing begins, and my brain started hurting :-) Up to the point, > I > > have a pretty good grasp of the process. > > That's where the fun starts :-) So I gathered ;-) > The processing is very simple. First, modules.xml is read - like > taskdefs in ant, it associates a tag name with a java class. Cool. I also got a detailed "how to set up your config files for the new module system" from Larry, so a big thanks to him as well (he's having IMAP woes :( so he forwarded it privately so that I could code on it ALL NIGHT tonight :-). I wasn't aware that the approach was more-or-less the deprecated way to interface a module, which would explain some of my confusion. Since the newer way sounds not only ... well, newer ... but also easier, I'll go with that. I really dig the way that the tag attributes have a corresponding setter methods in the object; how if I just name the setters correctly, everything just happens ... very slick. > I know, XmlMapper is a very bad hack. *shrug* ... Honestly, I couldn't tell you. I just know that my little brain couldn't process that level of abstraction at 5:30pm after having just finished a 4-hour whirlwind crash course in general container startup and config. It's kind of like giving a caveman a Packard Bell computer. He doesn't know if it's genius or not. He just knows that it's shiny and does things he doesn't understand. You should have just told me it was brilliant ;-) (Incidentally, and continuing my theme from the newly-ressurected "source code in the binaries" thread, I would like to propose in advance that the Tomcat 5 codebase be codenamed "Milton".) > I'm working on a replacement ( as a 3.3 module, of course :-). ... > > Finally, is the right answer to create a class that extends > > Http10Interceptor? It would inherit everything as-is, then adds a > calls > > out to my (self-contained for portability) "prompt getter" class, > > calling the existing PoolTCPConnector.setKeypass() method with the > > I don't think it's a good idea - just write a class that extends > BaseInterceptor, with all the attributes you need, then search for the > Http10Interceptor and set the property. > > I hope I can extended a bit your module, after you're done, to > check if the admin password and ajp12 passwords are set - and if not > to prompt the user. Far too many users forget this. By all means, my friend. Since I have no earthly idea what either the admin or ajp12 passwords do, or what they are, I promise not mind =) Seriously, though, just keep in mind that I am planning that broader "External Resource Security" module (explained in a half-assed fashion in a previous post). I haven't gotten any committer feedback on that yet, so I'm not sure what the general sentiments are on it. Of course if you don't personally like that one, or if the idea doesn't fly in general, I would have absolutely no objections to anyone extending this mod to suit their needs. But if you like the idea, those things may be perfect candidates for my "centralized repository" approach. > I think what you want is a configuration module, not a http ( connector ) > module. Even if it would work if you extend Http10Interceptor, it would not be > very clean. Yeah, that makes more sense. I was confused by the RequestInterceptor business, primarily because I couldn't see how to hook into the process without mimicking the current https RequestInterceptor. My module's lifecycle is complete once the user types in the password and hits ENTER, so leaving it sitting there in the middle of the request/response chain seemed weird. I now see how I can be a load-time module without being a connector. Thanks for the info! - Christopher