I'm not sure what you are referring to. Since the beginning, HttpClient supports HTTPS (through the use of JSSE). Thus it is possible to call a web server which has SSL turned on.
-Vincent > -----Original Message----- > From: Peter Wong [mailto:[EMAIL PROTECTED]] > Sent: 17 December 2001 19:01 > To: Cactus Developers List > Subject: RE: Security testing in Cactus > > > > Hi, > > I just looked at httpclient's nightly built code and did not see > certificate auth. > > Peter > > > > > "Peter Wong" <[EMAIL PROTECTED]> on 12/17/2001 12:14:32 PM > > Please respond to "Cactus Developers List" > <[EMAIL PROTECTED]> > > To: "Cactus Developers List" <[EMAIL PROTECTED]> > cc: > Subject: RE: Security testing in Cactus > > > > Hi, > > I didn't mean to exclude the basic authentication; I just like the > form-based & certificate ones better. > As for httpclient, the last time I looked(mid October), I recalled > seeing support for basic but not for certificate. > Let me download the source again to look at it. > > Peter > > > > > "Vincent Massol" <[EMAIL PROTECTED]> on 12/17/2001 11:57:40 AM > > Please respond to "Cactus Developers List" > <[EMAIL PROTECTED]> > > To: "'Cactus Developers List'" <[EMAIL PROTECTED]> > cc: > Subject: RE: Security testing in Cactus > > I wouldn't exclude basic authentication, which is also widely used. > Regarding SSL, you're right, we would have to support it in Cactus, > which is why I'm advocating moving to Commons HttpClient which does > support it. Thoughts ? > > -Vincent > > > -----Original Message----- > > From: Peter Wong [mailto:[EMAIL PROTECTED]] > > Sent: 17 December 2001 17:36 > > To: Cactus Developers List > > Subject: Re: Security testing in Cactus > > > > > > > > Hi, > > > > It seems to me that the 2 important authentication schemes are > > form-based and certificate via ssl. > > > > Peter > > > > > > > > > > "Vincent Massol" <[EMAIL PROTECTED]> on 12/17/2001 11:14:27 AM > > > > Please respond to "Cactus Developers List" > > <[EMAIL PROTECTED]> > > > > To: "'Cactus Developers List'" <[EMAIL PROTECTED]> > > cc: > > Subject: Security testing in Cactus > > > > Here is a summary on my views for supporting Security testing in > > Cactus > > : > > > > First, there are 2 areas Cactus users may wish to test : > > 1/ Programmatic security logic : This means to be able to unit test > > methods which have calls to getRemoteUser(), isUserInRole() and > > getUserPrincipal(). > > 2/ Security integration testing : Verify that the security mappings > in > > web.xml and the interaction with the container work ok. > > > > * 1/ is easily achievable by adding a > WebRequest.setCredentials(String > > username) and a WebRequest.setCredentials(String username, Vector > > roles). The HttpServletRequestWrapper would use this information to > > return expected values from getRemoteUser(), isUserInRole() and > > getUserPrincipal(). However, this does not verify the interaction > with > > the container. On the other hand it is very easy to implement and > can > > make it in Cactus 1.3 > > > > * 2/ is more difficult for 2 reasons : > > - the client part of Cactus need to be able to handle the > different > > authentication schemes (Basic Authentication, Form-based > > authentication > > and possibly Digest Authentication - although seldom used so we > could > > probably drop this one). Thus the client part of Cactus is becoming > > complex and I think it would need refactoring. It would be high time > > to > > move to Commons HttpClient and maybe even participate to include the > > feature it might be missing (notably, we need to verify if it > supports > > these authentication schemes). > > - We probably don't want to secure the Redirector Servlet as it > > would > > mean all tests will run in this secure mode whereas we may only wish > > to > > test security for such and such test cases. Thus before doing this, > we > > would need to implement a per testcase configuration (as discusses > in > > the past on this list (see thread "[proposal/poll] Per testcase > > configuration of web.xml" in archives). Another solution is to > figure > > out a way to have a per testcase redirector. > > > > To summarise, we can certainly include 1/ in Cactus 1.3 but 2/ would > > need more thinking and more work. We could target it for Cactus 1.4. > > > > What do you think ? > > > > Thanks > > -Vincent > > > > > > > > -- > > To unsubscribe, e-mail: < > > mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: < > > mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > > > > -- > > To unsubscribe, e-mail: <mailto:cactus-dev- > > [EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:cactus-dev- > > [EMAIL PROTECTED]> > > > > > -- > To unsubscribe, e-mail: < > mailto:[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]> > > > > > > > > > > -- > To unsubscribe, e-mail: <mailto:cactus-dev- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:cactus-dev- > [EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
