Re: FormAuthentication problem
Hi, Sorry for my late response. In article <[EMAIL PROTECTED]>, Wed, 30 Apr 2008 09:24:42 -0700, "Eric Barendt" <[EMAIL PROTECTED]> wrote: eric> We are using JBoss 4.2.1 with whatever version of Tomcat it comes with. I eric> just applied your patch to the 1.8.0 code, and it works great! Thank you for the feedback. eric> Is this a bug in Cactus? I couldn't find anything in the project's Jira eric> page, but it'd be great to get this integrated. I think, it is a fault in Cactus: "not implemented yet". AFAIK, the client-server protocol for the form-based authentication have not been specified in detail, so, many possible implementations exist. It seems that Tomcat changed the implementation in a way Cactus mishandles the protocol with Tomcat. I think the new protocol of Tomcat is a possible one, and issue is in Cactus side. Kazuhito SUGURI - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FormAuthentication problem
Hi guys, I have added Kazuhito's changes in the svn. Sorry I have missed them - I have been really swamped lately. Eric, maybe you can tell more on how you use Cactus on the "Who uses Cactus" wiki. :-) Cheers, Petar. 2008/4/30 Eric Barendt <[EMAIL PROTECTED]>: > We are using JBoss 4.2.1 with whatever version of Tomcat it comes with. I > just applied your patch to the 1.8.0 code, and it works great! > > Is this a bug in Cactus? I couldn't find anything in the project's Jira > page, but it'd be great to get this integrated. > > Thanks! > Eric > > On Tue, Apr 29, 2008 at 11:30 PM, Kazuhito SUGURI < > [EMAIL PROTECTED]> wrote: > > > Hi Eric, > > > > In article <[EMAIL PROTECTED] > >, > > Tue, 29 Apr 2008 15:28:56 -0700, > > "Eric Barendt" <[EMAIL PROTECTED]> wrote: > > eric> I'm working on switching our application from Basic to Form > > authentication. > > [snip] > > eric> With FormAuthentication, I get "Missing service name parameter > > eric> [Cactus_Service] in HTTP request." and "Error getting test result. > > This > > eric> could happen for example if you're using a load-balancer." This > is > > what I > > eric> see in my access log: > > eric> > > eric> 127.0.0.1 - - [29/Apr/2008:16:50:18 -0500] "GET > > eric> /application/ServletRedirectorSecure HTTP/1.1" 200 2357 > > eric> 127.0.0.1 - - [29/Apr/2008:16:50:18 -0500] "POST > > eric> /application/j_security_check HTTP/1.1" 302 - > > eric> 127.0.0.1 - user [29/Apr/2008:16:50:18 -0500] "GET > > eric> /application/ServletRedirectorSecure HTTP/1.1" 500 2527 > > eric> 127.0.0.1 - user [29/Apr/2008:16:50:18 -0500] "GET > > eric> /application/ServletRedirectorSecure?Cactus_Service=GET_RESULTS > > HTTP/1.1" > > eric> 500 2556 > > > > What is your servlet container? > > > > If you are using Tomcat later than 5.5.20, > > my post to tomcat-users ML might helps you: > >http://marc.info/?l=tomcat-user&m=119098089904045&w=2 > > > > If it works for you, please let me know. > > > > Kazuhito SUGURI > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Eric Barendt > Danube Technologies, Inc. > -- Regards, Petar! Karlovo, Bulgaria. EOOXML Objections http://www.grokdoc.net/index.php/EOOXML_objections Public PGP Key at: https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
Re: FormAuthentication problem
We are using JBoss 4.2.1 with whatever version of Tomcat it comes with. I just applied your patch to the 1.8.0 code, and it works great! Is this a bug in Cactus? I couldn't find anything in the project's Jira page, but it'd be great to get this integrated. Thanks! Eric On Tue, Apr 29, 2008 at 11:30 PM, Kazuhito SUGURI < [EMAIL PROTECTED]> wrote: > Hi Eric, > > In article <[EMAIL PROTECTED]>, > Tue, 29 Apr 2008 15:28:56 -0700, > "Eric Barendt" <[EMAIL PROTECTED]> wrote: > eric> I'm working on switching our application from Basic to Form > authentication. > [snip] > eric> With FormAuthentication, I get "Missing service name parameter > eric> [Cactus_Service] in HTTP request." and "Error getting test result. > This > eric> could happen for example if you're using a load-balancer." This is > what I > eric> see in my access log: > eric> > eric> 127.0.0.1 - - [29/Apr/2008:16:50:18 -0500] "GET > eric> /application/ServletRedirectorSecure HTTP/1.1" 200 2357 > eric> 127.0.0.1 - - [29/Apr/2008:16:50:18 -0500] "POST > eric> /application/j_security_check HTTP/1.1" 302 - > eric> 127.0.0.1 - user [29/Apr/2008:16:50:18 -0500] "GET > eric> /application/ServletRedirectorSecure HTTP/1.1" 500 2527 > eric> 127.0.0.1 - user [29/Apr/2008:16:50:18 -0500] "GET > eric> /application/ServletRedirectorSecure?Cactus_Service=GET_RESULTS > HTTP/1.1" > eric> 500 2556 > > What is your servlet container? > > If you are using Tomcat later than 5.5.20, > my post to tomcat-users ML might helps you: >http://marc.info/?l=tomcat-user&m=119098089904045&w=2 > > If it works for you, please let me know. > > Kazuhito SUGURI > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Eric Barendt Danube Technologies, Inc.
Re: FormAuthentication problem
Hi Eric, In article <[EMAIL PROTECTED]>, Tue, 29 Apr 2008 15:28:56 -0700, "Eric Barendt" <[EMAIL PROTECTED]> wrote: eric> I'm working on switching our application from Basic to Form authentication. [snip] eric> With FormAuthentication, I get "Missing service name parameter eric> [Cactus_Service] in HTTP request." and "Error getting test result. This eric> could happen for example if you're using a load-balancer." This is what I eric> see in my access log: eric> eric> 127.0.0.1 - - [29/Apr/2008:16:50:18 -0500] "GET eric> /application/ServletRedirectorSecure HTTP/1.1" 200 2357 eric> 127.0.0.1 - - [29/Apr/2008:16:50:18 -0500] "POST eric> /application/j_security_check HTTP/1.1" 302 - eric> 127.0.0.1 - user [29/Apr/2008:16:50:18 -0500] "GET eric> /application/ServletRedirectorSecure HTTP/1.1" 500 2527 eric> 127.0.0.1 - user [29/Apr/2008:16:50:18 -0500] "GET eric> /application/ServletRedirectorSecure?Cactus_Service=GET_RESULTS HTTP/1.1" eric> 500 2556 What is your servlet container? If you are using Tomcat later than 5.5.20, my post to tomcat-users ML might helps you: http://marc.info/?l=tomcat-user&m=119098089904045&w=2 If it works for you, please let me know. Kazuhito SUGURI - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FormAuthentication
Thanks for the suggestion, but it ended up being my fault again. I think I'll wait a little tiny bit longer before asking for help next time. I always seem to figure it out shortly after I ask for help. I just need to pretend like I asked for help and then maybe the answer will come to me. :-) --David Nicolas Chalumeau wrote: Do you use the ant task or the maven plugin ? For the ant task add in your catifywar : roles="RoleBase"/> For the maven plugin I provide a patch but it is the same thing to do : http://issues.apache.org/jira/browse/CACTUS-224 Nicolas, 2005/9/1, David Turley <[EMAIL PROTECTED]>: Hi, it's me again... I'm trying to get the FormAuthentication to work. I'm having problems though. (Of course I'm having problems! Why else would I be writing!) When I try to run my test, my test fails and tells me it couldn't connect to the secured redirector. The console says "[Access Denied] NULL user". I haven't had any luck getting this to work. I'm using StrutsTestCase, so I asked for help in their user forum, but that forum is all but dead and I haven't gotten a response. I searched for any threads in there about authentication and all I found was another guy with a similar problem that hadn't had his question answered either... Thanks for any help you can provide. --David Turley - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FormAuthentication
Do you use the ant task or the maven plugin ? For the ant task add in your catifywar : For the maven plugin I provide a patch but it is the same thing to do : http://issues.apache.org/jira/browse/CACTUS-224 Nicolas, 2005/9/1, David Turley <[EMAIL PROTECTED]>: > Hi, it's me again... > > I'm trying to get the FormAuthentication to work. I'm having > problems though. (Of course I'm having problems! Why else would I be > writing!) When I try to run my test, my test fails and tells me it > couldn't connect to the secured redirector. The console says "[Access > Denied] NULL user". > > I haven't had any luck getting this to work. I'm using > StrutsTestCase, so I asked for help in their user forum, but that forum > is all but dead and I haven't gotten a response. I searched for any > threads in there about authentication and all I found was another guy > with a similar problem that hadn't had his question answered either... > > Thanks for any help you can provide. > > --David Turley > > - > 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]
RE: FormAuthentication and Error Code 500
Hi Kazuhito,
Unfortunately I haven't been able to spend any more time on this problem
since my last post. If I get some time over the next few days I'll find out
what exactly is going on and I'll let you guys know.
Thanks,
Setanta.
-Original Message-
From: Kazuhito SUGURI [mailto:[EMAIL PROTECTED]
Sent: 20 November 2004 07:56
To: [EMAIL PROTECTED]
Subject: Re: FormAuthentication and Error Code 500
Hi Setanta,
Could you post server log?
We need more detail to understand what's going on.
In article <[EMAIL PROTECTED]>,
Thu, 18 Nov 2004 13:25:02 -,
Setanta Mathews <[EMAIL PROTECTED]> wrote:
smathews> The authentication must be working. Part of the test in question
calls an
smathews> EJB that does the following check:
smathews>
smathews> principal = sessionContext.getCallerPrincipal();
smathews> name = principal.getName();
smathews> System.out.println("User Id: " + name);
smathews> if (name.equals("anonymous") || name.equals("guest"))
smathews> throw new PrincipalException("Principal must be
authenticated");
smathews>
smathews> Without the begin method in my test the principal name is "guest"
and a
smathews> PrincipalException will be thrown. With the begin method the
principal name
smathews> is "0" (so authentication must have happened) and no exception is
thrown.
If the purpose of the authentication is to get a principal name,
and you think the FormAuthentication goes worng,
you might try to use the BasicAuthentication for your unit-testing of EJBs.
smathews> I agree that setting the expected response code to 500 is
dangerous
smathews> but I can't spend too much more time trying to get my tests
running.
I don't think that is a good idea.
It may take long time to solve your problem with FormAuthentication,
but it cannot be a reason to bypassing the problem by such unusual approach.
I suggest you to use more simple authentication for your tests.
Regards,
Kazuhito SUGURI
mailto:[EMAIL PROTECTED]
-
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]
Re: FormAuthentication and Error Code 500
Hi Setanta,
Could you post server log?
We need more detail to understand what's going on.
In article <[EMAIL PROTECTED]>,
Thu, 18 Nov 2004 13:25:02 -,
Setanta Mathews <[EMAIL PROTECTED]> wrote:
smathews> The authentication must be working. Part of the test in question
calls an
smathews> EJB that does the following check:
smathews>
smathews> principal = sessionContext.getCallerPrincipal();
smathews> name = principal.getName();
smathews> System.out.println("User Id: " + name);
smathews> if (name.equals("anonymous") || name.equals("guest"))
smathews> throw new PrincipalException("Principal must be authenticated");
smathews>
smathews> Without the begin method in my test the principal name is "guest" and
a
smathews> PrincipalException will be thrown. With the begin method the
principal name
smathews> is "0" (so authentication must have happened) and no exception is
thrown.
If the purpose of the authentication is to get a principal name,
and you think the FormAuthentication goes worng,
you might try to use the BasicAuthentication for your unit-testing of EJBs.
smathews> I agree that setting the expected response code to 500 is dangerous
smathews> but I can't spend too much more time trying to get my tests running.
I don't think that is a good idea.
It may take long time to solve your problem with FormAuthentication,
but it cannot be a reason to bypassing the problem by such unusual approach.
I suggest you to use more simple authentication for your tests.
Regards,
Kazuhito SUGURI
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: FormAuthentication and Error Code 500
Hi,
The username and password are fine. I know they might look a bit odd but
they're valid. The user login page of the webapp takes in an e-mail address
and a password. It then posts to a struts action that gets the user id,
based on the email address, encrypts the password and then forwards on to a
page that automatically submits a form called j_security_check with
j_username and j_password set appropriately.
The authentication must be working. Part of the test in question calls an
EJB that does the following check:
principal = sessionContext.getCallerPrincipal();
name = principal.getName();
System.out.println("User Id: " + name);
if (name.equals("anonymous") || name.equals("guest"))
throw new PrincipalException("Principal must be authenticated");
Without the begin method in my test the principal name is "guest" and a
PrincipalException will be thrown. With the begin method the principal name
is "0" (so authentication must have happened) and no exception is thrown.
If I get the time I'll trace through what exactly is going on in the server
and post back to this list. I agree that setting the expected response code
to 500 is dangerous but I can't spend too much more time trying to get my
tests running.
Thanks,
Setanta.
-Original Message-
From: Kazuhito SUGURI [mailto:[EMAIL PROTECTED]
Sent: 18 November 2004 12:18
To: [EMAIL PROTECTED]
Subject: Re: FormAuthentication and Error Code 500
Hi Setanta,
In article <[EMAIL PROTECTED]>,
Thu, 18 Nov 2004 11:56:27 -,
Setanta Mathews <[EMAIL PROTECTED]> wrote:
smathews> I think the password is okay. If I change it to something else I
get a 403
smathews> (forbidden) error response code:
Can you access to a secured resource from your browser
as a user account you are coded in beginA method?
First of all, we need to know an account (id and password)
which is available in the system.
smathews> Now, if I change by begin method to expect a response code of 500
...
smathews>
smathews> public void beginA(WebRequest theRequest)
smathews> {
smathews> theRequest.setRedirectorName("ServletRedirectorSecure");
smathews> FormAuthentication fa = new FormAuthentication("0",
smathews> "qUqP5cyxm6YcTAhz05Hph5gvu9M=");
smathews> fa.setExpectedAuthResponse(500);
smathews> theRequest.setAuthentication(fa);
smathews> }
I strongly suggest, don't try this approach.
# need some protection logic in setExpectedAuthResponse()?
Regards,
Kazuhito SUGURI
mailto:[EMAIL PROTECTED]
-
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]
Re: FormAuthentication and Error Code 500
Hi Setanta,
In article <[EMAIL PROTECTED]>,
Thu, 18 Nov 2004 11:56:27 -,
Setanta Mathews <[EMAIL PROTECTED]> wrote:
smathews> I think the password is okay. If I change it to something else I get
a 403
smathews> (forbidden) error response code:
Can you access to a secured resource from your browser
as a user account you are coded in beginA method?
First of all, we need to know an account (id and password)
which is available in the system.
smathews> Now, if I change by begin method to expect a response code of 500 ...
smathews>
smathews> public void beginA(WebRequest theRequest)
smathews> {
smathews> theRequest.setRedirectorName("ServletRedirectorSecure");
smathews> FormAuthentication fa = new FormAuthentication("0",
smathews> "qUqP5cyxm6YcTAhz05Hph5gvu9M=");
smathews> fa.setExpectedAuthResponse(500);
smathews> theRequest.setAuthentication(fa);
smathews> }
I strongly suggest, don't try this approach.
# need some protection logic in setExpectedAuthResponse()?
Regards,
Kazuhito SUGURI
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: FormAuthentication and Error Code 500
Hi,
Thanks for the reply.
I think the password is okay. If I change it to something else I get a 403
(forbidden) error response code:
java.lang.Exception: Received a status code [403] and was expecting a [302]
Now things get a little bit strange ...
I think the HTTP sniffer I was using (HTTPLook) might have somehow been
interfering with HTTP traffic. After turning it off and running my test
again I got the following cactus error:
java.lang.Exception: Received a status code [500] and was expecting a [302]
And in my OC4J application.log you can see that the 500 Error was caused by
something I've seen in mailing list archives quite a bit:
javax.servlet.ServletException: Missing service name parameter
[Cactus_Service] in HTTP request. Received query string is [].
Now, if I change by begin method to expect a response code of 500 ...
public void beginA(WebRequest theRequest)
{
theRequest.setRedirectorName("ServletRedirectorSecure");
FormAuthentication fa = new FormAuthentication("0",
"qUqP5cyxm6YcTAhz05Hph5gvu9M=");
fa.setExpectedAuthResponse(500);
theRequest.setAuthentication(fa);
}
... guess what? The test runs fine. I'm still getting the application error
but I'm guessing that's because something in the web-app (I've only just
started working on it and I'm not too familiar with it just yet) tries to
process the original request to the ServletRedirectorSecure and there was no
Cactus_Service request parameter.
Out of curiosity I set the redirector name to the following in my begin
method:
theRequest.setRedirectorName("ServletRedirectorSecure?Cactus_Service=GET_VER
SION");
But I still get the 500 error.
Anyway, if a call to setExpectedAuthResponse(500) gets my tests running then
I'm happy for the time being.
Thanks,
Setanta.
-Original Message-
From: Kazuhito SUGURI [mailto:[EMAIL PROTECTED]
Sent: 18 November 2004 11:22
To: [EMAIL PROTECTED]
Subject: Re: FormAuthentication and Error Code 500
Hi Setanta,
In article <[EMAIL PROTECTED]>,
Thu, 18 Nov 2004 11:03:53 -,
Setanta Mathews <[EMAIL PROTECTED]> wrote:
smathews> public void beginA(WebRequest theRequest)
smathews> {
smathews>
theRequest.setRedirectorName("ServletRedirectorSecure");
smathews> FormAuthentication fa = new FormAuthentication("0",
smathews> "qUqP5cyxm6YcTAhz05Hph5gvu9M=");
smathews> theRequest.setAuthentication(fa);
smathews> }
Is the password "qUqP5cyxm6YcTAhz05Hph5gvu9M=" base-64 encoded?
Your system may stores passwords with encrypted and base-64 encoded form,
however, you should give a password with plain text form to the system.
So, you should pass a plain password to the constructor, I guess.
smathews> The HTTP traffic is
smathews>
smathews> 1 - Cactus Request
smathews>
smathews> GET /ServletRedirectorSecure? HTTP/1.1
smathews> Content-type: application/x-www-form-urlencoded
smathews> User-Agent: Jakarta Commons-HttpClient/2.0rc1
smathews> Host: localhost:8889
smathews>
smathews> 2 - OC4J Response
smathews>
smathews> HTTP/1.1 200 OK
smathews> Date: Thu, 18 Nov 2004 10:43:46 GMT
smathews> Server: Oracle9iAS (9.0.3.0.0) Containers for J2EE
smathews> Content-Location:
smathews> http://localhost:8889/jsp/html/portlet/my_account/j_login.jsp
smathews> Set-Cookie: JSESSIONID=b3eabbf09d734b998c79d15602741b8c; Path=/
smathews> Connection: Close
smathews> Content-Type: text/html;charset=ISO-8859-1
smathews> Cache-Control: no-cache
smathews> Transfer-Encoding: chunked
smathews>
smathews> 3 - Cactus Request
smathews>
smathews> POST /j_security_check? HTTP/1.1
smathews> Content-type: application/x-www-form-urlencoded
smathews> User-Agent: Jakarta Commons-HttpClient/2.0rc1
smathews> Host: localhost:8889
smathews> Cookie: $Version=0; JSESSIONID=b3eabbf09d734b998c79d15602741b8c
smathews> Content-Length: 54
smathews>
smathews> j_username=0&j_password=qUqP5cyxm6YcTAhz05Hph5gvu9M%3D
smathews>
smathews> 4 - OC4J Response
smathews>
smathews> HTTP/1.1 100 Continue
smathews> Server: Oracle9iAS (9.0.3.0.0) Containers for J2EE
smathews> Date: Thu, 18 Nov 2004 10:43:47 GMT
The last response means that the authentication is not completed.
I'm not sure why your container responses with status 100, however,
this may make your case, i.e. "unable to find line starting with HTTP".
Regards,
Kazuhito SUGURI
mailto:[EMAIL PROTECTED]
-
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]
Re: FormAuthentication and Error Code 500
Hi Setanta,
In article <[EMAIL PROTECTED]>,
Thu, 18 Nov 2004 11:03:53 -,
Setanta Mathews <[EMAIL PROTECTED]> wrote:
smathews> public void beginA(WebRequest theRequest)
smathews> {
smathews> theRequest.setRedirectorName("ServletRedirectorSecure");
smathews> FormAuthentication fa = new FormAuthentication("0",
smathews> "qUqP5cyxm6YcTAhz05Hph5gvu9M=");
smathews> theRequest.setAuthentication(fa);
smathews> }
Is the password "qUqP5cyxm6YcTAhz05Hph5gvu9M=" base-64 encoded?
Your system may stores passwords with encrypted and base-64 encoded form,
however, you should give a password with plain text form to the system.
So, you should pass a plain password to the constructor, I guess.
smathews> The HTTP traffic is
smathews>
smathews> 1 - Cactus Request
smathews>
smathews> GET /ServletRedirectorSecure? HTTP/1.1
smathews> Content-type: application/x-www-form-urlencoded
smathews> User-Agent: Jakarta Commons-HttpClient/2.0rc1
smathews> Host: localhost:8889
smathews>
smathews> 2 - OC4J Response
smathews>
smathews> HTTP/1.1 200 OK
smathews> Date: Thu, 18 Nov 2004 10:43:46 GMT
smathews> Server: Oracle9iAS (9.0.3.0.0) Containers for J2EE
smathews> Content-Location:
smathews> http://localhost:8889/jsp/html/portlet/my_account/j_login.jsp
smathews> Set-Cookie: JSESSIONID=b3eabbf09d734b998c79d15602741b8c; Path=/
smathews> Connection: Close
smathews> Content-Type: text/html;charset=ISO-8859-1
smathews> Cache-Control: no-cache
smathews> Transfer-Encoding: chunked
smathews>
smathews> 3 - Cactus Request
smathews>
smathews> POST /j_security_check? HTTP/1.1
smathews> Content-type: application/x-www-form-urlencoded
smathews> User-Agent: Jakarta Commons-HttpClient/2.0rc1
smathews> Host: localhost:8889
smathews> Cookie: $Version=0; JSESSIONID=b3eabbf09d734b998c79d15602741b8c
smathews> Content-Length: 54
smathews>
smathews> j_username=0&j_password=qUqP5cyxm6YcTAhz05Hph5gvu9M%3D
smathews>
smathews> 4 - OC4J Response
smathews>
smathews> HTTP/1.1 100 Continue
smathews> Server: Oracle9iAS (9.0.3.0.0) Containers for J2EE
smathews> Date: Thu, 18 Nov 2004 10:43:47 GMT
The last response means that the authentication is not completed.
I'm not sure why your container responses with status 100, however,
this may make your case, i.e. "unable to find line starting with HTTP".
Regards,
Kazuhito SUGURI
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: RE: FormAuthentication with machine name
Hi Vincent,
thanks for the answer.
Reading the documentation of the bug could have helped. Sorry.
I will investigate ...
Regards,
Anton
---
Anton Grimm
MAN Nutzfahrzeuge AG
IDP - Software Produktionsumgebungen
Dachauerstr.667
D - 80995 München
Fon: +49-89-1580-1054
Fax: +49-89-1580-911054
mailto:[EMAIL PROTECTED]
Internet: http://www.man-trucks.com
---
"Vincent Massol"
<[EMAIL PROTECTED]An: "'Cactus Users List'"
<[EMAIL PROTECTED]>
com> Kopie:
Thema:RE: FormAuthentication with
machine name
04/01/15 09:51 PM
Bitte antworten
an "Cactus Users
List"
Hi Anton,
Sorry for the late answer. The status is in the bug itself:
http://issues.apache.org/bugzilla/show_bug.cgi?id=17933
It's still open and thus has not been fixed. Would you have patch for
it?
Thanks
-Vincent
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 08 January 2004 11:11
> To: Cactus Users List
> Subject: FormAuthentication with machine name
>
>
>
>
>
> I already asked this question five months ago and did not get any
answer
> ...
>
> There was/is a Bug (17933) with FormAuthentication using not localhost
as
> the machine name
> in the cactus.properties file (cactus.contextURL).
>
> The fix was announced earlier for version 1.6.
> Is this already fixed in one of the nightly builds?
>
> I already tried two or three of the earlier ones but without success.
>
> Thanks for any help!
>
> Toni Grimm
>
> ---
> Anton Grimm
> MAN Nutzfahrzeuge AG
> IDP - Software Produktionsumgebungen
> Dachauerstr.667
> D - 80995 München
>
> Fon: +49-89-1580-1054
> Fax: +49-89-1580-911054
> mailto:[EMAIL PROTECTED]
> Internet: http://www.man-trucks.com
> ---
>
>
>
>
>
> "Vincent Massol"
> <[EMAIL PROTECTED]An: "'Cactus
Users
> List'" <[EMAIL PROTECTED]>
> com> Kopie:
>Thema:RE: Login
once
> using (FormAuthentication) for all tests in a class
> 04/01/08 09:55 AM
> Bitte antworten
> an "Cactus Users
> List"
>
>
>
>
>
>
> Hi Matt,
>
> > -Original Message-
> > From: Matt Raible [mailto:[EMAIL PROTECTED]
> > Sent: 08 January 2004 01:21
> > To: Cactus Users List
> > Subject: Login once using (FormAuthentication) for all tests in a
> class
> >
> > Quick and dirty question:
> >
> > Is it possible to login once (using FormAuthentication) for a class,
> > rather than adding a beginXXTestName befor every testXXTestName
> method?
> >
>
> hmm... There is a global begin(WebRequest) method. But it is called
> before every test (it's the equivalent of setUp() but on the client
> side). What we should do really is create the equivalent of JUnit
> TestSetup but with methods names begin/end instead of SetUp/tearDown.
> Patches much welcome :-)
>
> > Longer explanation:
> >
> > I have a number of tests in my ContactActionTest - this test extends
> > CactusStrutsTestCase, which extends ServletTestCase - nothing is
> really
> > Struts specific in this scenario.
> >
> > In order to simulate logging in, I've simply retrieved a user object
> in
> > by setUp() method and stuffed it into the session - this seems to
> > simulate a login good enough. However, today, I started logging
down
> > my Actions/Servlets with roles. So now this doesn't work - do I
have
> > to have a beginXX before each testXX that logs the user in (with
> > FormAuthentication)?
>
> Thinking more a
RE: FormAuthentication with machine name
Hi Anton, Sorry for the late answer. The status is in the bug itself: http://issues.apache.org/bugzilla/show_bug.cgi?id=17933 It's still open and thus has not been fixed. Would you have patch for it? Thanks -Vincent > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 08 January 2004 11:11 > To: Cactus Users List > Subject: FormAuthentication with machine name > > > > > > I already asked this question five months ago and did not get any answer > ... > > There was/is a Bug (17933) with FormAuthentication using not localhost as > the machine name > in the cactus.properties file (cactus.contextURL). > > The fix was announced earlier for version 1.6. > Is this already fixed in one of the nightly builds? > > I already tried two or three of the earlier ones but without success. > > Thanks for any help! > > Toni Grimm > > --- > Anton Grimm > MAN Nutzfahrzeuge AG > IDP - Software Produktionsumgebungen > Dachauerstr.667 > D - 80995 München > > Fon: +49-89-1580-1054 > Fax: +49-89-1580-911054 > mailto:[EMAIL PROTECTED] > Internet: http://www.man-trucks.com > --- > > > > > > "Vincent Massol" > <[EMAIL PROTECTED]An: "'Cactus Users > List'" <[EMAIL PROTECTED]> > com> Kopie: >Thema:RE: Login once > using (FormAuthentication) for all tests in a class > 04/01/08 09:55 AM > Bitte antworten > an "Cactus Users > List" > > > > > > > Hi Matt, > > > -Original Message- > > From: Matt Raible [mailto:[EMAIL PROTECTED] > > Sent: 08 January 2004 01:21 > > To: Cactus Users List > > Subject: Login once using (FormAuthentication) for all tests in a > class > > > > Quick and dirty question: > > > > Is it possible to login once (using FormAuthentication) for a class, > > rather than adding a beginXXTestName befor every testXXTestName > method? > > > > hmm... There is a global begin(WebRequest) method. But it is called > before every test (it's the equivalent of setUp() but on the client > side). What we should do really is create the equivalent of JUnit > TestSetup but with methods names begin/end instead of SetUp/tearDown. > Patches much welcome :-) > > > Longer explanation: > > > > I have a number of tests in my ContactActionTest - this test extends > > CactusStrutsTestCase, which extends ServletTestCase - nothing is > really > > Struts specific in this scenario. > > > > In order to simulate logging in, I've simply retrieved a user object > in > > by setUp() method and stuffed it into the session - this seems to > > simulate a login good enough. However, today, I started logging down > > my Actions/Servlets with roles. So now this doesn't work - do I have > > to have a beginXX before each testXX that logs the user in (with > > FormAuthentication)? > > Thinking more about it, I'm not so sure that the solution is a method > that is called only once... Each test must set its own fixture. So you > should group test using the same fixture (i.e. user being logging in) in > the same TestCase class. Then simply use either begin() or even better > setUp() (it has direct access to the session) to log the user in before > *each* test. > > Cactus is about unitary tests so each test must set its own fixture and > not depend on other tests or side effects. > > Thanks > -Vincent > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > This message and any attachments are confidential and may be privileged or > otherwise protected from disclosure. > If you are not the intended recipient, please telephone or email the > sender and delete this message and any attachment > from your system. If you are not the intended recipient, you must not copy > this message or attachment or disclose the > contents to any other person. > > > - > 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]
RE: FormAuthentication
Hi Jason, > -Original Message- > From: Robertson, Jason [mailto:Jason.Robertson@;acs-inc.com] > Sent: 28 October 2002 20:35 > To: 'Cactus Users List' > Subject: 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. I'd love if you could contribute to this servlet-unit subproject! However, I don't have much time ATM and it would be nice if it were in a similar format as the existing sample-servlet project... Anyway, anything you can submit will be of help! Thanks for your continuing help! -Vincent > > 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 Abstr
RE: FormAuthentication
Hi Jason/Michael, I don't believe HTTPS will work with the current version of Cactus. We're using HttpClient to make the connection to the server side. Thus the first thing to look at is how to enable HTTPS in httpclient. I think we need additional jars (jsse.jar and one or 2 others). Then we may need to change a few lines in Cactus code to allow this. Who wants to submit a patch? :-) Note: It's a nice to have feature but I don't believe it has any impact on unit testing any part of the code. Thanks -Vincent > -Original Message- > From: Robertson, Jason [mailto:Jason.Robertson@;acs-inc.com] > Sent: 29 October 2002 15:37 > To: 'Cactus Users List' > Subject: RE: FormAuthentication > > Here's my "SimpleFormLogin" project. This is project source, so look into > the build.xml file and adjust the "" 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- >
RE: FormAuthentication
Here's my "SimpleFormLogin" project. This is project source, so look into the build.xml file and adjust the "" 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 cha
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>
RE: FormAuthentication
Guys , I got past the 404 error.It was a mistake on my part by not mapping /ServletRedirectSecure to the ServletRedirectorSecure Alias of the ServletRedirector Servlet. Thanks again for your help and understanding. Pranab -Original Message- From: Dhar, Pranab [mailto:Pranab.Dhar@;DFA.STATE.NY.US] Sent: Sunday, October 27, 2002 10:39 PM To: 'Cactus Users List' Subject: RE: FormAuthentication Hi Jason/Vincent, I checked out the code changes and as expected the first call gets the JSESSIONID from the Server to proceed with calling the servlet set by Webrequest.setURL() .The GET_RESULTS query now use the same redirector. I am having a little glitch with the test as I am getting a 404 return code for a valid servlet. ... -- 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
ctorSecure] 20:22:11,240 [main] DEBUG util.UrlUtil- http://localhost:8080/ServletRedirectorSecure?Cactus_Service=GET_ RESULTS]) 20:22:11,240 [main] DEBUG util.UrlUtil- >getQuery = [Cactus_Service=GET_RESULTS] 20:22:11,240 [main] DEBUG ent.HttpClientConnectionHelper - http://localhost:8080/ServletRedirectorSecure?Cactus_Service=GET_RESULTS]) 20:22:11,240 [main] DEBUG cactus.Cookie - getCookiePath = [/ServletRedirectorSecure] 20:22:11,240 [main] DEBUG cactus.Cookie - getCookieDomain = [localhost] 20:22:11,240 [main] DEBUG cactus.Cookie - getCookiePath = [/ServletRedirectorSecure] 20:22:11,240 [main] DEBUG ent.HttpClientConnectionHelper - >getCookieString = [$Version=0; JSESSIONID=417F0AF81C47F5242AF988C66DAAFE11] 20:22:11,260 [main] DEBUG ent.HttpClientConnectionHelper - >connect = [org.apache.cactus.util.HttpURLConnection:http://localhost:8080/ServletRedir ectorSecure?Cactus_Service=GET_RESULTS] 20:22:11,260 [main] DEBUG util.IoUtil - getText = [ Error 404 -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>
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>
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 AbstractAuthentication 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
-Original Message-
From: Dhar, Pranab [mailto:Pranab.Dhar@;DFA.STATE.NY.US]
Sent: Friday, October 25, 2002 11:17 PM
To: 'Cactus Users List'
Subject: RE: FormAuthentication
Jason,
I found the Redirector change happening at function
(AbstractHttpClient.java)
private WebTestResult callGetResult(
AbstractAuthentication theAuthentication) throws Throwable
{
WebRequest resultsRequest = new WebRequest(this.configuration); <---
here
// Add authentication details
if (theAuthentication != null)
{
resultsRequest.setAuthentication(theAuthentication);
}
// Open the second connection to get the test results
ConnectionHelper helper = ConnectionHelperFactory.getConnectionHelper(
getRedirectorURL(resultsRequest), this.configuration);
The ServletConfiguration does not contain the redirector set in WebRequest
object
instead it loads it default redirector from the cactus.properties.
this.configuration is coming from new Configuration being initialized in
ServletTestCase class
* @see AbstractTestCase#createConfiguration()
*/
protected Configuration createConfiguration()
{
return new ServletConfiguration();
}
When the user sets the redirector in Webrequest that never gets updated in
the configuration.
So when getRedirectorURL() gets called in AbstractHttpClient.java which is
actually implemented
in ServletHttpClient.java as
protected String getRedirectorURL(WebRequest theRequest)
{
String url;
// Check if user has overriden the servlet redirector
if (theRequest.getRedirectorName() != null)
{
url = this.configuration.getContextURL() + "/"
+ theRequest.getRedirectorName();
}
else
{
url = this.configuration.getRedirectorURL();
}
return url;
}
The theRequest parameter being a newly intialized WebRequest object does not
have the
redirector set from the old request object used for Form Authentication.
Hence callResult function never goes to the Secured Servlet Redirector used
earlier to run the test.
I am not too sure if the unsecured redirector will be able to return the
results.
Maybe cactus guru's will know the answer to this design.
Pranab
-Original Message-
From: Robertson, Jason [mailto:Jason.Robertson@;acs-inc.com]
Sent: Friday, October 25, 2002 6:20 PM
To: 'Cactus Users List'
Subject: RE: FormAuthentication
Yes, you're correct with the need to get the context URL as well.
As for the rest of it, I'm not sure. I'll try looking at the log again, but
there's a lot of information there!
Jason
-Original Message-
From: Dhar, Pranab [mailto:Pranab.Dhar@;DFA.STATE.NY.US]
Sent: Friday, October 25, 2002 3:43 PM
To: 'Cactus Users List'
Subject: RE: FormAuthentication
Jason,
Sorry for the typo Error in my last post.it should be
getConfiguration().getContextURL()+"/"+theRequest.getRedirectorName();
I just compiled the code and tested it. I am getting past the authentication
now
but getting stuck somewhere after that. Somewhere down the line the
ServletRedirectorSecure
is getting switched back to ServletRedirector even though I am setting the
URL to a
secured resource.I am getting a Error 404 instead of the regulars output
from the servlet.
Pranab
I added the following in the test code
public void beginBasicAuthentication(WebRequest theRequest) {
theRe
RE: FormAuthentication
Jason,
I found the Redirector change happening at function
(AbstractHttpClient.java)
private WebTestResult callGetResult(
AbstractAuthentication theAuthentication) throws Throwable
{
WebRequest resultsRequest = new WebRequest(this.configuration); <---
here
// Add authentication details
if (theAuthentication != null)
{
resultsRequest.setAuthentication(theAuthentication);
}
// Open the second connection to get the test results
ConnectionHelper helper = ConnectionHelperFactory.getConnectionHelper(
getRedirectorURL(resultsRequest), this.configuration);
The ServletConfiguration does not contain the redirector set in WebRequest
object
instead it loads it default redirector from the cactus.properties.
this.configuration is coming from new Configuration being initialized in
ServletTestCase class
* @see AbstractTestCase#createConfiguration()
*/
protected Configuration createConfiguration()
{
return new ServletConfiguration();
}
When the user sets the redirector in Webrequest that never gets updated in
the configuration.
So when getRedirectorURL() gets called in AbstractHttpClient.java which is
actually implemented
in ServletHttpClient.java as
protected String getRedirectorURL(WebRequest theRequest)
{
String url;
// Check if user has overriden the servlet redirector
if (theRequest.getRedirectorName() != null)
{
url = this.configuration.getContextURL() + "/"
+ theRequest.getRedirectorName();
}
else
{
url = this.configuration.getRedirectorURL();
}
return url;
}
The theRequest parameter being a newly intialized WebRequest object does not
have the
redirector set from the old request object used for Form Authentication.
Hence callResult function never goes to the Secured Servlet Redirector used
earlier to run the test.
I am not too sure if the unsecured redirector will be able to return the
results.
Maybe cactus guru's will know the answer to this design.
Pranab
-Original Message-
From: Robertson, Jason [mailto:Jason.Robertson@;acs-inc.com]
Sent: Friday, October 25, 2002 6:20 PM
To: 'Cactus Users List'
Subject: RE: FormAuthentication
Yes, you're correct with the need to get the context URL as well.
As for the rest of it, I'm not sure. I'll try looking at the log again, but
there's a lot of information there!
Jason
-Original Message-
From: Dhar, Pranab [mailto:Pranab.Dhar@;DFA.STATE.NY.US]
Sent: Friday, October 25, 2002 3:43 PM
To: 'Cactus Users List'
Subject: RE: FormAuthentication
Jason,
Sorry for the typo Error in my last post.it should be
getConfiguration().getContextURL()+"/"+theRequest.getRedirectorName();
I just compiled the code and tested it. I am getting past the authentication
now
but getting stuck somewhere after that. Somewhere down the line the
ServletRedirectorSecure
is getting switched back to ServletRedirector even though I am setting the
URL to a
secured resource.I am getting a Error 404 instead of the regulars output
from the servlet.
Pranab
I added the following in the test code
public void beginBasicAuthentication(WebRequest theRequest) {
theRequest.setURL("localhost:8080", "/", "/secure/idsconf",
null, null); <--
theRequest.addCookie( "test", "test" );
theRequest.setRedirectorName("ServletRedirectorSecure");
theRequest.setAuthentication( new
FormAuthentication("admin", "admin"));
}
public void testBasicAuthentication() {
try {
idsconfServlet servlet = new
idsconfServlet();<--
servlet.init(this.config);<--
servlet.doGet(this.request,this.response);<--
assertEquals("admin",
request.getUserPrincipal().getName());
assertEquals("admin",
request.getRemoteUser());
assertTrue("User not in 'admin' role",
request.isUserInRole("admin"));
} catch (ServletException e) {
log.error(e);
} catch (IOException e) {
log.error(e);
}
}
Debug LOG
15:25:40,563 [main] DEBUG util.UrlUtil-
http://localhost:8080/ServletRedirectorSecure?Cactus_TestMethod=te
stBasicAuthentication&Cactus_URL_ContextPath=%2F&Cactus_URL_Server=localhost
%3A8080&Cactus_URL_ServletPath=%2Fsecure%2Fidsconf&Cactus_TestClass=com.ids.
servlet.TestLoginServlet&Cactus_AutomaticSession=true&
RE: FormAuthentication
Yes, you're correct with the need to get the context URL as well.
As for the rest of it, I'm not sure. I'll try looking at the log again, but
there's a lot of information there!
Jason
-Original Message-
From: Dhar, Pranab [mailto:Pranab.Dhar@;DFA.STATE.NY.US]
Sent: Friday, October 25, 2002 3:43 PM
To: 'Cactus Users List'
Subject: RE: FormAuthentication
Jason,
Sorry for the typo Error in my last post.it should be
getConfiguration().getContextURL()+"/"+theRequest.getRedirectorName();
I just compiled the code and tested it. I am getting past the authentication
now
but getting stuck somewhere after that. Somewhere down the line the
ServletRedirectorSecure
is getting switched back to ServletRedirector even though I am setting the
URL to a
secured resource.I am getting a Error 404 instead of the regulars output
from the servlet.
Pranab
I added the following in the test code
public void beginBasicAuthentication(WebRequest theRequest) {
theRequest.setURL("localhost:8080", "/", "/secure/idsconf",
null, null); <--
theRequest.addCookie( "test", "test" );
theRequest.setRedirectorName("ServletRedirectorSecure");
theRequest.setAuthentication( new
FormAuthentication("admin", "admin"));
}
public void testBasicAuthentication() {
try {
idsconfServlet servlet = new
idsconfServlet();<--
servlet.init(this.config);<--
servlet.doGet(this.request,this.response);<--
assertEquals("admin",
request.getUserPrincipal().getName());
assertEquals("admin",
request.getRemoteUser());
assertTrue("User not in 'admin' role",
request.isUserInRole("admin"));
} catch (ServletException e) {
log.error(e);
} catch (IOException e) {
log.error(e);
}
}
Debug LOG
15:25:40,563 [main] DEBUG util.UrlUtil-
http://localhost:8080/ServletRedirectorSecure?Cactus_TestMethod=te
stBasicAuthentication&Cactus_URL_ContextPath=%2F&Cactus_URL_Server=localhost
%3A8080&Cactus_URL_ServletPath=%2Fsecure%2Fidsconf&Cactus_TestClass=com.ids.
servlet.TestLoginServlet&Cactus_AutomaticSession=true&Cactus_URL_Protocol=ht
tp&Cactus_Service=CALL_TEST])
15:25:40,563 [main] DEBUG util.UrlUtil- >getPath =
[/ServletRedirectorSecure]
15:25:40,563 [main] DEBUG util.UrlUtil-
http://localhost:8080/ServletRedirectorSecure?Cactus_TestMethod=t
estBasicAuthentication&Cactus_URL_ContextPath=%2F&Cactus_URL_Server=localhos
t%3A8080&Cactus_URL_ServletPath=%2Fsecure%2Fidsconf&Cactus_TestClass=com.ids
.servlet.TestLoginServlet&Cactus_AutomaticSession=true&Cactus_URL_Protocol=h
ttp&Cactus_Service=CALL_TEST])
15:25:40,563 [main] DEBUG util.UrlUtil- >getQuery =
[Cactus_TestMethod=testBasicAuthentication&Cactus_URL_ContextPath=%2F&Cactus
_URL_Server=localhost%3A8080&Cactus_URL_ServletPath=%2Fsecure%2Fidsconf&Cact
us_TestClass=com.ids.servlet.TestLoginServlet&Cactus_AutomaticSession=true&C
actus_URL_Protocol=http&Cactus_Service=CALL_TEST]
15:25:40,563 [main] DEBUG ent.HttpClientConnectionHelper -
http://localhost:8080/ServletRedirectorSecure?Cactus_TestMethod=testBasicAu
thentication&Cactus_URL_ContextPath=%2F&Cactus_URL_Server=localhost%3A8080&C
actus_URL_ServletPath=%2Fsecure%2Fidsconf&Cactus_TestClass=com.ids.servlet.T
estLoginServlet&Cactus_AutomaticSession=true&Cactus_URL_Protocol=http&Cactus
_Service=CALL_TEST])
15:25:40,563 [main] DEBUG cactus.Cookie -
getCookiePath =
[//secure/idsconf]
15:25:40,563 [main] DEBUG cactus.Cookie -
getCookiePath =
[//secure/idsconf]
15:25:40,563 [main] DEBUG cactus.Cookie -
getCookieDomain
= [localhost]
15:25:40,563 [main] DEBUG cactus.Cookie -
getCookiePath =
[//secure/idsconf]
15:25:40,683 [main] DEBUG ent.HttpClientConnectionHelper - >getCookieString
= [$Version=0; test=test; JSESSIONID=B9D9DDE0DD962B211E36D92FBE854D67]
15:25:50,928 [main] DEBUG ent.HttpClientConnectionHelper - >connect =
[org.apache.cactus.util.HttpURLConnection:http://localhost:8080/ServletRedir
ectorSecure?Cactus_TestMethod=testBasicAuthentication&Cactus_URL_ContextPath
=%2F&Cactus_URL_Server=localhost%3A8080&Cactus_URL_ServletPath=%2Fsecure%2Fi
dsconf&Cactus_TestClass=com.ids.servlet.TestLoginServlet&Cactus_AutomaticSes
sion=true&Cactus_URL_Protocol=http&Cactu
RE: FormAuthentication
Jason,
Sorry for the typo Error in my last post.it should be
getConfiguration().getContextURL()+"/"+theRequest.getRedirectorName();
I just compiled the code and tested it. I am getting past the authentication
now
but getting stuck somewhere after that. Somewhere down the line the
ServletRedirectorSecure
is getting switched back to ServletRedirector even though I am setting the
URL to a
secured resource.I am getting a Error 404 instead of the regulars output
from the servlet.
Pranab
I added the following in the test code
public void beginBasicAuthentication(WebRequest theRequest) {
theRequest.setURL("localhost:8080", "/", "/secure/idsconf",
null, null); <--
theRequest.addCookie( "test", "test" );
theRequest.setRedirectorName("ServletRedirectorSecure");
theRequest.setAuthentication( new
FormAuthentication("admin", "admin"));
}
public void testBasicAuthentication() {
try {
idsconfServlet servlet = new
idsconfServlet();<--
servlet.init(this.config);<--
servlet.doGet(this.request,this.response);<--
assertEquals("admin",
request.getUserPrincipal().getName());
assertEquals("admin",
request.getRemoteUser());
assertTrue("User not in 'admin' role",
request.isUserInRole("admin"));
} catch (ServletException e) {
log.error(e);
} catch (IOException e) {
log.error(e);
}
}
Debug LOG
15:25:40,563 [main] DEBUG util.UrlUtil-
http://localhost:8080/ServletRedirectorSecure?Cactus_TestMethod=te
stBasicAuthentication&Cactus_URL_ContextPath=%2F&Cactus_URL_Server=localhost
%3A8080&Cactus_URL_ServletPath=%2Fsecure%2Fidsconf&Cactus_TestClass=com.ids.
servlet.TestLoginServlet&Cactus_AutomaticSession=true&Cactus_URL_Protocol=ht
tp&Cactus_Service=CALL_TEST])
15:25:40,563 [main] DEBUG util.UrlUtil- >getPath =
[/ServletRedirectorSecure]
15:25:40,563 [main] DEBUG util.UrlUtil-
http://localhost:8080/ServletRedirectorSecure?Cactus_TestMethod=t
estBasicAuthentication&Cactus_URL_ContextPath=%2F&Cactus_URL_Server=localhos
t%3A8080&Cactus_URL_ServletPath=%2Fsecure%2Fidsconf&Cactus_TestClass=com.ids
.servlet.TestLoginServlet&Cactus_AutomaticSession=true&Cactus_URL_Protocol=h
ttp&Cactus_Service=CALL_TEST])
15:25:40,563 [main] DEBUG util.UrlUtil- >getQuery =
[Cactus_TestMethod=testBasicAuthentication&Cactus_URL_ContextPath=%2F&Cactus
_URL_Server=localhost%3A8080&Cactus_URL_ServletPath=%2Fsecure%2Fidsconf&Cact
us_TestClass=com.ids.servlet.TestLoginServlet&Cactus_AutomaticSession=true&C
actus_URL_Protocol=http&Cactus_Service=CALL_TEST]
15:25:40,563 [main] DEBUG ent.HttpClientConnectionHelper -
http://localhost:8080/ServletRedirectorSecure?Cactus_TestMethod=testBasicAu
thentication&Cactus_URL_ContextPath=%2F&Cactus_URL_Server=localhost%3A8080&C
actus_URL_ServletPath=%2Fsecure%2Fidsconf&Cactus_TestClass=com.ids.servlet.T
estLoginServlet&Cactus_AutomaticSession=true&Cactus_URL_Protocol=http&Cactus
_Service=CALL_TEST])
15:25:40,563 [main] DEBUG cactus.Cookie -
getCookiePath =
[//secure/idsconf]
15:25:40,563 [main] DEBUG cactus.Cookie -
getCookiePath =
[//secure/idsconf]
15:25:40,563 [main] DEBUG cactus.Cookie -
getCookieDomain
= [localhost]
15:25:40,563 [main] DEBUG cactus.Cookie -
getCookiePath =
[//secure/idsconf]
15:25:40,683 [main] DEBUG ent.HttpClientConnectionHelper - >getCookieString
= [$Version=0; test=test; JSESSIONID=B9D9DDE0DD962B211E36D92FBE854D67]
15:25:50,928 [main] DEBUG ent.HttpClientConnectionHelper - >connect =
[org.apache.cactus.util.HttpURLConnection:http://localhost:8080/ServletRedir
ectorSecure?Cactus_TestMethod=testBasicAuthentication&Cactus_URL_ContextPath
=%2F&Cactus_URL_Server=localhost%3A8080&Cactus_URL_ServletPath=%2Fsecure%2Fi
dsconf&Cactus_TestClass=com.ids.servlet.TestLoginServlet&Cactus_AutomaticSes
sion=true&Cactus_URL_Protocol=http&Cactus_Service=CALL_TEST]
15:25:50,938 [main] DEBUG ient.AutoReadHttpURLConnection - Original
connection =
org.apache.cactus.util.HttpURLConnection:http://localhost:8080/ServletRedire
ctorSecure?Cactus_TestMethod=testBasicAuthentication&Cactus_URL_ContextPath=
%2F&Cactus_URL_Server=localhost%3A8080&Cactus_URL_ServletPath=%2Fsecure%2Fid
sconf&Cactus_TestClass=com.ids.servlet.TestLoginServlet&Cactus_AutomaticSess
ion=true&Cactus_URL_Protocol=http&Cactus_Service=CALL_TEST
15:25:50,938 [main] DEBUG util.HttpURLConnection -
getHeaderField
= [null]
15:25:50,938 [main] DEBUG ient.AutoReadHttpURLConnection - Content-Length :
[-1]
15:25:50,938 [main] DEBUG util.HttpURLConnection -
getHead
RE: FormAuthentication
Jason,
I think the resource string should be the URL (
http://localhost:8080/ServletRedirectorSecure )
String resource =
theRequest.getConfiguration().getContextURL()+"/"+theRequest.getRedirectorUR
L();
Pranab
-Original Message-
From: Robertson, Jason [mailto:Jason.Robertson@;acs-inc.com]
Sent: Friday, October 25, 2002 1:47 PM
To: 'Cactus Users List'
Subject: RE: FormAuthentication
I think you've found a problem!
I was unaware that you could change the redirector name in the WebRequest so
I didn't deal with that scenario. If you can, change the authenticate
function to be this (add the WebRequest argument, and then use it to get the
redirector name):
public void authenticate(WebRequest theRequest)
{
//Note: This method needs refactoring. It is too complex.
try
{
// Create a helper that will connect to a restricted resource.
String resource = theRequest.getRedirectorName();
...
and pass theRequest to the authenticate function in configuration method:
if (this.sessionId == null)
{
authenticate(theRequest);
}
and give it a try.
If that fixes things I'll work up a proper patch and submit it.
Good catch!
Jason
-Original Message-
From: Dhar, Pranab [mailto:Pranab.Dhar@;DFA.STATE.NY.US]
Sent: Friday, October 25, 2002 1:32 PM
To: 'Cactus Users List'
Subject: RE: FormAuthentication
Jason,
The servlet mapping in WEB-INF/web.xml is
ServletRedirector
org.apache.cactus.server.ServletTestRedirector
ServletRedirectorSecure
org.apache.cactus.server.ServletTestRedirector
two aliases for the same Redirector servlet and the security constraint is
on the
ServletRedirectorSecure alias.
SecurityRestriction
Protect the Cactus
redirectorservlet.
/ServletRedirectorSecure
GET
POST
Authorized Users Group
idsconf_admin
idsconf_user
NONE
cactus.properties contains :-
cactus.contextURL = http://localhost:8080 only
and the testcase sets the redirector by calling :-
theRequest.setRedirectorName("ServletRedirectorSecure");
As long as I set the redirector in the test case it will override the
default redirector.
Then the question is why the default redirector is being used after the
override.
[org.apache.cactus.util.HttpURLConnection:http://localhost:8080/ServletRedir
ector]
I think I found the problem in cactus code.
I am setting redirector in the class WebRequest.redirectorName whereas the
FormAuthentication is getting the redirector name from the WebConfiguration
interface
implemented by the ServletConfiguration class which reads the redirector
name from
cactus.properties and used the default "ServletRedirector" if not specified.
The WebRequest wrapper should rather modify the stored configuration
object to
the new Redirector or the Servlet Configuration should check the request
object to get
the modified redirector.
/**
* @param theConfiguration the Cactus configuration
*/
public WebRequest(WebConfiguration theConfiguration)
{
this.configuration = theConfiguration;
}
/**
* Override the redirector Name defined in
cactus.properties.
* This is useful to define a per test case Name (for example, if some
* test case need to have authentication turned on and not other tests,
* etc).
*
* @param theRedirectorName the new redirector Name to use
*/
public void setRedirectorName(String theRedirectorName)
{
this.redirectorName = theRedirectorName;
}
Tell me what you think.
Pranab
-Original Message-
From: Robertson, Jason [mailto:Jason.Robertson@;acs-inc.com]
Sent: Friday, October 25, 2002 12:44 PM
To: 'Cactus Users List'
Subject: RE: FormAuthentication
One thing I notice is that cactus connects to
http://localhost:8080/ServletRedirector but you have the Tomcat config url
pattern as /ServletRedirectorSecure. Try removing the "Secure" from the end.
Make the ServletRedirector servlet a secure resource. (Alternatively, you
could add "Secure" to you cactus.properties file, but I'd say it would be
better to remove it.)
Let me know if that changes anything.
Jason
-Original Message-
From: Dhar, Pranab [mailto:Pranab.Dhar@;DFA.STATE.NY.US]
Sent: Friday, October 25, 2002 11:47 AM
To: 'Cactus Users List'
Subject: RE: FormAuthentication
Hi Jason,
Yes Authentication works. I am using JBoss app server.
with user defined security realm/domain where all the users and roles are
mapped
using users.properties and roles.properties.I can run the servlet
straightaway and
I am asked to authenticate u
RE: FormAuthentication
I think you've found a problem!
I was unaware that you could change the redirector name in the WebRequest so
I didn't deal with that scenario. If you can, change the authenticate
function to be this (add the WebRequest argument, and then use it to get the
redirector name):
public void authenticate(WebRequest theRequest)
{
//Note: This method needs refactoring. It is too complex.
try
{
// Create a helper that will connect to a restricted resource.
String resource = theRequest.getRedirectorName();
...
and pass theRequest to the authenticate function in configuration method:
if (this.sessionId == null)
{
authenticate(theRequest);
}
and give it a try.
If that fixes things I'll work up a proper patch and submit it.
Good catch!
Jason
-Original Message-
From: Dhar, Pranab [mailto:Pranab.Dhar@;DFA.STATE.NY.US]
Sent: Friday, October 25, 2002 1:32 PM
To: 'Cactus Users List'
Subject: RE: FormAuthentication
Jason,
The servlet mapping in WEB-INF/web.xml is
ServletRedirector
org.apache.cactus.server.ServletTestRedirector
ServletRedirectorSecure
org.apache.cactus.server.ServletTestRedirector
two aliases for the same Redirector servlet and the security constraint is
on the
ServletRedirectorSecure alias.
SecurityRestriction
Protect the Cactus
redirectorservlet.
/ServletRedirectorSecure
GET
POST
Authorized Users Group
idsconf_admin
idsconf_user
NONE
cactus.properties contains :-
cactus.contextURL = http://localhost:8080 only
and the testcase sets the redirector by calling :-
theRequest.setRedirectorName("ServletRedirectorSecure");
As long as I set the redirector in the test case it will override the
default redirector.
Then the question is why the default redirector is being used after the
override.
[org.apache.cactus.util.HttpURLConnection:http://localhost:8080/ServletRedir
ector]
I think I found the problem in cactus code.
I am setting redirector in the class WebRequest.redirectorName whereas the
FormAuthentication is getting the redirector name from the WebConfiguration
interface
implemented by the ServletConfiguration class which reads the redirector
name from
cactus.properties and used the default "ServletRedirector" if not specified.
The WebRequest wrapper should rather modify the stored configuration
object to
the new Redirector or the Servlet Configuration should check the request
object to get
the modified redirector.
/**
* @param theConfiguration the Cactus configuration
*/
public WebRequest(WebConfiguration theConfiguration)
{
this.configuration = theConfiguration;
}
/**
* Override the redirector Name defined in
cactus.properties.
* This is useful to define a per test case Name (for example, if some
* test case need to have authentication turned on and not other tests,
* etc).
*
* @param theRedirectorName the new redirector Name to use
*/
public void setRedirectorName(String theRedirectorName)
{
this.redirectorName = theRedirectorName;
}
Tell me what you think.
Pranab
-Original Message-
From: Robertson, Jason [mailto:Jason.Robertson@;acs-inc.com]
Sent: Friday, October 25, 2002 12:44 PM
To: 'Cactus Users List'
Subject: RE: FormAuthentication
One thing I notice is that cactus connects to
http://localhost:8080/ServletRedirector but you have the Tomcat config url
pattern as /ServletRedirectorSecure. Try removing the "Secure" from the end.
Make the ServletRedirector servlet a secure resource. (Alternatively, you
could add "Secure" to you cactus.properties file, but I'd say it would be
better to remove it.)
Let me know if that changes anything.
Jason
-Original Message-
From: Dhar, Pranab [mailto:Pranab.Dhar@;DFA.STATE.NY.US]
Sent: Friday, October 25, 2002 11:47 AM
To: 'Cactus Users List'
Subject: RE: FormAuthentication
Hi Jason,
Yes Authentication works. I am using JBoss app server.
with user defined security realm/domain where all the users and roles are
mapped
using users.properties and roles.properties.I can run the servlet
straightaway and
I am asked to authenticate using a FormLogin.I have been able to set
security role-mapping
JSP/Servlets-to-EJB.I was trying to write test cases to test Servlet's &
EJB's with their
roles for which I need the JBoss App Server to authenticate and set up
Identity/Principal
and their roles.
Let me know how can I help.
Pranab
-
RE: FormAuthentication
Jason,
The servlet mapping in WEB-INF/web.xml is
ServletRedirector
org.apache.cactus.server.ServletTestRedirector
ServletRedirectorSecure
org.apache.cactus.server.ServletTestRedirector
two aliases for the same Redirector servlet and the security constraint is
on the
ServletRedirectorSecure alias.
SecurityRestriction
Protect the Cactus
redirectorservlet.
/ServletRedirectorSecure
GET
POST
Authorized Users Group
idsconf_admin
idsconf_user
NONE
cactus.properties contains :-
cactus.contextURL = http://localhost:8080 only
and the testcase sets the redirector by calling :-
theRequest.setRedirectorName("ServletRedirectorSecure");
As long as I set the redirector in the test case it will override the
default redirector.
Then the question is why the default redirector is being used after the
override.
[org.apache.cactus.util.HttpURLConnection:http://localhost:8080/ServletRedir
ector]
I think I found the problem in cactus code.
I am setting redirector in the class WebRequest.redirectorName whereas the
FormAuthentication is getting the redirector name from the WebConfiguration
interface
implemented by the ServletConfiguration class which reads the redirector
name from
cactus.properties and used the default "ServletRedirector" if not specified.
The WebRequest wrapper should rather modify the stored configuration
object to
the new Redirector or the Servlet Configuration should check the request
object to get
the modified redirector.
/**
* @param theConfiguration the Cactus configuration
*/
public WebRequest(WebConfiguration theConfiguration)
{
this.configuration = theConfiguration;
}
/**
* Override the redirector Name defined in
cactus.properties.
* This is useful to define a per test case Name (for example, if some
* test case need to have authentication turned on and not other tests,
* etc).
*
* @param theRedirectorName the new redirector Name to use
*/
public void setRedirectorName(String theRedirectorName)
{
this.redirectorName = theRedirectorName;
}
Tell me what you think.
Pranab
-Original Message-
From: Robertson, Jason [mailto:Jason.Robertson@;acs-inc.com]
Sent: Friday, October 25, 2002 12:44 PM
To: 'Cactus Users List'
Subject: RE: FormAuthentication
One thing I notice is that cactus connects to
http://localhost:8080/ServletRedirector but you have the Tomcat config url
pattern as /ServletRedirectorSecure. Try removing the "Secure" from the end.
Make the ServletRedirector servlet a secure resource. (Alternatively, you
could add "Secure" to you cactus.properties file, but I'd say it would be
better to remove it.)
Let me know if that changes anything.
Jason
-Original Message-
From: Dhar, Pranab [mailto:Pranab.Dhar@;DFA.STATE.NY.US]
Sent: Friday, October 25, 2002 11:47 AM
To: 'Cactus Users List'
Subject: RE: FormAuthentication
Hi Jason,
Yes Authentication works. I am using JBoss app server.
with user defined security realm/domain where all the users and roles are
mapped
using users.properties and roles.properties.I can run the servlet
straightaway and
I am asked to authenticate using a FormLogin.I have been able to set
security role-mapping
JSP/Servlets-to-EJB.I was trying to write test cases to test Servlet's &
EJB's with their
roles for which I need the JBoss App Server to authenticate and set up
Identity/Principal
and their roles.
Let me know how can I help.
Pranab
--
JBoss Security Realm login-config.xml:-
guest
--
Tomcat Security:-
SecurityRestriction
Protect the Cactus redirector
servlet.
/ServletRedirectorSecure
GET
POST
Authorized Users Group
idsconf_admin
idsconf_user
NONE
FORM
IDSCONF-REALM
/LoginForm.jsp
/LoginError.jsp
The Secure ROLE
idsconf_admin
The Non Secure ROLE
idsconf_user
--
J2EE application roles:-
.. app jars.
Administrator Role
idsconf_admin
User Role
idsconf_user
Internal Role
idsconf_inter
RE: FormAuthentication
One thing I notice is that cactus connects to
http://localhost:8080/ServletRedirector but you have the Tomcat config url
pattern as /ServletRedirectorSecure. Try removing the "Secure" from the end.
Make the ServletRedirector servlet a secure resource. (Alternatively, you
could add "Secure" to you cactus.properties file, but I'd say it would be
better to remove it.)
Let me know if that changes anything.
Jason
-Original Message-
From: Dhar, Pranab [mailto:Pranab.Dhar@;DFA.STATE.NY.US]
Sent: Friday, October 25, 2002 11:47 AM
To: 'Cactus Users List'
Subject: RE: FormAuthentication
Hi Jason,
Yes Authentication works. I am using JBoss app server.
with user defined security realm/domain where all the users and roles are
mapped
using users.properties and roles.properties.I can run the servlet
straightaway and
I am asked to authenticate using a FormLogin.I have been able to set
security role-mapping
JSP/Servlets-to-EJB.I was trying to write test cases to test Servlet's &
EJB's with their
roles for which I need the JBoss App Server to authenticate and set up
Identity/Principal
and their roles.
Let me know how can I help.
Pranab
--
JBoss Security Realm login-config.xml:-
guest
--
Tomcat Security:-
SecurityRestriction
Protect the Cactus redirector
servlet.
/ServletRedirectorSecure
GET
POST
Authorized Users Group
idsconf_admin
idsconf_user
NONE
FORM
IDSCONF-REALM
/LoginForm.jsp
/LoginError.jsp
The Secure ROLE
idsconf_admin
The Non Secure ROLE
idsconf_user
--
J2EE application roles:-
.. app jars.
Administrator Role
idsconf_admin
User Role
idsconf_user
Internal Role
idsconf_internal
JBoss EJB Security mapping jboss.xml
java:jaas/IDSCONF-REALM
. entity/session beans jndi mapping
Standard Stateless
SessionBean
java:/jaas/IDSCONF-REALM
Standard BMP EntityBean
java:/jaas/IDSCONF-REALM
Unsecure Stateless
SessionBean
--
# A sample users.properties file for use with the UsersRolesLoginModule
# user=password
admin=admin
pkdhar=pkdhar
bob=bob
--
# A sample roles.properties file for use with the UsersRolesLoginModule
# user=role1,role2...
admin=idsconf_admin,idsconf_user
pkdhar=idsconf_user
bob=idsconf_user
-Original Message-
From: Robertson, Jason [mailto:Jason.Robertson@;acs-inc.com]
Sent: Friday, October 25, 2002 11:21 AM
To: 'Cactus Users List'
Subject: RE: FormAuthentication
Buried in the stack trace is "Failed to authenticate the principal". If you
try to log into the website normally using admin/admin does it work?
What server are you using? We have test cases that work with Tomcat and
WebLogic.
Jason
-Original Message-
From: Dhar, Pranab [mailto:Pranab.Dhar@;DFA.STATE.NY.US]
Sent: Friday, October 25, 2002 10:10 AM
To: '[EMAIL PROTECTED]'
Subject: FormAuthentication
Hi,
I am in a situation where I have EJB's and servlets created with security
roles defined.I need to test the Servlets and EJB's doing the authentication
in the process.I am using FormAuthentication for the secured
jsp/servlets/struts forms and actions.
I installed cactus 1.4.1 and found out that it does'nt implement form
authentication so I am now using the nightly build 20021022 after checking
the mailing list that some gentlemen have been adding this new feature.
My testcase is as follows:-
public void beginBasicAuthentication(WebRequest theRequest) {
theRequest.setURL("localhost:8080", "/", "/secure/idsconf",
null, null);
theRequest.addCookie( "test", "test" );
theRequest.setRedirectorName("ServletRedirectorSecure");
theRequest.setAuthentication(new FormAuthentication("admin",
"admin"));
}
public void testBasicAuthentication() {
assertEquals("admin",
request.getUserPrincipal().getName()
RE: FormAuthentication
, Pranab [mailto:Pranab.Dhar@;DFA.STATE.NY.US]
Sent: Friday, October 25, 2002 11:47 AM
To: 'Cactus Users List'
Subject: RE: FormAuthentication
Hi Jason,
Yes Authentication works. I am using JBoss app server.
with user defined security realm/domain where all the users and roles are
mapped
using users.properties and roles.properties.I can run the servlet
straightaway and
I am asked to authenticate using a FormLogin.I have been able to set
security role-mapping
JSP/Servlets-to-EJB.I was trying to write test cases to test Servlet's &
EJB's with their
roles for which I need the JBoss App Server to authenticate and set up
Identity/Principal
and their roles.
Let me know how can I help.
Pranab
--
JBoss Security Realm login-config.xml:-
guest
--
Tomcat Security:-
SecurityRestriction
Protect the Cactus redirector
servlet.
/ServletRedirectorSecure
GET
POST
Authorized Users Group
idsconf_admin
idsconf_user
NONE
FORM
IDSCONF-REALM
/LoginForm.jsp
/LoginError.jsp
The Secure ROLE
idsconf_admin
The Non Secure ROLE
idsconf_user
--
J2EE application roles:-
.. app jars.
Administrator Role
idsconf_admin
User Role
idsconf_user
Internal Role
idsconf_internal
JBoss EJB Security mapping jboss.xml
java:jaas/IDSCONF-REALM
. entity/session beans jndi mapping
Standard Stateless
SessionBean
java:/jaas/IDSCONF-REALM
Standard BMP EntityBean
java:/jaas/IDSCONF-REALM
Unsecure Stateless
SessionBean
--
# A sample users.properties file for use with the UsersRolesLoginModule
# user=password
admin=admin
pkdhar=pkdhar
bob=bob
--
# A sample roles.properties file for use with the UsersRolesLoginModule
# user=role1,role2...
admin=idsconf_admin,idsconf_user
pkdhar=idsconf_user
bob=idsconf_user
-Original Message-
From: Robertson, Jason [mailto:Jason.Robertson@;acs-inc.com]
Sent: Friday, October 25, 2002 11:21 AM
To: 'Cactus Users List'
Subject: RE: FormAuthentication
Buried in the stack trace is "Failed to authenticate the principal". If you
try to log into the website normally using admin/admin does it work?
What server are you using? We have test cases that work with Tomcat and
WebLogic.
Jason
-Original Message-
From: Dhar, Pranab [mailto:Pranab.Dhar@;DFA.STATE.NY.US]
Sent: Friday, October 25, 2002 10:10 AM
To: '[EMAIL PROTECTED]'
Subject: FormAuthentication
Hi,
I am in a situation where I have EJB's and servlets created with security
roles defined.I need to test the Servlets and EJB's doing the authentication
in the process.I am using FormAuthentication for the secured
jsp/servlets/struts forms and actions.
I installed cactus 1.4.1 and found out that it does'nt implement form
authentication so I am now using the nightly build 20021022 after checking
the mailing list that some gentlemen have been adding this new feature.
My testcase is as follows:-
public void beginBasicAuthentication(WebRequest theRequest) {
theRequest.setURL("localhost:8080", "/", "/secure/idsconf",
null, null);
theRequest.addCookie( "test", "test" );
theRequest.setRedirectorName("ServletRedirectorSecure");
theRequest.setAuthentication(new FormAuthentication("admin",
"admin"));
}
public void testBasicAuthentication() {
assertEquals("admin",
request.getUserPrincipal().getName());
assertEquals("admin", request.getRemoteUser());
assertTrue("User not in 'admin' role",
request.isUserInRole("admin"));
}
I am getting this error when I run the test in Log4J DEBUG mode
-
18:00:12,899 [main] DEBUG ent.HttpClientConnectionHelper -
http://localhost:8080/ServletRedirector])
18:00
RE: FormAuthentication
Hi Jason,
Yes Authentication works. I am using JBoss app server.
with user defined security realm/domain where all the users and roles are
mapped
using users.properties and roles.properties.I can run the servlet
straightaway and
I am asked to authenticate using a FormLogin.I have been able to set
security role-mapping
JSP/Servlets-to-EJB.I was trying to write test cases to test Servlet's &
EJB's with their
roles for which I need the JBoss App Server to authenticate and set up
Identity/Principal
and their roles.
Let me know how can I help.
Pranab
--
JBoss Security Realm login-config.xml:-
guest
--
Tomcat Security:-
SecurityRestriction
Protect the Cactus redirector
servlet.
/ServletRedirectorSecure
GET
POST
Authorized Users Group
idsconf_admin
idsconf_user
NONE
FORM
IDSCONF-REALM
/LoginForm.jsp
/LoginError.jsp
The Secure ROLE
idsconf_admin
The Non Secure ROLE
idsconf_user
--
J2EE application roles:-
.. app jars.
Administrator Role
idsconf_admin
User Role
idsconf_user
Internal Role
idsconf_internal
JBoss EJB Security mapping jboss.xml
java:jaas/IDSCONF-REALM
. entity/session beans jndi mapping
Standard Stateless
SessionBean
java:/jaas/IDSCONF-REALM
Standard BMP EntityBean
java:/jaas/IDSCONF-REALM
Unsecure Stateless
SessionBean
--
# A sample users.properties file for use with the UsersRolesLoginModule
# user=password
admin=admin
pkdhar=pkdhar
bob=bob
--
# A sample roles.properties file for use with the UsersRolesLoginModule
# user=role1,role2...
admin=idsconf_admin,idsconf_user
pkdhar=idsconf_user
bob=idsconf_user
-Original Message-
From: Robertson, Jason [mailto:Jason.Robertson@;acs-inc.com]
Sent: Friday, October 25, 2002 11:21 AM
To: 'Cactus Users List'
Subject: RE: FormAuthentication
Buried in the stack trace is "Failed to authenticate the principal". If you
try to log into the website normally using admin/admin does it work?
What server are you using? We have test cases that work with Tomcat and
WebLogic.
Jason
-Original Message-
From: Dhar, Pranab [mailto:Pranab.Dhar@;DFA.STATE.NY.US]
Sent: Friday, October 25, 2002 10:10 AM
To: '[EMAIL PROTECTED]'
Subject: FormAuthentication
Hi,
I am in a situation where I have EJB's and servlets created with security
roles defined.I need to test the Servlets and EJB's doing the authentication
in the process.I am using FormAuthentication for the secured
jsp/servlets/struts forms and actions.
I installed cactus 1.4.1 and found out that it does'nt implement form
authentication so I am now using the nightly build 20021022 after checking
the mailing list that some gentlemen have been adding this new feature.
My testcase is as follows:-
public void beginBasicAuthentication(WebRequest theRequest) {
theRequest.setURL("localhost:8080", "/", "/secure/idsconf",
null, null);
theRequest.addCookie( "test", "test" );
theRequest.setRedirectorName("ServletRedirectorSecure");
theRequest.setAuthentication(new FormAuthentication("admin",
"admin"));
}
public void testBasicAuthentication() {
assertEquals("admin",
request.getUserPrincipal().getName());
assertEquals("admin", request.getRemoteUser());
assertTrue("User not in 'admin' role",
request.isUserInRole("admin"));
}
I am getting this error when I run the test in Log4J DEBUG mode
-
18:00:12,899 [main] DEBUG ent.HttpClientConnectionHelper -
http://localhost:8080/ServletRedirector])
18:00:12,899 [main] DEBUG ent.HttpClientConnectionHelper - >getCookieString
= [null]
18:00:13,891 [main] DEBUG ent.HttpClientConnectionHelper - >
RE: FormAuthentication
Buried in the stack trace is "Failed to authenticate the principal". If you
try to log into the website normally using admin/admin does it work?
What server are you using? We have test cases that work with Tomcat and
WebLogic.
Jason
-Original Message-
From: Dhar, Pranab [mailto:Pranab.Dhar@;DFA.STATE.NY.US]
Sent: Friday, October 25, 2002 10:10 AM
To: '[EMAIL PROTECTED]'
Subject: FormAuthentication
Hi,
I am in a situation where I have EJB's and servlets created with security
roles defined.I need to test the Servlets and EJB's doing the authentication
in the process.I am using FormAuthentication for the secured
jsp/servlets/struts forms and actions.
I installed cactus 1.4.1 and found out that it does'nt implement form
authentication so I am now using the nightly build 20021022 after checking
the mailing list that some gentlemen have been adding this new feature.
My testcase is as follows:-
public void beginBasicAuthentication(WebRequest theRequest) {
theRequest.setURL("localhost:8080", "/", "/secure/idsconf",
null, null);
theRequest.addCookie( "test", "test" );
theRequest.setRedirectorName("ServletRedirectorSecure");
theRequest.setAuthentication(new FormAuthentication("admin",
"admin"));
}
public void testBasicAuthentication() {
assertEquals("admin",
request.getUserPrincipal().getName());
assertEquals("admin", request.getRemoteUser());
assertTrue("User not in 'admin' role",
request.isUserInRole("admin"));
}
I am getting this error when I run the test in Log4J DEBUG mode
-
18:00:12,899 [main] DEBUG ent.HttpClientConnectionHelper -
http://localhost:8080/ServletRedirector])
18:00:12,899 [main] DEBUG ent.HttpClientConnectionHelper - >getCookieString
= [null]
18:00:13,891 [main] DEBUG ent.HttpClientConnectionHelper - >connect =
[org.apache.cactus.util.HttpURLConnection:http://localhost:8080/ServletRedir
ector]
18:00:13,901 [main] DEBUG util.HttpURLConnection -
getHeaderFieldKey = [Connection]
18:00:13,901 [main] DEBUG util.HttpURLConnection -
getHeaderFieldKey = [null]
18:00:13,901 [main] DEBUG hentication.FormAuthentication - Using security
check URL [http://localhost:8080/j_security_check]
18:00:13,901 [main] DEBUG client.ConnectionHelperFactory -
http://localhost:8080/j_security_check],
[org.apache.cactus.util.ServletConfiguration@1dff3a2])
18:00:13,901 [main] DEBUG client.ConnectionHelperFactory -
>getConnectionHelper =
[org.apache.cactus.client.HttpClientConnectionHelper@1d9fd51]
18:00:13,901 [main] DEBUG cactus.WebRequest -
printStackTrace
org.apache.cactus.util.ChainedRuntimeException: Failed to authenticate the
principal
at
org.apache.cactus.client.authentication.FormAuthentication.authenticate(Form
Authentication.java;org/apache/cactus/util/log/LogAspect.aj(1k):288)
at
org.apache.cactus.client.authentication.FormAuthentication.configure$ajcPost
Around13(FormAuthentication.java;org/apache/cactus/util/log/LogAspect.aj(1k)
:147)
at
org.apache.cactus.client.authentication.FormAuthentication.configure$ajcPost
Around13$ajcVoidWrapper(FormAuthentication.java;org/apache/cactus/util/log/L
ogAspect.aj(1k))
at
org.apache.cactus.client.authentication.FormAuthentication.configure(FormAut
hentication.java;org/apache/cactus/util/log/LogAspect.aj(1k):1151)
at
org.apache.cactus.client.HttpClientConnectionHelper.connect$ajcPostAround9(H
ttpClientConnectionHelper.java;org/apache/cactus/util/log/LogAspect.aj(1k):1
16)
at
org.apache.cactus.client.HttpClientConnectionHelper.connect(HttpClientConnec
tionHelper.java;org/apache/cactus/util/log/LogAspect.aj(1k):1222)
at
org.apache.cactus.client.AbstractHttpClient.callRunTest(AbstractHttpClient.j
ava;org/apache/cactus/util/log/LogAspect.aj(1k):200)
at
org.apache.cactus.client.AbstractHttpClient.doTest$ajcPostAround8(AbstractHt
tpClient.java;org/apache/cactus/util/log/LogAspect.aj(1k):124)
at
org.apache.cactus.client.AbstractHttpClient.doTest(AbstractHttpClient.java;o
rg/apache/cactus/util/log/LogAspect.aj(1k):1222)
at
org.apache.cactus.AbstractWebTestCase.runWebTest(AbstractWebTestCase.java:31
0)
at
org.apache.cactus.AbstractWebTestCase.runGenericTest(AbstractWebTestCase.jav
a:260)
at
org.apache.cactus.ServletTestCase.runTest(ServletTestCase.java:136)
at
org.apache.cactus.AbstractTestCase.runBare(AbstractTestCase.java:255)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
