Hi Jason, > -----Original Message----- > From: Robertson, Jason [mailto:Jason.Robertson@;acs-inc.com] > Sent: 28 October 2002 20:35 > To: 'Cactus Users List' > Subject: 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.
I'd love if you could contribute to this servlet-unit subproject! However, I don't have much time ATM and it would be nice if it were in a similar format as the existing sample-servlet project... Anyway, anything you can submit will be of help! Thanks for your continuing help! -Vincent > > 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- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:cactus-user- > [EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:cactus-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:cactus-user-help@;jakarta.apache.org>
