On Fri, 14 Feb 2003, Bryan Field-Elliot wrote:
> Date: 14 Feb 2003 11:55:46 -0700 > From: Bryan Field-Elliot <[EMAIL PROTECTED]> > To: Tomcat Users List <[EMAIL PROTECTED]> > Cc: Craig R. McClanahan <[EMAIL PROTECTED]> > Subject: Re: JAASRealm/LoginManager questions > > I was discussing these issues with Jason Hunter, whose opinion is > quoted: > > BFE> Craig was basically saying, don't assume any particular behavior > which > BFE> isn't specified in the spec. So, it's not safe to assume that it > will > BFE> be supported to POST to j_security_check a couple of requests > later, > BFE> rather than on the very next request. Bum deal. > > JH> That makes perfect sense. The one argument you have back is that > Tomcat > JH> is the RI so if Tomcat does it then that's how it should be done, > and > JH> then ask him to make sure Tomcat does it. > > What do you say, Craig? ;) > > It really opens doors, flexibility-wise, to store the "original URL > which triggered the authentication request" as a session attribute, and > allow multiple requests to occur in the interim, before the authN > request should be considered "satisfied" by a POST to j_security_check. > > It presupposes that none of these intervening requests can be protected > by a security constraint, otherwise you'd throw the container into an > endless loop. ;) > It's interesting but not timely, for two reasons. First, Servlet 2.4 is in Proposed Final Draft state, and this is not a trivial are of functionality to start messing with. The Servlet expet group looked at some notions of adding programmatic login support this time around (so you don't have to abuse and misuse form based login in the manner you propose :-), but decided not to this time around. Second, it's somewhat premature to address this in Servlet 2.4 anyway, because of JSR 196 (Java Authentication Service Provider Contract for Containers). It is pointless to change something now and then have to change it again in response to whatever develops there, while incorporating the new SPI stuff into whatever follows Servlet 2.4 is a lot more sensible. With respect to "Tomcat is the RI so if Tomcat does it then that's how it should be done." I suspect he's referring to an interesting comment in the preface of the Servlet spec. Unfortunately, this argument falls down on two grounds: * Tomcat is *not* the reference implementation for the servlet API -- its code is the *basis* for the reference implementation. At this point in time, the official RI for servlet (and JSP) is the J2EE Reference Implementation -- whose web tier code is certainly based on Tomcat, but is not necessarily identical. So, even if an Apache Tomcat release implemented something like this, that doesn't automaticaly enable the "the RI does it" argument. * The instruction to look at the RI for guidance only applies when "the specification leaves the implementation of a particular feature open to interpretation". That is not the case in what you are proposing -- what' you're propoosing is an additional feeature beyond the specification. Form based login is not the right place to solve the real underlying problem here -- what you're looking for is a way for an application to programatically log someone in. Trying to corrupt an algorithm designed for interactive user authentication to accomplish this is a really lousy way to accomplish that goal. Building a standarized programmitic login is the right answer. That's just not going to be able to happen this time around. 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. > Thanks, > > Bryan > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
