Hi Craig, That is pretty much the implementation that I have been working on. I am not an expert on the HTTP protocol, and less on the behavior of a web container, so..
What is the best way to process the request in the same way as if it had been processed without the security piece getting in the way. My current implementation is storing in the session variable the value of the http parameters, and re-attaching them when the second stage of the authentication is completed, but I guess that the referrer header is not 'correct' (in that is is no longer the page that caused the reference), and I don't know what else needs to be remembered, and patched. The second problem that I have is more serious. If you consider the following Index.html -> /secure/foo.jsp ( which is protected) This causes login.jsp (form based authentication) which posts the action to j_security_check, whci hits the filter and gets redirected to login2.jsp. When the user submits this, and assuming that the details are correct I forward the request to the original request (but I cant set the post data parameters, so I intercept the request within the filter and supply the remembered http parameters, by modifying the HttpServletRequest that is passed down the chain). How do I defferntiate between a user refreshing that page, and a new request. I guess that his logic is in the j_security_check implementation so I was hoping that I could re-use it. What is th mechanism that the j_security_check uses to get around this problem? Mike > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Wednesday 28 August 2002 19:40 > To: Tomcat Users List > Subject: Re: Extended authentication > > > > > On Wed, 28 Aug 2002, Mike Skells wrote: > > > Date: Wed, 28 Aug 2002 19:21:49 +0100 > > From: Mike Skells <[EMAIL PROTECTED]> > > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > > To: 'Tomcat Users List' <[EMAIL PROTECTED]> > > Subject: Extended authentication > > > > Hi, > > I am developing an application where there is a need for extended > > authentication, in addition to that of usernam/password, some > > additional challenge/response > > > > Is there any way to protect a web app so that the extra > parameters can > > be prompted for in a 'standard' way > > > > I know that I can use froms based authentication, but how do I > > separate the username/password validation from the > forwarding of the > > request. > > > > Ideally I would like to validate the usernam/password, and > then take > > the user to a subsiquent page that does additional validation. > > > > I had a look at JAAS to do this, but I cant see that this can be > > plugged into a web app, without redeveloping the web app to > explicitly > > check, which rather defeats the purpose of the security > system in the > > first place. > > > > Is there any way to do this. All that I can think of is by using a > > filter for all of the secure area which is processed after the > > security check pass, but this means a re-implementation of the > > facilities of the j_security_check which is hardly neat > > > > Any ideas > > > > Doing any sort of validation that requires additional round > trips to the user is going to be pretty challenging to > implement, and is not supported portably by the servlet spec > at this time. Basically, you are going to be on your own in > the mean time. > > However, simulating your scenario for "subsequent page extra > checking" doesn't seem that difficult. A strategy like this > would probably work: > > * Define a session attribute that (if it exists) includes > the results of your extra checking. > > * Add a Filter or some logic at the beginning of every page > that routes the user to your extra page if this session > attribute doesn't exist. > > * The servlet that responds to the "extra page" form post > can create this session attribute and then redirect the > user back to the menu. > > > > Mike > > > > Craig > > > -- > To unsubscribe, e-mail: > <mailto:tomcat-user-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
