Re: [VOTE] Cactus 1.7.2 release
In article <[EMAIL PROTECTED]>, Sat, 14 Jan 2006 23:57:37 -0200, Felipe Leme <[EMAIL PROTECTED]> wrote: maven> Due to the 'legal bug' of Cactus 1.7 and Cactus 1.7.1 had bundled a LGPL maven> jar, I propose we release Cactus 1.7.2 - other than the aforementioned maven> issue, technically speaking the only change was a new property for the maven> Maven plugin (see http://issues.apache.org/jira/browse/CACTUS-231). +1 Regards, Kazuhito SUGURI - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Kenney Westerhof as committer
+1 In article <[EMAIL PROTECTED]>, Wed, 20 Jul 2005 14:20:41 +0200, "Vincent Massol" <[EMAIL PROTECTED]> wrote: vmassol> I'd like to propose Kenney as a Cactus committer. Some of you may not know vmassol> Kenney but he's actually been around for some time here at Apache, vmassol> participating to Maven2 very actively and submitting excellent patches. Kazuhito SUGURI - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Nicolas Chalumeau as Cactus committer
+1 In article <[EMAIL PROTECTED]>, Wed, 20 Jul 2005 12:02:35 +0200, "Vincent Massol" <[EMAIL PROTECTED]> wrote: vmassol> I'd like to propose Nicolas Chalumeau as a new Cactus committer. Nicolas has vmassol> been actively participating for a very long time, answering the mailing list vmassol> and providing lots of patches. Kazuhito SUGURI - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Migrating to Subversion
Here is my +1. In article <[EMAIL PROTECTED]>, Sat, 7 May 2005 10:54:46 +0200, "Vincent Massol" <[EMAIL PROTECTED]> wrote: vmassol> Apache is slowly migrating all its projects to Subversion and they're asking vmassol> us if we want to do it for Cactus. I've personally used SVN on several vmassol> projects and it's great. The tools are slightly behind compared to CVS but vmassol> they are quite usable (TortoiseSVN for windows, subclipe for Eclipse, etc). vmassol> vmassol> Please cast your vote: Regards, Kazuhito SUGURI - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (CACTUS-173) Add test cases for the form-based authentication feature
[ http://issues.apache.org/jira/browse/CACTUS-173?page=history ] Kazuhito SUGURI reassigned CACTUS-173: -- Assign To: Kazuhito SUGURI > Add test cases for the form-based authentication feature > > > Key: CACTUS-173 > URL: http://issues.apache.org/jira/browse/CACTUS-173 > Project: Cactus > Type: Task > Components: Framework > Versions: 1.7 > Reporter: Vincent Massol > Assignee: Kazuhito SUGURI > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Magnus Grimsell as a committer
+1 In article <[EMAIL PROTECTED]>, Wed, 16 Feb 2005 11:10:14 +0100, "Vincent Massol" <[EMAIL PROTECTED]> wrote: vmassol> I'd like to propose Magnus as a committer on Cactus. Magnus has submitted vmassol> several patches (CACTUS-190: addition of cactifyear Ant task, CACTUS-189: vmassol> addition of run-as support in cactifywar Ant task). Those patches were of vmassol> perfect quality and he's done them without any help showing that he clearly vmassol> understands Cactus. Kazuhito SUGURI mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Cactus 1.7 release
+1 Regards, Kazuhito SUGURI - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Summary] Vote to elect Kazuhito as Cactus committer
Hi, In article <[EMAIL PROTECTED]>, Wed, 27 Oct 2004 11:46:56 +0200, "Vincent Massol" <[EMAIL PROTECTED]> wrote: vmassol> Hi Committers, vmassol> vmassol> We've received 4 +1 to grant committer status to Kazuhito Suguri: vmassol> vmassol> +1 Vincent Massol vmassol> +1 Felipe Leme vmassol> +1 Nicolas Lesiecki vmassol> +1 Christopher Lenz vmassol> vmassol> This means that Kazuhito is now a Cactus committer! :-) vmassol> vmassol> Welcome aboard! Thanks a lot. vmassol> Kazuhito, your first step (as described in vmassol> http://www.apache.org/dev/pmc.html#newcommitter) is to fill a CLA form and vmassol> fax it to the Apache Software Foundation (see vmassol> http://www.apache.org/licenses/#clas). Once the foundation receives I'll ask vmassol> them to grant you CVS write access. To avaid the problem in the future, I'm confirming necessary in-house procedure now. As soon as its confirmed, I'll do that and inform you, Vincent. Thanks, Kazuhito SUGURI mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with Tomcat and BasicAuthentication
Hi Gertjan, The name of the property is cactus.servletRedirectorName. See also: http://jakarta.apache.org/cactus/integration/manual/howto_config.html In article <[EMAIL PROTECTED]>, Tue, 30 Mar 2004 14:19:52 +0200, Gertjan van Oosten <[EMAIL PROTECTED]> wrote: gertjan> a. my BasicAuthentication tests run using the ServletRedirectorSecure gertjan> b. all other Cactus tests run using the normal ServletRedirector gertjan> c. for all tests (including the authentication tests), Cactus uses the gertjan>normal ServletRedirector to check whether Tomcat is up-and-running Is the statement of c true? >From your first message, I thought that Cactus uses the secured ServletRedirector for the check. In article <[EMAIL PROTECTED]>, Tue, 30 Mar 2004 11:27:03 +0200, gertjan> [cactus] [DEBUG] Checking if server is up ... gertjan> [cactus] [DEBUG] Failed to connect to http://localhost:8080/test-portal-realm-cactus/ServletRedirectorSecure?Cactus_Service=RUN_TEST (null) This is the one. Other possiblity. In article <[EMAIL PROTECTED]>, gertjan> [cactus] [DEBUG] Connected with a 401: gertjan> java.io.IOException gertjan>at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:593) gertjan>at org.apache.cactus.integration.ant.container.ContainerRunner.readFully(ContainerRunner.java:391) gertjan>at org.apache.cactus.integration.ant.container.ContainerRunner.testConnectivity(ContainerRunner.java:303) gertjan>at org.apache.cactus.integration.ant.container.ContainerRunner.startUpContainer(ContainerRunner.java:163) gertjan>at org.apache.cactus.integration.ant.CactusTask.executeInContainer(CactusTask.java:436) gertjan>at org.apache.cactus.integration.ant.CactusTask.execute(CactusTask.java:216) The CactusTask may overrides the property. As I can understand from Cactus sources, a url-pattern in the first servlet-mapping entry for the Servlet Redirector is used to check whether the server is running. This means that if the servlet-mapping for the secured ServletRedirector is prior to that for the normal ServletRedirector in your web.xml, secured ServletRedirector will be used. Regards, Kazuhito SUGURI mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with Tomcat and BasicAuthentication
Hi Gertjan, In article <[EMAIL PROTECTED]>, Tue, 30 Mar 2004 13:31:44 +0200, Gertjan van Oosten <[EMAIL PROTECTED]> wrote: gertjan> The problem is: the redirector that is set with setRedirectorName() is gertjan> also the one that's used by Cactus to check whether Tomcat is gertjan> up-and-running. I have no control over that. You may have your configuration file which sets the name of the Cactus Servlet Redirector name to ServletRedirectorSecure, cactus.properties for example. Regards, Kazuhito SUGURI mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with Tomcat and BasicAuthentication
Hi Gertjan, In article <[EMAIL PROTECTED]>, Tue, 30 Mar 2004 13:07:30 +0200, Gertjan van Oosten <[EMAIL PROTECTED]> wrote: gertjan> I'm not quite sure what you mean. If you want me to set ServletRedirector gertjan> in the beginXXX() method that would fail to accomplish anything, since gertjan> either I will have to protect ServletRedirector in the web.xml or the gertjan> test will fail because the resource is not protected... gertjan> Is my interpretation correct? I think, if it is not conflicting with requirements of your app, you can have two ServletRedirectors, one of which is protected and the other is not portected. ServletRedirector /ServletRedirector ServletRedirectorSecure /ServletRedirectorSecure SecurityRestriction Protect the Cactus redirector servlet. /ServletRedirectorSecure GET POST Then you can use /ServletRedirector to check whether the servlet is running, and /ServletRedirectorSecure for the test. Regards, Kazuhito SUGURI mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with Tomcat and BasicAuthentication
Hi Gertjan, In article <[EMAIL PROTECTED]>, Tue, 30 Mar 2004 12:18:26 +0200, Gertjan van Oosten <[EMAIL PROTECTED]> wrote: gertjan> As quoted from Kazuhito SUGURI <[EMAIL PROTECTED]>: gertjan> > I'm not familiar with Maven, however, you may not need to use gertjan> > ServletRedirectorSecure to check whether the server is running. gertjan> gertjan> Which is what I did (as could be seen in my previous message). Yes, I have seen that you are using ServetRedirectorSecure. So, I wanted to suggest, use ServletRedirector. Regards, Kazuhito SUGURI mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with Tomcat and BasicAuthentication
Hi Gertjan, In article <[EMAIL PROTECTED]>, Tue, 30 Mar 2004 11:27:03 +0200, Gertjan van Oosten <[EMAIL PROTECTED]> wrote: gertjan> As part of a larger project, I'm setting up Cactus tests for gertjan> BasicAuthentication, to be run from Maven. The environment is: I'm not familiar with Maven, however, you may not need to use ServletRedirectorSecure to check whether the server is running. As I understand, the secured ServletRedirector is needed when the authentication is really needed in TestCases, and can be set for each testXXX() by WebRequest#serRedirectorName(String) in beginXXX method. Regards, Kazuhito SUGURI mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Help] Servlet response's encoding of new lines, what is the correct behavior?
Hi Vincent,
In article <[EMAIL PROTECTED]>,
Wed, 24 Mar 2004 16:08:16 +0100,
"Vincent Massol" <[EMAIL PROTECTED]> wrote:
vmassol> The container where the test succeeds are those returning Windows eol
vmassol> characters (\r\n) whereas those that fail return Unix eol (\n).
vmassol>
vmassol> Is there a way (through some encoding?) to control how the response
vmassol> stream should encode end of lines?
Some ideas:
- don't use println() but print() in both test and end methods.
pw.print("\n");
- compare each line in end method.
String result = theResponse.getText();
BufferedReader reader = new BufferedReader(new StringReader(result));
assertEquals("", reader.readLine());
I hope this helps,
Kazuhito SUGURI
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] Re: Cactus/test name is null
Hi,
In article <[EMAIL PROTECTED]>,
Fri, 05 Mar 2004 17:50:19 -0500,
"J. B. Rainsberger" <[EMAIL PROTECTED]> wrote:
jbrains> It points out a potential defect in Cactus, though. When the test name
jbrains> is null, JUnit usually pukes; but in this case, it looks like a test
jbrains> failure. Vince... maybe it's worth changing Cactus so that it blows up
jbrains> the same way that JUnit does when the test name is null.
[snip: my first proposal]
In article <[EMAIL PROTECTED]>,
Fri, 12 Mar 2004 09:43:28 +0100,
"Vincent Massol" <[EMAIL PROTECTED]> wrote:
vmassol> What would be excellent is if you could also provide some test cases
vmassol> proving that it works. You can either reuse an existing test case class
vmassol> if it makes sense or create a new one. That will enrich our test suite
vmassol> and not lower our test coverage! :-)
vmassol>
vmassol> I've had a brief look at the patch. It looks good. Maybe, as a second
vmassol> step, it would be good to factorize both your check and the ones that
vmassol> already exist into a single place. ATM, there are lots of checks in the
vmassol> ClientTestCaseCaller.callGeneric*Method(...)
vmassol>
vmassol> It would be excellent if all the checks could be gathered in one place.
Patchs, new java files and test cases are appending.
These may have too many changes for one time.
Key points are:
1. added test case name checks at AbstractCactusTestCase#runBare()
[test case: TestNoNameTestCase ]
2. collected some test case check logics into TestCaseImplementChecker
[test case: TestTestCaseImplementChecker]
3. refactored ClientTestCaseCaller#callGeneric*Method
to use TestCaseImplementChecker
[modified existing test case: AbstractTestAbstractTestCase,
some expected messages were changed]
4. introduced TestCaseImplementError as a subclass of AssertionFailedError
appending files
New java files to be located under framework/src/share/org/apache/cactus/util:
TestCaseImplementChecker.java
TestCaseImplementError.java
New test case to be located under framework/src/test/org/apache/cactus:
TestNoNameTestCase.java
New test case to be located under framework/src/test/org/apache/cactus/util:
TestTestCaseImplementChecker.java
patch.AbstractCactusTestCase.1.7:
a patch against AbstractTestCase.java Rev.1.7
patch.ClientTestCaseCaller.1.3:
a patch against ClientTestCaseCaller.java Rev.1.3
patch.AbstractTestAbstractTestCase.1.7:
a patch against test/share/org/apache/cactus/AbstractTestAbstractTestCase.java
Rev.1.7
patch.TestAll.1.19
a patch against test/share/org/apache/cactus/TestAll.java Rev.1.19
patch.util.TestAll.1.4
a patch against test/share/org/apache/cactus/util/TestAll.java Rev.1.4
Regards,
Kazuhito SUGURI
mailto:[EMAIL PROTECTED]
/*
*
*
* Copyright 2001-2003 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*
*
*/
package org.apache.cactus.util;
import java.lang.reflect.Method;
import java.lang.reflect.Modifier;
import junit.framework.Test;
import org.apache.cactus.Request;
/**
* Utilities to check TestCase implementation.
* @version $Id$
*/
public abstract class TestCaseImplementChecker
{
/**
* Default constructor that requires that
* [EMAIL PROTECTED] #setConfiguration(Configuration)} be called before the methods
* requiring a configuration object.
*
*/
private TestCaseImplementChecker()
{
}
/**
* Check if the Test to run is properly implemented or not.
* @param theTest the test to check
* @throws TestCaseImplementError if has no name
*/
public static void checkTestName(Test theTest)
throws TestCaseImplementError
{
if (theTest == null)
{
return;
}
if (JUnitVersionHelper.getTestCaseName(theTest) == null)
{
throw new TestCaseImplementError("No test name found. The test ["
+ theTest.getClass().getName()
+ "] is not properly implemented.");
}
}
/**
* @param theNum the number
* @return a numeric e
[PATCH] documentation/docs/xdoc/faq.xml broken link to JUnit FAQ
Hi, I found a link to JUnit FAQ is broken. Appending a patch against documentation/docs/xdoc/faq.xml Rev.1.21. Regards, Kazuhito SUGURI mailto:[EMAIL PROTECTED] --- documentation/docs/xdocs/faq.xml.orig 2003-11-23 23:03:50.0 +0900 +++ documentation/docs/xdocs/faq.xml2004-03-02 11:22:10.0 +0900 @@ -415,7 +415,7 @@ Check the - JUnit + JUnit FAQ. Indeed, JUnit uses a special class loader to load classes that is incompatible with the Commons-Logging framework. Thus you need to put the commons-logging package in the JUnit - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] expectedPreAuthResponse check logic
Hi,
In article <[EMAIL PROTECTED]>,
Mon, 01 Mar 2004 12:02:49 +0900 (JST),
Kazuhito SUGURI <[EMAIL PROTECTED]> wrote:
suguri> I would like to implement the logic, as Chris suggested,
suguri> for pre-auth response stauts check.
The patch against CVS HEAD (obtained from CVS View page) is appending.
I dropped the expectedPreAuthResponse attribute and its accessor.
Check logic of pre-auth and auth responses are now implemented
as corresponding protected methods, checkPreAuthResponse(HttpURLConnection)
and checkAuthResponse(HttpURLConnection), for whom need to customize the logic.
Max, is this work for you?
Regards,
----
Kazuhito SUGURI
mailto:[EMAIL PROTECTED]
---
framework/src/java/share/org/apache/cactus/client/authentication/FormAuthentication.java.orig
2004-02-29 17:56:42.0 +0900
+++
framework/src/java/share/org/apache/cactus/client/authentication/FormAuthentication.java
2004-03-01 14:14:20.0 +0900
@@ -45,7 +45,7 @@
*
* @since 1.5
*
- * @version $Id: $
+ * @version $Id$
*/
public class FormAuthentication extends AbstractAuthentication
{
@@ -56,13 +56,8 @@
LogFactory.getLog(FormAuthentication.class);
/**
- * The expected HTTP response code for the request to a restricted
- * resource without authenticated principal.
- */
-private int expectedPreAuthResponse = HttpURLConnection.HTTP_MOVED_TEMP;
-
-/**
- * The expected HTTP response code when the authentication is succeeded.
+ * The expected HTTP response status code when the authentication
+ * is succeeded.
*/
private int expectedAuthResponse = HttpURLConnection.HTTP_MOVED_TEMP;
@@ -212,63 +207,28 @@
}
}
-/**
- * Get the expected HTTP response code for a request to a restricted
- * resource without authenticated principal.
- * @return the expected HTTP response code value
- */
-private int getExpectedPreAuthResponse()
-{
-return this.expectedPreAuthResponse;
-}
-
-/**
- * Set the expected HTTP response code for a request to a restricted
- * resource without authenticated principal.
- * The default is HttpURLConnection.HTTP_MOVED_TEMP.
- * @param theExpectedCode the expected HTTP response code value
- */
-public void setExpectedPreAuthResponse(int theExpectedCode)
-{
-this.expectedPreAuthResponse = theExpectedCode;
-}
/**
- * Get the expected HTTP response code for an authentication request
+ * Get the expected HTTP response status code for an authentication request
* which should be successful.
- * @return the expected HTTP response code
+ * @return the expected HTTP response status code
*/
-private int getExpectedAuthResponse()
+protected int getExpectedAuthResponse()
{
return this.expectedAuthResponse;
}
/**
- * Set the expected HTTP response code for an authentication request
+ * Set the expected HTTP response status code for an authentication request
* which should be successful.
* The default is HttpURLConnection.HTTP_MOVED_TEMP.
- * @param theExpectedCode the expected HTTP response code value
+ * @param theExpectedCode the expected HTTP response status code value
*/
public void setExpectedAuthResponse(int theExpectedCode)
{
this.expectedAuthResponse = theExpectedCode;
}
-/**
- * Check if the actual response code is that of the expected.
- * @param theExpected the expected response code
- * @param theActual the actural response code
- * @exception Exception the actual response code is not that of the expected
- */
-private void checkResponseCodeEquals(int theExpected, int theActual)
-throws Exception
-{
-if (theActual != theExpected)
-{
-throw new Exception("Received a [" + theActual + "] response code"
-+ " and was expecting a [" + theExpected + "]");
-}
-}
/**
* Get a cookie required to be set by set-cookie header field.
@@ -307,6 +267,28 @@
return null;
}
+
+/**
+ * Check if the pre-auth step can be considered as succeeded or not.
+ * As default, the step considered as succeeded
+ * if the response status code of theConnection
+ * is less than 400.
+ *
+ * @param theConnection a HttpURLConnection value
+ * @exception Exception if the pre-auth step should be considered as failed
+ */
+protected void checkPreAuthResponse(HttpURLConnection theConnection)
+throws Exception
+{
+if (theConnection.getResponseCode() >= 400)
+{
+throw new Exception("Received a status code ["
++ theConnection.getResponseCode()
++ "] and was expecting less than 400");
+}
+}
+
+
/*
Re: expectedPreAuthResponse check logic
Hi Max, Thank you for the comment and suggestion. Your message gave me better understanding of the spec. I'll post the patch soon. Regards, Kazuhito SUGURI mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
expectedPreAuthResponse check logic [Re: FormAuthentication (bug #17933)]
Hi Max, In article <[EMAIL PROTECTED]>, Fri, 27 Feb 2004 11:33:33 +0200, Max Kutny <[EMAIL PROTECTED]> wrote: mkut> Kazuhito, could you make the default expectedPreAuthResponse to be mkut> HTTP_OK instad of HTTP_MOVED_TEMP? In article <[EMAIL PROTECTED]>, Fri, 27 Feb 2004 13:07:37 +0100, Christopher Lenz <[EMAIL PROTECTED]> wrote: cmlenz> Possibly stupid question: why don't we just check for any status code < cmlenz> 400? I would like to implement the logic, as Chris suggested, for pre-auth response stauts check. What do you think about expectedAuthResponse? I'm not sure how Resin works. Regards, Kazuhito SUGURI mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FormAuthentication (bug #17933)
Hi, In article <[EMAIL PROTECTED]>, Fri, 27 Feb 2004 13:07:37 +0100, Christopher Lenz <[EMAIL PROTECTED]> wrote: cmlenz> Possibly stupid question: why don't we just check for any status code < cmlenz> 400? I think this is enough for most of Cactus users. For your information, followings are what I thought about the FormAuthentication. 1. I want stop the authentication sequence and inform what's (maybe) wrong to tester when the sequence seems goes wrong. So, I determined to check response for each authentication step and throw Exception if the response is not something expected. 2. At the pre-auth step, the resource set by setRedirectorName(String) may be a) xxxRedirector and is secured: [This case is normal.] 302 (or server depending) stats code will be returned. b) xxxRedirector, but is not secured: [In this case, the server should be re-configured. or the test-case should be debugged] 500 status code will be returned. c) not xxxRedirector but is existing secured resource: [In this case, the test-case should be debugged.] 302 (or server depending) status code will be returned. At this point, the sequence goes wrong, however, I cannot imagine how to know that in the program logic. d) not xxxRedirector but an existing un-secured resource: [In this case, the test-case should be debugged.] 2xx status code will be returned. The existence of the set-cookie header field is server dependent. If the cookie is find, unexpected authentication sequence can be proceeded (but I wanted stop it if possible). To detect this case, I didn't use logic like if (theCode < 300), however, the program logic not work as I want for server which returns 2xx. e) not existing resource: [In this case, the test-case should be debugged, also.] 4xx status code will be returned. 3. At the auth step, the status code is also server dependent. Server may try to return resource requested in the pre-auth step whenever the authentication is succeeded. Hopefully, no such server is existing, however, if server try to do so, the response may have status code of 500 for cactus tests because no query string is passed to the xxxRedirector at that time. Moreover, if the security_check url set by FormAuthentication#setSecurityCheckURL(URL) is possibly wrong, how could I judge from the status codes? I'v never find the answer. 4. After all, I found that it's too difficult for me to determin expected response status codes. Then, I determined that the value should be set by one who knows it. 5. Even if the status code is that of expected, however, that is not means the authentication sequence is successfully proceedeing. For example, 302 status code at auth step may means "authentication faild (try again)". So, more complex logic is required to realize what I wanted to do at the first time. However, I thought, such logic gives no valuable means for Cactus. I think there are some other better ways to track the sequence than this status code based apploach. Regards, Kazuhito SUGURI E-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FormAuthentication (bug #17933)
Hi Max, In article <[EMAIL PROTECTED]>, Fri, 27 Feb 2004 12:00:55 +0200, Max Kutny <[EMAIL PROTECTED]> wrote: mkut> No, they are useful ;) At least my servlet container (Resin 2.1.8) mkut> returns login page as 200 response. Moreover, I believe the spec mkut> requires to do exactly the same. So we need to be accurate here in case mkut> the containers interpete the spec differently. As far as I know, the detailed sequence is not determined as a spec. The spec is only determing the security check url and parameter names to be passed to that url. I've never seen the spec that defines how the sequence should be proceeded. (I may be mislooking something.) So, I believe, response code is depending on the server side implementation. I'm not sure which one of known response codes is widely used in existing servlet containers. But the tomcat implementation, which returns 302, is exist as a reference. So I useed 302 as the default. Kazuhito SUGURI E-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FormAuthentication (bug #17933)
Thank you Vincent. In article <[EMAIL PROTECTED]>, Fri, 27 Feb 2004 10:24:00 +0100, "Vincent Massol" <[EMAIL PROTECTED]> wrote: vmassol> Note: For my own understanding, could you tell me briefly why it is vmassol> sometimes required to call setExpected(Pre)AuthResponse to set an vmassol> expected response different than 302? I thought it was standard? Yes, I think it is the defact standard. However, the implementation of the authentication sequence can be changed due to application level constraints. For example, some borwser implemented for STBs does not follow redirect response like 302. IF an application needs such browser (STB) and still requires the form authentication, the mechanism may be changed to something like: C->S: request to the restricted resource of the server S:store the request information in the session scope S->C: return a login-form page with the response code 200 C->S: send credentials S->C: return the resource requested at first, if the authentication succeeded As I understand, the form authentication mechanism can be customized to perform such kinds of sequence. This is why I added the accessors to the FormAuthentication. Regards, Kazuhito SUGURI E-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FormAuthentication (bug #17933)
Hi Vincent, In article <[EMAIL PROTECTED]>, Thu, 26 Feb 2004 14:41:52 +0100, "Vincent Massol" <[EMAIL PROTECTED]> wrote: vmassol> I was trying to apply your patch but it's quite difficult. Do you think vmassol> you could improve it in the following manner: Yes. I'll do so. Thanks your for the advice. Regards, Kazuhito SUGURI E-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FormAuthentication (bug #17933)
Hi Vincent,
First, I must apologize for my post at 26 Feb 2004 19:53:34 +0900.
I should read the participating page before I do.
In article <[EMAIL PROTECTED]>,
Thu, 26 Feb 2004 14:41:52 +0100,
"Vincent Massol" <[EMAIL PROTECTED]> wrote:
vmassol> I was trying to apply your patch but it's quite difficult. Do you think
vmassol> you could improve it in the following manner:
vmassol>
vmassol> 1/ send a cvs diff against CVS HEAD (unified diff)
vmassol> 2/ apply Cactus coding conventions as defined in
vmassol> http://jakarta.apache.org/cactus/participating/coding_conventions.html
[snip]
vmassol> 3/ provide a diff for
vmassol> jakarta-cactus/documentation/docs/xdocs/changes.xml to include your
vmassol> changes.
I tried to do so, however, I cannot connect to the CVS server at this moment.
My network administrator is closing the route.
So, I applied changes against the source distributed as
jakarta-cactus-src-1.6dev20040225.
I hope the code FormAuthentication.java is same...
Appendings are:
- the patch against the FormAuthentication.java
- the full source code of the new FormAuthentication.java
- action elements to be inserted in documentation/docs/xdocs/changes.xml.
vmassol> If 2/ is not right then the build fails as it's part of the automated
vmassol> checks. The best way is for you to run "ant dist" in
vmassol> jakarta-cactus/framework to see if your changes do not fail the build.
vmassol> Then what is really nice is to run the full release (ant release) to
vmassol> verify that tests still pass, etc.
I confirmed "ant dist" in framework successfully finishes
with checkstyle-3.3.
Best Regards,
Kazuhito SUGURI
mailto:[EMAIL PROTECTED]
---
framework/src/java/share/org/apache/cactus/client/authentication/FormAuthentication.java.orig
2004-02-14 13:06:14.0 +0900
+++
framework/src/java/share/org/apache/cactus/client/authentication/FormAuthentication.java
2004-02-27 12:18:03.0 +0900
@@ -23,6 +23,7 @@
import java.net.MalformedURLException;
import java.net.URL;
+import org.apache.cactus.Cookie;
import org.apache.cactus.WebRequest;
import org.apache.cactus.client.connector.http.ConnectionHelper;
import org.apache.cactus.client.connector.http.ConnectionHelperFactory;
@@ -42,6 +43,7 @@
* cookie for the next request. The second time it is called, it simply
* addes the session cookie for the next request.
*
+ * @author mailto:[EMAIL PROTECTED]">Kazuhito SUGURI
* @author mailto:[EMAIL PROTECTED]">Jason Robertson
* @author mailto:[EMAIL PROTECTED]">Vincent Massol
*
@@ -58,21 +60,32 @@
LogFactory.getLog(FormAuthentication.class);
/**
+ * The expected HTTP response code for the request to a restricted
+ * resource without authenticated principal.
+ */
+private int expectedPreAuthResponse = HttpURLConnection.HTTP_MOVED_TEMP;
+
+/**
+ * The expected HTTP response code when the authentication is succeeded.
+ */
+private int expectedAuthResponse = HttpURLConnection.HTTP_MOVED_TEMP;
+
+/**
* The URL to use when attempting to log in, if for whatever reason
* the default URL is incorrect.
*/
private URL securityCheckURL = null;
/**
- * We store the session cookie name because of case issues. We need
- * to be able to send exactly the same one as was sent back by the
- * server. */
-private String sessionIdCookieName = null;
+ * The cookie name of the session.
+ */
+private String sessionCookieName = "JSESSIONID";
/**
- * We store the session id cookie so that this instance can
- * be reused for another test. */
-private String sessionId = null;
+ * We store the session cookie.
+ */
+private Cookie jsessionCookie = null;
+
/**
* [EMAIL PROTECTED] WebRequest} object that will be used to connect to the
@@ -112,15 +125,15 @@
Configuration theConfiguration)
{
// Only authenticate the first time this instance is used.
-if (this.sessionId == null)
+if (this.jsessionCookie == null)
{
authenticate(theRequest, theConfiguration);
}
// Sets the session id cookie for the next request.
-if (this.sessionId != null)
+if (this.jsessionCookie != null)
{
-theRequest.addCookie(this.sessionIdCookieName, this.sessionId);
+theRequest.addCookie(this.jsessionCookie);
}
}
@@ -180,104 +193,223 @@
return securityCheckURL;
}
+
/**
- * Authenticate the principal by calling the security URL.
- *
- * @param theRequest the web request used to connect to the Redirector *
@param theConfiguration the Cactus configuration
- */
-public void authenticate(WebRequest theRequest,
-Configuration theConfiguration)
+ * Get
FormAuthentication (bug #17933) [Re: Form Authentication is not working in Weblogic Portal 7.0 SP4,need help]
Hi,
In article <[EMAIL PROTECTED]>,
Fri, 20 Feb 2004 11:56:29 +0900 (JST),
Kazuhito SUGURI <[EMAIL PROTECTED]> wrote:
suguri> I modified FormAuthentication while we (Ankur and I) were solving this.
suguri> # please refer archive of cactus-users ML for detail.
suguri>
suguri> I believe the new FormAuthentication will be a solution for a issue:
suguri> http://issues.apache.org/bugzilla/show_bug.cgi?id=17933
suguri>
suguri> The code is appending to this message.
suguri> The code is modified from the one of the source release of Cactus-1.5.
I didn't care about difference between 1.5 and 1.6dev,
so I modified little more.
The code modified from the one of cactus-1.6dev20040225 is appending.
Followings are what I did to the original cactus-1.6dev20040225:
1. Bug #17933 is fixed (I hope so)
(1) Get hostname from a HttpURLConnection instance of the first connection,
which should contains set-cookie header field in its response,
then pass the hostname to the first argument of Cookie(String, String, String)
constructor.
(2) Use WebRequest#addCookie(Cookie) instead of WebRequest#addCookie(String, String)
2. New accessors are provided
(1) setExpectedPreAuthResponse(int)/getExpectedPreAuthResponse()
Set/get the expected HTTP response code for a request
to a restricted resource without authenticated principal.
The default is HttpURLConnection.HTTP_MOVED_TEMP.
If the response code of the first connection is not what's expected,
authentication process will not be proceeded.
(2) setExpectedAuthResponse(int)/getExpectedAuthResponse()
Set/get the expected HTTP response code for an authntication request
which should be succeeded.
The default is HttpURLConnection.HTTP_MOVED_TEMP.
If the response code of the second connection is not what's expected,
the authentication is considerd as failed.
(3) setSessionCookieName(String)/getSessionCookieName()
Set/get the cookie name of the session. The default is "JSESSIONID".
Best Regards,
Kazuhito SUGURI
mailto:[EMAIL PROTECTED]
/*
*
*
* Copyright 2001-2003 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*
*
*/
package org.apache.cactus.client.authentication;
import java.net.HttpURLConnection;
import java.net.MalformedURLException;
import java.net.URL;
import org.apache.cactus.Cookie;
import org.apache.cactus.WebRequest;
import org.apache.cactus.client.connector.http.ConnectionHelper;
import org.apache.cactus.client.connector.http.ConnectionHelperFactory;
import org.apache.cactus.configuration.Configuration;
import org.apache.cactus.configuration.WebConfiguration;
import org.apache.cactus.internal.WebRequestImpl;
import org.apache.cactus.util.ChainedRuntimeException;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
/**
* Form-based authentication implementation. An instance of this class
* can be reused across several tests as it caches the session cookie.
* Thus the first time it is used to authenticate the user, it calls
* the security URL (which is by default the context URL prepended by
* "j_security_check"), caches the returned session cookie and adds the
* cookie for the next request. The second time it is called, it simply
* addes the session cookie for the next request.
*
* @author mailto:[EMAIL PROTECTED]">Jason Robertson
* @author mailto:[EMAIL PROTECTED]">Vincent Massol
* @author mailto:[EMAIL PROTECTED]">Kazuhito SUGURI
*
* @since 1.5
*
* @version $Id: $
*/
public class FormAuthentication extends AbstractAuthentication
{
/**
* The logger.
*/
private static final Log LOGGER =
LogFactory.getLog(FormAuthentication.class);
/**
* The expected HTTP response code for the request to a restricted
* resource without authenticated principal.
*/
private int expectedPreAuthResponse = HttpURLConnection.HTTP_MOVED_TEMP;
/**
* The expected HTTP response code when the authentication is succeeded.
*/
private int expectedAuthResponse = HttpURLConnection.HTTP_MOVED_TEMP;
/**
* The URL to use when attempting to log in, if for whateve
Re: Form Authentication is not working in Weblogic Portal 7.0 SP4,need help
Hi,
In article <[EMAIL PROTECTED]>,
Wed, 18 Feb 2004 16:59:19 +1100,
[EMAIL PROTECTED] wrote:
ankur.kumar> I'm writing a test case, which is using form authentication.
This problem has been solved.
I modified FormAuthentication while we (Ankur and I) were solving this.
# please refer archive of cactus-users ML for detail.
I believe the new FormAuthentication will be a solution for a issue:
http://issues.apache.org/bugzilla/show_bug.cgi?id=17933
The code is appending to this message.
The code is modified from the one of the source release of Cactus-1.5.
Best Regards,
Kazuhito SUGURI
mailto:[EMAIL PROTECTED]
/*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2001-2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* "This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/)."
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names "The Jakarta Project", "Cactus" and "Apache Software
*Foundation" must not be used to endorse or promote products
*derived from this software without prior written permission. For
*written permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called "Apache"
*nor may "Apache" appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* <http://www.apache.org/>.
*
*/
package org.apache.cactus.client.authentication;
import java.net.HttpURLConnection;
import java.net.MalformedURLException;
import java.net.URL;
import org.apache.cactus.Cookie;
import org.apache.cactus.WebRequest;
import org.apache.cactus.client.connector.http.ConnectionHelper;
import org.apache.cactus.client.connector.http.ConnectionHelperFactory;
import org.apache.cactus.configuration.Configuration;
import org.apache.cactus.configuration.WebConfiguration;
import org.apache.cactus.util.ChainedRuntimeException;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
/**
* Form-based authentication implementation. An instance of this class
* can be reused across several tests as it caches the session cookie.
* Thus the first time it is used to authenticate the user, it calls
* the security URL (which is by default the context URL prepended by
* "j_security_check"), caches the returned session cookie and adds the
* cookie for the next request. The second time it is called, it simply
* addes the session cookie for the next request.
*
* @author mailto:[EMAIL PROTECTED]">Jason Robertson
* @author mailto:[EMAIL PROTECTED]">Vincent Massol
*
* @since 1.5
*
* @version $Id: $
*/
public class FormAuthentication extends AbstractAuthentication
{
/**
* The logger.
*/
private static final Log LOGGER =
LogFactory.getLog(FormAuthentication.class);
/**
* The expected HTTP response code for the request to a restricted
* resource without authenticated principal.
*/
private int e
