Hi Jason/Michael, I don't believe HTTPS will work with the current version of Cactus. We're using HttpClient to make the connection to the server side. Thus the first thing to look at is how to enable HTTPS in httpclient. I think we need additional jars (jsse.jar and one or 2 others). Then we may need to change a few lines in Cactus code to allow this.
Who wants to submit a patch? :-) Note: It's a nice to have feature but I don't believe it has any impact on unit testing any part of the code. Thanks -Vincent > -----Original Message----- > From: Robertson, Jason [mailto:Jason.Robertson@;acs-inc.com] > Sent: 29 October 2002 15:37 > To: 'Cactus Users List' > Subject: RE: FormAuthentication > > Here's my "SimpleFormLogin" project. This is project source, so look into > the build.xml file and adjust the "<!-- Jar files -->" section to fit your > setup. > > As far as I know, form authentication over https shouldn't be a problem as > it's really not much different than any other form submission. As long as > the server is setup right and the context URL has https I'd assume it > would > all work, but I've never tested it. > > Jason > > -----Original Message----- > From: Koegel, Michael [mailto:Michael.Koegel@;partner.commerzbank.com] > Sent: Tuesday, October 29, 2002 3:23 AM > To: Cactus Users List > Subject: AW: FormAuthentication > > > Hi Jason, > > I would also be interested in this FormAuthentication Example. > I didn't follow the discussion closely the last couple weeks is it also > possible to test form based login with https? > > Regards, > Michael > > -----Ursprüngliche Nachricht----- > Von: Robertson, Jason [mailto:Jason.Robertson@;acs-inc.com] > Gesendet am: Montag, 28. Oktober 2002 21:35 > An: 'Cactus Users List' > Betreff: RE: FormAuthentication > > I think this is a good solution. Separate WAR files is the only way I know > of to use different authentication techniques. > > Plus, the side effect of making a clearer separation between the example > and > the unit tests I agree is a good thing. > > Do you want my test app? It's just a very simple web app with pages to do > the form authentication as well, so you have a 2nd avenue to test > configuration if you're having troubles with cactus. Its the one I used to > test Tomcat and WLS. I'm sure it can be easily adapted to any other J2EE > server. Let me know and I'll try to bundle it up. > > Jason > > -----Original Message----- > From: Vincent Massol [mailto:vmassol@;octo.com] > Sent: Saturday, October 26, 2002 2:12 PM > To: 'Cactus Users List' > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: FormAuthentication > > > Hi Jason/Pranab, > > Thank you both for the good analysis! There are indeed 2 bugs you have > found: > - one with the FormAuthentication using only the default redirector > - one with the HttpClient fetching the test result using only the > default redirector > > I have now fixed (hopefully) both bugs in CVS. You can check the CVS > commit emails if you wish to see what I have modified. I would be happy > to know if you agree with my changes... :-) > > However, there is still something missing which I was not able to code: > it is a test for the FormAuthentication class. The problem is that > apparently you can only have one method of authentication in a given > webapp and ATM the sample webapp is using Basic authentication... Thus > we cannot easily add one more test for testing Jason's > FormaAuthentication code ... I was pondering about what route to take > for that. Any idea? > > One solution would be to have several webapp of course and more > specifically to have the following directory structure in CVS: > > jakarta-cactus > |_ [...] > |_ servlet-sample > |_ servlet-unit > > servlet-sample: contains only the org.apache.cactus.sample.* packages. > It is the sample application. > > servlet-unit: contains only the org.apache.cactus.unit.* packages. The > goal of this application is to offer a full regression test suite for > Cactus. It is not a sample application per see. The idea would then be > to have a build file that produces 3 wars: one test.war (no > authentication tests), one test-basic.war (basic authentication tests) > and one test-form.war (form-based authentication tests). > > Note: Some persons have told me it was difficult to understand the > differences between the unit/ and sample/ directories in the > servlet-sample project. That would solve the problem. > > What do you think? > > Thanks > -Vincent > > > -----Original Message----- > > From: Robertson, Jason [mailto:Jason.Robertson@;acs-inc.com] > > Sent: 26 October 2002 15:40 > > To: 'Cactus Users List' > > Subject: RE: FormAuthentication > > > > Time for Vincent to chime in! > > > > Vincent, Pranab's comments below show that there's a problem in the > > reconfiguring of the Redirector in that you can configure it in two > > places: > > in WebRequest and in cactus.properties, but only the latter is > persistent > > between callRunTest and callGetResult. In callGetResult, a new > WebRequest > > is > > created and gets initialized with the cactus.properties value. > > > > Should calling setRedirectorName in the WebRequest propagate that > setting > > to > > the configuration? Or should that method be removed from WebRequest > and > > added to the WebConfiguration interface and then you'd say: > > > > aWebRequestObject.getConfiguration().setRedirectorName(...); > > > > Or should the same WebRequest object be shared between callRunTest and > > callGetResult? I would think this would make the most sense, I don't > know > > if > > I like accessing static properties through a transient object. > > > > If we take the reuse-the-WebRequest approach, the signature for > > callGetResult would change to remove the AbstractAuthen. Thetication > and add > > the > > WebRequest (the authentication object would already be configured in > the > > WebRequest) and you'd have to add something like a "setParameter" that > > would > > overwrite any existing parameter and allow you to reconfigure the > service > > name parameter. > > > > None of these changes are that difficult, but does any one look better > or > > worse in the "big picture"? > > > > Jason > > [snip] > > > > -- > To unsubscribe, e-mail: > <mailto:cactus-user-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: > <mailto:cactus-user-help@;jakarta.apache.org> > > -- > To unsubscribe, e-mail: > <mailto:cactus-user-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: > <mailto:cactus-user-help@;jakarta.apache.org> > > -- > To unsubscribe, e-mail: > <mailto:cactus-user-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: > <mailto:cactus-user-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:cactus-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:cactus-user-help@;jakarta.apache.org>
