AW: FormAuthentication
Hi Jason, I would also be interested in this FormAuthentication Example. I didn't follow the discussion closely the last couple weeks is it also possible to test form based login with https? Regards, Michael -Ursprüngliche Nachricht- Von: Robertson, Jason [mailto:Jason.Robertson;acs-inc.com] Gesendet am: Montag, 28. Oktober 2002 21:35 An: 'Cactus Users List' Betreff: RE: FormAuthentication I think this is a good solution. Separate WAR files is the only way I know of to use different authentication techniques. Plus, the side effect of making a clearer separation between the example and the unit tests I agree is a good thing. Do you want my test app? It's just a very simple web app with pages to do the form authentication as well, so you have a 2nd avenue to test configuration if you're having troubles with cactus. Its the one I used to test Tomcat and WLS. I'm sure it can be easily adapted to any other J2EE server. Let me know and I'll try to bundle it up. Jason -Original Message- From: Vincent Massol [mailto:vmassol;octo.com] Sent: Saturday, October 26, 2002 2:12 PM To: 'Cactus Users List' Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: FormAuthentication 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 -- To unsubscribe, e-mail: mailto:cactus-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:cactus-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:cactus-user-unsubscribe;jakarta.apache.org For additional commands, e-mail:
followRedirects is false
Hi, I have a secure EJB application running on JBoss3.0.3/Jetty and I'm trying to integrate some Cactus Unit Tests. I have read the docs and created a sample EJB Test, deployed it in a war and added security to the web.xml so that I can authenticate and run the tests from a browser. ..but after I log in I get a page back indicating an error as follows: BROWSER ERROR = Failed to get the test results. This is probably due to an error that happened on the server side when trying to execute the tests. Here is what was returned by the server : [] This tells me nothing so I look in the JBoss log and I see the following: JBOSS ERROR === INFO [wire] Content-type: application/x-www-form-urlencoded INFO [wire] Host: localhost INFO [wire] User-Agent: Jakarta HTTP Client/2.0.0a1 INFO [wire] \r\n INFO [wire] HTTP/1.1 302 Moved Temporarily [\r\n] INFO [wire] Date: Tue, 29 Oct 2002 08:16:09 GMT [\r\n] INFO [wire] Server: Jetty/4.1.0 (SunOS 5.8 sparc) [\r\n] INFO [wire] Servlet-Engine: Jetty/4.1.0 (Servlet 2.3; JSP 1.2; java 1.4.0_01) [\r\n] INFO [wire] Set-Cookie: JSESSIONID=bsp7oiipqikl7;Path=/myapp-ejbtest [\r\n] INFO [wire] Set-Cookie2: JSESSIONID=bsp7oiipqikl7;Version=1;Path=/myapp-ejbtest;Discard [\r\n] INFO [wire] Location: http://localhost/myapp-ejbtest/login.html;JSESSIONID=bsp7oiipqikl7; [\r\n] INFO [wire] Transfer-Encoding: chunked [\r\n] INFO [HttpMethod] HttpMethodBase.execute(): Received 302 response, but followRedirects is false. Returning 302. The WebServer doesn't indicate any error as such: WEB SERVER ERROR POST /myapp-ejbtest/j_security_check HTTP/1.1 302 0 http://localhost:19201/myapp-ejbtest/login.html;JSESSIONID=bsp7oiipqikl7; Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0) GET /myapp-ejbtest/ServletRedirector?Cactus_TestMethod=testConvertCactus_TestClass=my.package.MyBeanTestCactus_AutomaticSession=trueCactus_Service=CALL_TEST HTTP/1.1 302 0 - Jakarta HTTP Client/2.0.0a1 Can some kind person point me in the right direction here? Many thanks in advance Charlene __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: mailto:cactus-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:cactus-user-help;jakarta.apache.org
Cactus/Struts nightly build issue
Below is part of an e-mail thread from the struts-dev list. Here's the situation - I upgraded to a nightly build of Struts, and that is the only change. On Struts 1.1b2 all our Cactus tests succeeded, but with the nightly build (20021028) they all failed. Logically you'd think the problem was with Struts, but our application still worked in the browser just fine. Digging a bit deeper, a change was made in part of the request handling of Struts to call: request.getServletPath(); With Struts debugging enabled, I see this is returning /something.do when running through a web browser, but is returning when running through Cactus. To further confuse issues, I'm using StrutsTestCase on top of Cactus. I'm assuming something is misconfigured in the Cactus side of things either with our code or in the StrutsTestCase framework (which may need some adjustments for the Struts code changes). Any clues? Thanks, Erik Original Message Subject: Re: Nightly build issue Date: Mon, 28 Oct 2002 16:17:11 -0600 From: Erik Hatcher [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Eddie Bush wrote: Can you verify your assumption with the logging output? It should say what the value of matchPath is. This would be a debug-level logging statment indicated by a line stating: Selecting module for path matchPath After getting the logging opened up, my results are matchPath is (blank, not null) when running through Cactus/StrutsTestCase, but not when running through a browser. Odd. I guess this is not a Struts issue per se. I'll take this up on the Cactus list when I get a chance. Erik -- To unsubscribe, e-mail: mailto:cactus-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:cactus-user-help;jakarta.apache.org
Struts testing problem
Below is part of an e-mail thread from the struts-dev list. Here's the situation - I upgraded to a nightly build of Struts, and that is the only change. On Struts 1.1b2 all our Cactus tests succeeded, but with the nightly build (20021028) they all failed. Logically you'd think the problem was with Struts, but our application still worked in the browser just fine. Digging a bit deeper, a change was made in part of the request handling of Struts to call: request.getServletPath(); With Struts debugging enabled, I see this is returning /something.do when running through a web browser, but is returning when running through Cactus. To further confuse issues, I'm using StrutsTestCase on top of Cactus. I'm assuming something is misconfigured in the Cactus side of things either with our code or in the StrutsTestCase framework (which may need some adjustments for the Struts code changes). Any clues? Thanks, Erik Original Message Subject: Re: Nightly build issue Date: Mon, 28 Oct 2002 16:17:11 -0600 From: Erik Hatcher [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Eddie Bush wrote: Can you verify your assumption with the logging output? It should say what the value of matchPath is. This would be a debug-level logging statment indicated by a line stating: Selecting module for path matchPath After getting the logging opened up, my results are matchPath is (blank, not null) when running through Cactus/StrutsTestCase, but not when running through a browser. Odd. I guess this is not a Struts issue per se. I'll take this up on the Cactus list when I get a chance. Erik -- To unsubscribe, e-mail: mailto:cactus-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:cactus-user-help;jakarta.apache.org
Apparent Race Condition, revisited
We've experienced a condition that seems to mirror the race condition that Frank Baxter reported last week. What we are seeing is the setUp() method of test B starting before the tearDown() method of test A has completed. Attempts to narrow down the cause have been unsuccessful, apparently because, as Frank pointed out, logging and other debug methods slow things down to the point where the race condition doesn't occur. One thing that sets this particular suite of tests apart from others is that the tearDown() method executes for a relatively long time. There is quite a bit of database cleanup going on and it can take 30 seconds or more. Vincent posted that internally Cactus reads the whole servlet response *before* calling again the server side to get the test Result. Is it possible that tearDown() is taking so long that the servlet response is complete, but tearDown() is still running? For clarity, we're using Cactus 1.4.1 and running the tests through jUnit's Swing test runner. We can work around the problem by moving the database work into beginXXX() and endXXX methods, but would rather not have to since a)this isn't the way we write non-cactus tests; and b)there are concerns (unproven and probably unfounded) about performance. Thanks, Brian -- To unsubscribe, e-mail: mailto:cactus-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:cactus-user-help;jakarta.apache.org
RE: FormAuthentication
Here's my SimpleFormLogin project. This is project source, so look into the build.xml file and adjust the !-- Jar files -- section to fit your setup. As far as I know, form authentication over https shouldn't be a problem as it's really not much different than any other form submission. As long as the server is setup right and the context URL has https I'd assume it would all work, but I've never tested it. Jason -Original Message- From: Koegel, Michael [mailto:Michael.Koegel;partner.commerzbank.com] Sent: Tuesday, October 29, 2002 3:23 AM To: Cactus Users List Subject: AW: FormAuthentication Hi Jason, I would also be interested in this FormAuthentication Example. I didn't follow the discussion closely the last couple weeks is it also possible to test form based login with https? Regards, Michael -Ursprüngliche Nachricht- Von: Robertson, Jason [mailto:Jason.Robertson;acs-inc.com] Gesendet am: Montag, 28. Oktober 2002 21:35 An: 'Cactus Users List' Betreff: RE: FormAuthentication I think this is a good solution. Separate WAR files is the only way I know of to use different authentication techniques. Plus, the side effect of making a clearer separation between the example and the unit tests I agree is a good thing. Do you want my test app? It's just a very simple web app with pages to do the form authentication as well, so you have a 2nd avenue to test configuration if you're having troubles with cactus. Its the one I used to test Tomcat and WLS. I'm sure it can be easily adapted to any other J2EE server. Let me know and I'll try to bundle it up. Jason -Original Message- From: Vincent Massol [mailto:vmassol;octo.com] Sent: Saturday, October 26, 2002 2:12 PM To: 'Cactus Users List' Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: FormAuthentication 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
cactus 1.4 with struts1.0
Hi I would like to know , this combination works or not.,.When i tried to do it i learned that there are some changes in the package names in the latest version of cactus and will work only wiht struts 1.1B. Manoj -- To unsubscribe, e-mail: mailto:cactus-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:cactus-user-help;jakarta.apache.org
