Hi Vincent,
If you were late in replying to my question, then I am
really, really late in replying to your response. My
apology for that as I was busy during the past 2 weeks
to put out fire at work.
My colleagues at work do not like cactus. The main
complain was that having a cactus redirector servlet
redirect to struts' ActionServlet which in turn
redirect to a business action object is considered to
be "strange" w.r.t. in-container testing. When I found
out cactus does not do authentication to appserver, my
proposal of adopting cactus was shot down.
We wrote our own model 2 framework, along with our own
test harness, last year before struts was released.
Now we move to struts and that's why we need a new
testing framework. Well, I ended up writing my own
out-of-container unit testing framework to work with
struts during the past 2 weeks. We always put a
wrapper around the request, response & servlet context
to support some of the methods because we do not want
developers to have full access to these 3 servlet
interfaces. This makes writing a test framework
easier.
If your offer is still good, I would like to
contribute to the cactus authentication effort. I
just downloaded cactus 1.2 and httpunit 1.2.6 to learn
about the new release. I couldn't find a zip file to
download for httpclient though. If you know, please
point me to the right URL. Also, is there an achive
for cactus developer emails that I can browse to learn
more about cactus?
Thank you very much. My work email address is:
[EMAIL PROTECTED]
Peter S. Wong
From: Vincent Massol
Subject: Re: authentication to webserver
Date: Thu, 13 Sep 2001 00:33:23 -0700
Hi Peter,
Sorry for the delay. Actually I started thinking
about this issue as soon as
I received your email. You may have noticed that
supporting security is one
the task that is listed in the todo list and is
supposed to be implemented
in Version 1.3.
There are 2 solutions to implement it :
Solution 1 :
------------
The idea would be to provide methods in
HttpServletRequestWrapper to set the
expected values
from these methods. For example your test would
be :
public void testXXX()
{
Principal myPrincipal = new Principal() {
public String getName()
{
return "whatever you want for the test";
}
[...]
};
request.setUserPrincipal(myPrincipal);
MyStrutsAction action = new MyStrutsAction();
[...]
// run the test
action.doSomething(..., request, ....)
[...]
}
so that when the doSomething() method calls
getUserPrincipal on the request
object it returns the Principal you have
defined. This is very good because
you can easily write unit tests with invalid
principals or undefined ones,
...
The sample would apply to getRemoteUser() (we
would have a
setRemoteUser(String)) and isUserInRole(String)
(we would have a
setIsUserInRole(boolean)).
However these tests will not exercise the
security deployment part but will
test your
code
Solution 2
----------
Solution 1 is a bit of a "hack" and is less with
the spirit of Cactus, which
is focusing on providing unit tests that run as
much as possible the real
things. The correct solution would probably be
to implement the support for
security on the client side of Cactus. Since
version 1.2, Cactus began
relying on commons-httpclient as the HTTP client
. At the current time, we
only use the Cookie handling functions of
httpclient. However, the idea is
to move completely to httpclient for the HTTP
connection itself. And as
httpclient is supporting authentication/SSL/...
Cactus will also benefit
from these features.
The idea will be to provide additional API in
the WebRequest object that you
use in beginXXX(). For example we will probably
add something like
setCredential() or setPrincipal() method to set
the user name and pwd that
should be used in the authentication, ...
If you really need this feature quickly, I can
suggest several options :
1/ you help us out writing the implementation
for Cactus 1.3
2/ you write very quickly solution 1 for
yourself. You simply need to extend
HttpServletRequestWrapper and provide the
additional methods. Then in your
test case you'll write :
public void testXXX()
{
MySpecialHttpServletRequestWrapper request2 =
new
MySpecialHttpServletRequestWrapper(request);
[...]
doSomething(request2)
[...]
}
Hope it helps
-Vincent
----- Original Message -----
From: "Peter Wong" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 12, 2001 3:01 PM
Subject: authentication to webserver
>
> Hi,
>
> I was thinking about it driving in to work
this morning. Will it work
> if I wrap the request implicit objects while
subclassing the
> ServletTestCase?
>
> Thanks.
>
> Peter
>
>
__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
