> From: "Raible, Matt" <[EMAIL PROTECTED]> > Sent: Wednesday, March 05, 2003 4:36 PM > Subject: RE: remember password HOW-TO?
> Actually, it *is* using form-based security. I just do a redirect to > "j_security_check" to mimic how a form's action submits to > action="j_security_check". Really? That certainly is crafty, and I'd like to think that it would work, but I'm a bit puzzled. Perhaps someone can clarify these points. My understanding is that the basic problems with interacting with Container based authentication are two fold. One is that the Servlet API provides no way for a Servlet to actually set the UserPrincipal, a Servlet can only access it. As seen by a Servlet, the UserPrincipal is an attribute of the Request, not of the Session. Your technique sort of mitigates this by directing to the container specific parts so it can Do Its Thing. However, my understanding of the path of a request is something like this: Request -> Mapper (determines where this URL should go, servlet, jsp, etc) -> Container Security (if Mapper points to protected resource, Security kicks in) -> Filters -> Servlets I'm under the impression that the Container Security layer is ABOVE the Filter layer. So, if you have a Container Security Managed resource that is also a Filtered Resource, then the Security will hit first before the Filter has a chance to do anything (in this example check a cookie and redirect). Now, this data flow is not enumerated at all within the spec, at least not in a nice blocky diagram. Filters can easily come before the Container Security, but I would think not as the filter may be doing something (say an Access Log filter) for a request that is later denied by Container Security, and then the user is passed on to either HTTP or Form based authentication. This would also be horribly nasty if for some silly reason the Filter had already started committing the response (which it's allowed to do). So, for simply sanity I'd think all of the Container Security would be done far before the Filters start firing. And I don't know how Container Security interacts with RequestDispatcher. If a unsecured request tries a .include or .foreward call. I'm guessing not at all. But, all of this tells me that Container Security is really just a thin veneer hammered in place between the original request and the rest of the Container. Anyway, I'm not saying your implementation does not work, obviously it does, or you wouldn't be using it. However I would be curious to see your security-contraint tags and filter-mapping tags. Regards, Will Hartung ([EMAIL PROTECTED]) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
