----- Original Message ----- From: "Peter Wong" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, September 28, 2001 3:46 AM Subject: authentication to webserver
> 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. Well, this is not really the Cactus architecture .... this is rather how they use it. The archietecture is : have the cactus redirector servlet call your test method. Your test method would initialize all neded environment parameters before calling the method to test and will then perform asserts. Nothing bad that I can see here ... ! :) WRT Struts, my preferred way of unit testing a Struts Action would be (although I agree I don't have much experience yet on that subject) : have the cactus redirector servlet call your test case. Your test case will need to initialize all environment variables and parameters that need to be passed to the method to test [that's unit testing !]. In the Struts Action case you need to pass an ActionServlet object. You simply create it : MyActionToTest action = new MyActionToTest(); action.setServlet((new ActionServlet()).init(config)); > When I found > out cactus does not do authentication to appserver, my > proposal of adopting cactus was shot down. In good architectures you would normally try to use very little programmatic security code and rather rely on declarative security. The goal of Cactus is to unit test your code and to also provide integration testing as much as possible. Even if Cacus does not support authentication testing at the current time, this shouldn't be a reason for not unit testing your code and if you use declarative security there is no problem with unit testing your code with Cactus. [There are few cases where it won't work but theses cases represent probably less than 1% of the code. For example if you wish to say I only allow gold members to perform a bank transfer if the amount to be transfered is greater than �1M.] > > 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 I understand correctly it means that you have chosen a Mock Object approach ? And you have implemented mocks for all the Servlet API (at least the ones you use) and for Struts objects ? This is a fine approach. It won't let you do integration testing but is very fine for unit testing. > > If your offer is still good, I would like to > contribute to the cactus authentication effort. That would be great ! Please do so ... :-) Let us know what approach you'd like to take. > 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. It is normal : 1/ httpclient is not officially released it and thus yuo have to build from the sources 2/ httpclient.jar is bundled in the download of Cactus, in lib/ > 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? yes, check http://jakarta.apache.org/cactus/maillinglist.html > > Thank you very much. My work email address is: > [EMAIL PROTECTED] > > Peter S. Wong > Thanks -Vincent > > > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
