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
>
>

Reply via email to