Thanks for the quick reply Vincent. I guess the quickest way for me is to use the mock implementation. Atleast in my own case I would prefer to go with the mock object implementation - I have been using the struts framework to build my application and have a proliferation of action classes & I check for the user in the perform method of each of them. So this login request would have to be sent before each test method. Only in test cases where I want to test the login process itself would I like to send the request to the container. I guess essentially what I am saying is it would be good if cactus supported both in container and mock object testing and leave it upto the programmer to figure out which is appropriate in a particular case. Also I could think of using solution 1 in another way - Add the ability to have multiple instances of the redirector servlet each configured in a different way and in the setup /beginxxx methods chose which of the redirector servlets you would like to have handle this test case. This way I can use the servlet without security enabled for some methods and security enabled for others. I guess generation step will add more flexibilty though .... Thanks Pratima -----Original Message----- From: Vincent Massol [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 05, 2001 2:21 AM To: [EMAIL PROTECTED] Subject: [cactus] Supporting security in Cactus and Cacus Design (WAS Re: Cactus with container security) Hi Pratima, That's an excellent question your are asking ... At the current time Cactus does not support unit testing method that make use of the security API. However, there is a task defined in the todo list for version 1.2 (next version) for doing so. The task states "Support unit testing of Servlet code that uses Security APIs, such as isUserInRole(), ... ". You are the first actually the first person to ask for this ! :) Thinking about it quickly right now, here are some ideas of how we could support it in Cactus : Solution 1: 1/ In the beginXXX() method, add a new method like setUserCredential(String name, String pwd) 2/ Make the client side code of Cactus understand HTTP requests for authentication so that it could answer by providing the user name and pwd specified in 1/ 3/ In web.xml, put security configuration on the Servlet Redirector The problem with this method is that the Servlet Redirector is generic and if we put security to it then it will be activated for all test cases ! Also it won't be possible to change values, like putting an invalid password to verify an error page is returned ... Solution 2: 1/ Provide a mock implementation for all security API. The behaviours of the security APIs will be set by setXXX() methods on implicit objects that have security related APIs The problem with solution 2 is that we're not doing in-container testing, but rather mock object ... The current goal of Cactus is to try as much as possible to do the real thing (i.e. behaviour from the container). However in several other occasions, we have been doing it mock style when it was not possible to do it otherwise. The other goal of Cactus was to see up to what level we could do it in-container. I think we're beginning to see the limits ... :) Solution 3: 1/ Forget the generic redirector and instead have one redirector per test case, meaning that we can very finely tune any paramter for a given test case. The redirector actually acts as a wrapper around the servlet to be tested. I had thought about doing it this way when I started Cactus but the issue was to write a redirector for each test case ! The idea I had was to use the Proxy Reflection API in JDK 1.3 in order to create it dynamically at runtime ... However, this means dropping support for JDK 1.x and 2.x ... which I did not want to do as I thought it was too early in the adoption of JDK 1.3 ! I think it is still true at the current time. Maybe in a year's time ... The other way of doing it might be by generating the proxy classes, meaning that within Ant we could have an additional step, which is a generation step. I actually like this idea as I am beginning to see how we could reconciliate both in-container testing and mock object testing using a generation step like this ... :-) I'll write a paper on the subject very soon ... I think solution 3 would the only way to go if we wish to continue in-container testing ! Thanks Partima for triggering all this chain of thoughts ... :) Any thoughts ? Thanks -Vincent ----- Original Message ----- From: "Gogineni, Pratima" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, July 05, 2001 6:37 AM Subject: Cactus with container security > Hi, > > I am using form-based authentication provided by my container. THe problem > is that in my servlets I have: > > request.getPrincipalUser() and I see no way to set a principal user into the > implicit request object. My question is - do I have to remove the > logon/security for testing with Cactus? I looked at the API and couldnt find > anything there that seemed relevant to my problem ... > > The only solution I can think of is somehow use httpunit to first login > before executing each unit test? > > thanks > pratima >
