On Fri, 14 Feb 2003, Will Hartung wrote:
> Date: Fri, 14 Feb 2003 14:16:02 -0800 > From: Will Hartung <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: Tomcat Users List <[EMAIL PROTECTED]> > Subject: Re: JAASRealm/LoginManager questions > > > From: "Craig R. McClanahan" <[EMAIL PROTECTED]> > > Sent: Friday, February 14, 2003 1:28 PM > > Subject: Re: JAASRealm/LoginManager questions > > *snip* > > That's the biggest problem with specifications, you kind of have to be a bit > of a lawyer to conform with them. It is also why while the goal of any > specification is to be functional, it's even more important (particularly in > the case of a spec with as wide a reach as the Servlet spec) to be clear. > "Functional" is certainly one goal, and improving/increasing functionality is the main thing that happens in spec versions after 1.0 releases. >From an application developer's viewpoint, "portability" is also an important goal. It is achieved by the confluence of two behaviors: * Containers promise to faithfully implement what the specs *do* say, so that application developers can count on features being implemented in the same manner everywhere. Compatibility tests for the specs try very hard to catch violations of this, but it's not always possible or cost-effective to catch all such violations (for the same reasons that very few nontrivial applications have 100% coverage in their unit tests). * Application developers promise to rely only on things that are explicitly spelled out in the specs, or at least explictly understand that when they go beyond the specs for extra features (or perhaps even unknowing dependence on bugs in the container's implementation of a spec feature :-), they risk compromising the portability of their application. Human nature being what it is, the temptations to "cheat" on both of these behaviors is common, and it can be argued in many circumstances that it is quite legitimate (container vendors use above-and-beyond-the-spec features to differentiate their products; developers who don't care about portability to different containers have no reason to avoid becoming dependent on container-specific behaviors; a cool new feature in one container gets kind-of adopted as a defacto standard before it gets formally standardized). And that's all fine. In the particular use case being discussed (at length :-) on this thread, the proposal was to use a feature already defined in the spec (form based login) for a purpose to which it was not intended (programmatic login). As we've discussed, there's no portable mechanism to accomplish programmatic login in the current version of the servlet spec. Tomcat provides a straightforward mechanism to customize things like per-request processing before the application's filters and servlets are invokved (Valves), as well as other things (such as Realms, which abstract the location of the usernames and password information). The right answer in this particular use case is to explicitly utilize those features until there is a portable mechanism to accomplish the goal. > > In the mean time, there's a perfectly reasonable (albeit container > > dependent) way to accomplish what you want in Tomcat. And, even if Tomcat > > did implement the form-based login wierdness you want, you're *still* > > stuck with the fact that no other container would necessarily follow > > Tomcat's lead on this. > > Let me head over to the corner, grab my stool and white, pointy "Ignorant" > hat here as I butt in, but could what you want to be done be done portably > using Filters? IMHO Filters are the most powerful aspect of the 2.3 spec as > they provide a great layering and request trapping mechanism in a portable > way with which you can do just all sorts of truly horrible things. > > I'd be very interested to hear why a Filter would NOT work in this case, but > as I said, I haven't been totally following the thread here. It's probably > glaringly pointed out on line 12 of the initial post (RTFML Will! STFU!). > Well, we've explored that approach already earlier in this thread :-). Unfortunately, it won't help because filters do not get executed until after any authentication has already occurred. Therefore, you cannot use them to initiate an authentication programmatically. By the way, enabling programmatic login at all raises pretty significant security concerns -- how positive are YOU that nobody can inject, say, some JSP or servlet code into your web application (perhaps through some cross site scripting flaw in the way you process input forms), and thereby bypass all of your application's security provisions? Making something like that possible is not a decision to be taken lightly. > Humbly... > > Regards, > > Will Hartung > ([EMAIL PROTECTED]) Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
