RE: FormAuthentication

2002-10-26 Thread Robertson, Jason
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 AbstractAuthentication 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

-Original Message-
From: Dhar, Pranab [mailto:Pranab.Dhar;DFA.STATE.NY.US]
Sent: Friday, October 25, 2002 11:17 PM
To: 'Cactus Users List'
Subject: RE: FormAuthentication


Jason,
   I found the Redirector change happening at function
(AbstractHttpClient.java)
private WebTestResult callGetResult(
AbstractAuthentication theAuthentication) throws Throwable
{
WebRequest resultsRequest = new WebRequest(this.configuration); ---
here
  // Add authentication details
if (theAuthentication != null)
{
resultsRequest.setAuthentication(theAuthentication);
}

// Open the second connection to get the test results
 ConnectionHelper helper = ConnectionHelperFactory.getConnectionHelper(
getRedirectorURL(resultsRequest), this.configuration);

The ServletConfiguration does not contain the redirector set in WebRequest
object
instead it loads it default redirector from the cactus.properties.
   this.configuration is coming from new Configuration being initialized in 
ServletTestCase class 
 * see AbstractTestCase#createConfiguration()
 */
protected Configuration createConfiguration()
{
return new ServletConfiguration();
}
When the user sets the redirector in Webrequest that never gets updated in
the configuration.
So when getRedirectorURL() gets called in AbstractHttpClient.java which is
actually implemented 
in ServletHttpClient.java as 
protected String getRedirectorURL(WebRequest theRequest)
{
String url;

// Check if user has overriden the servlet redirector

if (theRequest.getRedirectorName() != null)
{
url = this.configuration.getContextURL() + /
+ theRequest.getRedirectorName();
}
else
{
url = this.configuration.getRedirectorURL();
}

return url;
}

The theRequest parameter being a newly intialized WebRequest object does not
have the 
redirector set from the old request object used for Form Authentication.
Hence callResult function never goes to the Secured Servlet Redirector used
earlier to run the test.
I am not too sure if the unsecured redirector will be able to return the
results.
Maybe cactus guru's will know the answer to this design.

Pranab




-Original Message-
From: Robertson, Jason [mailto:Jason.Robertson;acs-inc.com]
Sent: Friday, October 25, 2002 6:20 PM
To: 'Cactus Users List'
Subject: RE: FormAuthentication


Yes, you're correct with the need to get the context URL as well.

As for the rest of it, I'm not sure. I'll try looking at the log again, but
there's a lot of information there!

Jason

-Original Message-
From: Dhar, Pranab [mailto:Pranab.Dhar;DFA.STATE.NY.US]
Sent: Friday, October 25, 2002 3:43 PM
To: 'Cactus Users List'
Subject: RE: FormAuthentication


Jason,
 Sorry for the typo Error in my last post.it should be
 getConfiguration().getContextURL()+/+theRequest.getRedirectorName();

I just compiled the code and tested it. I am getting past the authentication
now
but getting stuck somewhere after that. Somewhere down the line the
ServletRedirectorSecure
 is getting switched back to ServletRedirector even though I am setting the
URL to a
secured resource.I am getting a Error  404 instead of the regulars output
from the servlet.

Pranab

I added the following in the test code
public void beginBasicAuthentication(WebRequest theRequest) {
theRequest.setURL(localhost:8080, /, /secure/idsconf,
null, null); --
theRequest.addCookie( test, test );

RE: FormAuthentication

2002-10-26 Thread Vincent Massol
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