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]
FormAuthentication problem
I'm working on switching our application from Basic to Form authentication.
I had Cactus working fine with:
request.setRedirectorName("ServletRedirectorSecure");
request.setAuthentication(new BasicAuthentication("user", "password");
I changed our web.xml from BASIC to FORM, switched the application, and that
all works fine. Cactus, however, fails when I change the above to:
request.setRedirectorName("ServletRedirectorSecure");
request.setAuthentication(new FormAuthentication("user", "password");
which should work according to
http://jakarta.apache.org/cactus/writing/howto_security.html
With BasicAuthentication, everything works fine and I get this in my access
log:
127.0.0.1 - user [29/Apr/2008:14:32:48 -0500] "GET
/application/ServletRedirectorSecure?Cactus_TestMethod=testMethod&Cactus_TestClass=com.company.TestClass&Cactus_AutomaticSession=true&Cactus_Service=CALL_TEST
HTTP/1.1" 200 -
127.0.0.1 - user [29/Apr/2008:14:32:48 -0500] "GET
/application/ServletRedirectorSecure?Cactus_Service=GET_RESULTS HTTP/1.1"
200 23
With FormAuthentication, I get "Missing service name parameter
[Cactus_Service] in HTTP request." and "Error getting test result. This
could happen for example if you're using a load-balancer." This is what I
see in my access log:
127.0.0.1 - - [29/Apr/2008:16:50:18 -0500] "GET
/application/ServletRedirectorSecure HTTP/1.1" 200 2357
127.0.0.1 - - [29/Apr/2008:16:50:18 -0500] "POST
/application/j_security_check HTTP/1.1" 302 -
127.0.0.1 - user [29/Apr/2008:16:50:18 -0500] "GET
/application/ServletRedirectorSecure HTTP/1.1" 500 2527
127.0.0.1 - user [29/Apr/2008:16:50:18 -0500] "GET
/application/ServletRedirectorSecure?Cactus_Service=GET_RESULTS HTTP/1.1"
500 2556
It seems to be losing the http parameters when I use form auth. Did
something change between the time the docs were written and now? Is there a
better FormAuthentication example?
Has anybody gotten FormAuthentication to work?
Thanks,
Eric
Re: negative testing with FormAuthentication
Hi Gabriel, In article <[EMAIL PROTECTED]>, Tue, 16 May 2006 17:04:14 -0400, Gabe <[EMAIL PROTECTED]> wrote: gabriel> I've been setting up a cactus test to test a web application gabriel> containers login. My test succeeds until I try a bad login. The gabriel> FormAuthentication throws a gabriel> "org.apache.cactus.util.ChainedRuntimeException: Failed to gabriel> authenticate the principal" exception. This is expected behavior. gabriel> The problem I can't wrap my head around is how is my test case gabriel> supposed to catch the exception? I put try catch blocks in the gabriel> beginXXX() and in the testXXX() methods and neither catch the gabriel> exception. I can understand what you want to do. However, you can not do it that way. The WebRequest instance is a container that maintains instructions to set the pre-test condition that should be tuned befor the testXXX() method is executed. After your begin() and beginXXX() methods provide the WebRequest instance, the client-side of the Cactus framework uses it to set the server-side pre-test condition for testXXX(). This means that the authentication would be performed AFTER the beginXXX() method. This is why you cannot catch the exception. gabriel> Right now the exception causes an error and makes the test fail. But gabriel> the login was supposed to fail. gabriel> gabriel> How should one test and assert a failed login using Cactus? HttpUnit or other functional testing frameworks would be appropriated. To test a failed login situation in Cactus world, you should consider how the behavior of the container is different between a request not authenticated and a request that failed to authenticate. # For unit testing, both may be considered as same, but I'm not sure. ## It may be depending on the container implementation. Regards, Kazuhito SUGURI - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: negative testing with FormAuthentication
Sorry, don't user cobertura. Wish I could be of help. On 5/24/06, Ryan <[EMAIL PROTECTED]> wrote: Gabe, I am sorry I can't answer your question. I don't understand why a Try/Catch wouldn't cath the exception. However, I have a question for you... Are you using any code coverage tools with your test? If so, are you using Cobertura? If not, need not to respond. Thanks and sorry, Ryan - 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: negative testing with FormAuthentication
Gabe, I am sorry I can't answer your question. I don't understand why a Try/Catch wouldn't cath the exception. However, I have a question for you... Are you using any code coverage tools with your test? If so, are you using Cobertura? If not, need not to respond. Thanks and sorry, Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
negative testing with FormAuthentication
Hi, I've been setting up a cactus test to test a web application containers login. My test succeeds until I try a bad login. The FormAuthentication throws a "org.apache.cactus.util.ChainedRuntimeException: Failed to authenticate the principal" exception. This is expected behavior. The problem I can't wrap my head around is how is my test case supposed to catch the exception? I put try catch blocks in the beginXXX() and in the testXXX() methods and neither catch the exception. Right now the exception causes an error and makes the test fail. But the login was supposed to fail. How should one test and assert a failed login using Cactus? Thanks, Gabriel - 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]
FormAuthentication
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]
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]
FormAuthentication and Error Code 500
Hi All,
I've just started using cactus and I am having a problem getting the
FormAuthentication working properly. I searched the web and mailing lists
already and couldn't find a solution.
My begin method for my test method "A" looks like:
public void beginA(WebRequest theRequest)
{
theRequest.setRedirectorName("ServletRedirectorSecure");
FormAuthentication fa = new FormAuthentication("0",
"qUqP5cyxm6YcTAhz05Hph5gvu9M=");
theRequest.setAuthentication(fa);
}
I can confirm that the ServletRedirectorSecure is configured as a secure
resource in my web.xml.
The problem I'm having is that I'm getting the following exception on the
client side when I try to run the test with the Cactus ant task (this is
pulled from the XML log generated by the task):
org.apache.commons.httpclient.HttpRecoverableException:
org.apache.commons.httpclient.HttpRecoverableException: Error in parsing the
status line from the response: unable to find line starting with
"HTTP"
at
org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.jav
a:1892)
The HTTP traffic is
1 - Cactus Request
GET /ServletRedirectorSecure? HTTP/1.1
Content-type: application/x-www-form-urlencoded
User-Agent: Jakarta Commons-HttpClient/2.0rc1
Host: localhost:8889
2 - OC4J Response
HTTP/1.1 200 OK
Date: Thu, 18 Nov 2004 10:43:46 GMT
Server: Oracle9iAS (9.0.3.0.0) Containers for J2EE
Content-Location:
http://localhost:8889/jsp/html/portlet/my_account/j_login.jsp
Set-Cookie: JSESSIONID=b3eabbf09d734b998c79d15602741b8c; Path=/
Connection: Close
Content-Type: text/html;charset=ISO-8859-1
Cache-Control: no-cache
Transfer-Encoding: chunked
3 - Cactus Request
POST /j_security_check? HTTP/1.1
Content-type: application/x-www-form-urlencoded
User-Agent: Jakarta Commons-HttpClient/2.0rc1
Host: localhost:8889
Cookie: $Version=0; JSESSIONID=b3eabbf09d734b998c79d15602741b8c
Content-Length: 54
j_username=0&j_password=qUqP5cyxm6YcTAhz05Hph5gvu9M%3D
4 - OC4J Response
HTTP/1.1 100 Continue
Server: Oracle9iAS (9.0.3.0.0) Containers for J2EE
Date: Thu, 18 Nov 2004 10:43:47 GMT
The HTTP traffic would suggest that the authentication has been successful
but cactus doesn't get a response that it expects.
Any help would be greatly appreciated,
Thanks,
Setanta Mathews.
P.S. The full stack trace of the exception is:
org.apache.cactus.util.ChainedRuntimeException: Failed to authenticate the
principal
at
org.apache.cactus.client.authentication.FormAuthentication.authenticate_arou
ndBody10(FormAuthentication.java:383)
at
org.apache.cactus.client.authentication.FormAuthentication.authenticate_arou
ndBody11$advice(FormAuthentication.java:117)
at
org.apache.cactus.client.authentication.FormAuthentication.authenticate(Form
Authentication.java)
at
org.apache.cactus.client.authentication.FormAuthentication.configure_aroundB
ody0(FormAuthentication.java:105)
at
org.apache.cactus.client.authentication.FormAuthentication.configure_aroundB
ody1$advice(FormAuthentication.java:117)
at
org.apache.cactus.client.authentication.FormAuthentication.configure(FormAut
hentication.java)
at
org.apache.cactus.internal.client.connector.http.HttpClientConnectionHelper.
connect_aroundBody0(HttpClientConnectionHelper.java:103)
at
org.apache.cactus.internal.client.connector.http.HttpClientConnectionHelper.
connect_aroundBody1$advice(HttpClientConnectionHelper.java:188)
at
org.apache.cactus.internal.client.connector.http.HttpClientConnectionHelper.
connect(HttpClientConnectionHelper.java)
at
org.apache.cactus.internal.client.connector.http.DefaultHttpClient.callRunTe
st(DefaultHttpClient.java:162)
at
org.apache.cactus.internal.client.connector.http.DefaultHttpClient.doTest_ar
oundBody0(DefaultHttpClient.java:80)
at
org.apache.cactus.internal.client.connector.http.DefaultHttpClient.doTest_ar
oundBody1$advice(DefaultHttpClient.java:188)
at
org.apache.cactus.internal.client.connector.http.DefaultHttpClient.doTest(De
faultHttpClient.java)
at
org.apache.cactus.internal.client.connector.http.HttpProtocolHandler.runWebT
est(HttpProtocolHandler.java:159)
at
org.apache.cactus.internal.client.connector.http.HttpProtocolHandler.runTest
_aroundBody0(HttpProtocolHandler.java:80)
at
org.apache.cactus.internal.client.connector.http.HttpProtocolHandler.runTest
_aroundBody1$advice(HttpProtocolHandler.java:188)
at
org.apache.cactus.internal.client.connector.http.HttpProtocolHandler.runTest
(HttpProtocolHandler.java)
at
org.apache.cactus.internal.client.ClientTestCaseCaller.runTest(ClientTestCas
eCaller.java:144)
at
org.apache.cactus.internal.AbstractCactusTestCase.runBareClient(AbstractCact
usTestCase.java:215)
Antwort: Re: Antwort: Re: Security (using FormAuthentication) not working against WebSphere 5.1
Hi,
as you mentioned in your answer I first tried to find out wether WebSphere
is sending the cookie JSessionID in
step 4) or 6).
After requesting the Login-Page from a browser and requesting
javascript:alert(document.cookie)
before authentication I found out WebSphere 5.1 is sending SessionID-Cookie
in step 4).
The cookie is shown in the alert window.
Then I changed the implementation of method getSecureSessionIdCookie(...)
like this
###
private Cookie getSecureSessionIdCookie(WebRequest theRequest,
Configuration theConfiguration)
{
HttpURLConnection connection;
String resource = null;
Cookie cookie = null;
try
{
// Create a helper that will connect to a restricted resource.
WebConfiguration webConfig = (WebConfiguration)
theConfiguration;
resource = webConfig.getRedirectorURL(theRequest);
HttpClientConnectionHelper helper =
new HttpClientConnectionHelper(resource);
WebRequest request =
new WebRequestImpl((WebConfiguration) theConfiguration);
// Make the connection using a default web request.
connection = helper.connect(request, theConfiguration);
checkPreAuthResponse(connection);
cookie = getCookie(connection, getSessionCookieName());
if (cookie == null) {
String loginURL = getLoginURL(connection);
HttpClientConnectionHelper helper2 =
new HttpClientConnectionHelper(loginURL);
connection = helper2.connect(request, theConfiguration);
cookie = getCookie(connection, getSessionCookieName());
} // end if
}
catch (Throwable e)
{
throw new ChainedRuntimeException(
"Failed to connect to the secured redirector: " + resource,
e);
}
return cookie;
}
public String getLoginURL(HttpURLConnection connection) {
String locationHeaderKey = "Location";
String loginURL = null;
// TODO
return
"http://mmwasint.mn-man.biz:8085/mandeploymantwebapp/jsp/LoginForm.jsp";;
}
###
The cookie is found and gets stored for the next request.
Now I get the exception "Failed to get test results at
[http:/.../ServletRedirectorSecure]".
I will try to find the reason on friday. Its already too late.
Kids are waiting ...
Thanks,
Toni
---
Anton Grimm
MAN Nutzfahrzeuge AG
IDP - Software Produktionsumgebungen
Dachauerstr.667
D - 80995 München
Fon: +49-89-1580-1054
Fax: +49-89-1580-4550
mailto:[EMAIL PROTECTED]
Internet: http://www.man-trucks.com
---
|-+--->
| | Kazuhito SUGURI |
| | <[EMAIL PROTECTED]|
| | .ntt.co.jp> |
| | |
| | 06/08/2004 05:14 PM |
| | Bitte antworten an |
| | "Cactus Users List" |
| | |
|-+--->
>--|
|
|
| An: [EMAIL PROTECTED], [EMAIL PROTECTED]
|
| Kopie:
|
| Thema:Re: Antwort: Re: Security (using FormAuthentication) not working
against WebSphere 5.1 |
>--|
Hi,
In article
<[EMAIL PROTECTED]>,
Tue, 8 Jun 2004 14:42:53 +0200,
[EMAIL PROTECTED] wrote:
Anton_Grimm> Do you think it is the right place to change the
implementation of the
Anton_Grimm> method
Anton_Grimm> getSecureSessionIdCookie()
Anton_Grimm> in FormAuthentication to include step3) and step4) if no
cookie is found in
Anton_Grimm> step 2) ?
Yes, I think so.
But, we have no data yet.
I'm wondering if WAS is sending Set-Cookie JSESSIONID header
only for successfully authenticated user, i.e. at step (6).
# if the session tracking can be started at step(4), why cannot at
step(6)...
Please let us know when you find a new fact.
Regards,
Kazuhito SUGURI
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTEC
Re: Antwort: Re: Security (using FormAuthentication) not working against WebSphere 5.1
Hi, In article <[EMAIL PROTECTED]>, Tue, 8 Jun 2004 14:42:53 +0200, [EMAIL PROTECTED] wrote: Anton_Grimm> Do you think it is the right place to change the implementation of the Anton_Grimm> method Anton_Grimm> getSecureSessionIdCookie() Anton_Grimm> in FormAuthentication to include step3) and step4) if no cookie is found in Anton_Grimm> step 2) ? Yes, I think so. But, we have no data yet. I'm wondering if WAS is sending Set-Cookie JSESSIONID header only for successfully authenticated user, i.e. at step (6). # if the session tracking can be started at step(4), why cannot at step(6)... Please let us know when you find a new fact. Regards, Kazuhito SUGURI mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: Re: Security (using FormAuthentication) not working against WebSphere 5.1
Thanks for your explanations! As I am not at all familiar with any packet capture tool I need some help of my collegues. We try this in the late afternoon ... Do you think it is the right place to change the implementation of the method getSecureSessionIdCookie() in FormAuthentication to include step3) and step4) if no cookie is found in step 2) ? Regards, 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-4550 mailto:[EMAIL PROTECTED] Internet: http://www.man-trucks.com --- |-+---> | | Kazuhito SUGURI | | | <[EMAIL PROTECTED]| | | .ntt.co.jp> | | | | | | 06/08/2004 10:34 AM | | | Bitte antworten an | | | "Cactus Users List" | | | | |-+---> >--| | | | An: [EMAIL PROTECTED] | | Kopie: | | Thema:Re: Security (using FormAuthentication) not working against WebSphere 5.1| >--| Hi, In article <[EMAIL PROTECTED]>, Tue, 8 Jun 2004 09:35:31 +0200, [EMAIL PROTECTED] wrote: Anton_Grimm> When I run our suite against WebSphere 5.1.0.4 the tests using Anton_Grimm> FormAuthentication fail reporting Anton_Grimm> Anton_Grimm> "Failed to authenticate the principal." [snip] Anton_Grimm> ### WebSphere ### Anton_Grimm> Anton_Grimm> getCookie(theConnection, theTarget) - Header: null:HTTP/1.1 302 Found Anton_Grimm> getCookie(theConnection, theTarget) - Header: Date:Tue, 08 Jun 2004 Anton_Grimm> 06:24:12 GMT Anton_Grimm> getCookie(theConnection, theTarget) - Header: Anton_Grimm> Server:IBM_HTTP_Server/2.0.47-PQ84017 Apache/2.0.47 (Unix) DAV/2 Anton_Grimm> getCookie(theConnection, theTarget) - Header: Anton_Grimm> Set-Cookie:WASReqURL=http://mmwasint.mn-man.biz:8085/mandeploymantwebapp/ServletRedirectorSecure?;Path=/ Anton_Grimm> getCookie(theConnection, theTarget) - Header: Anton_Grimm> Cache-Control:no-cache="set-cookie,set-cookie2" Anton_Grimm> getCookie(theConnection, theTarget) - Header: Expires:Thu, 01 Dec 1994 Anton_Grimm> 16:00:00 GMT Anton_Grimm> getCookie(theConnection, theTarget) - Header: Anton_Grimm> Location: http://mmwasint.mn-man.biz:8085/mandeploymantwebapp/jsp/LoginForm.jsp Anton_Grimm> getCookie(theConnection, theTarget) - Header: Content-Length:0 Anton_Grimm> getCookie(theConnection, theTarget) - Header: Content-Type:text/html; Anton_Grimm> charset=ISO-8859-1 Anton_Grimm> getCookie(theConnection, theTarget) - Header: Content-Language:en-US [snip] Anton_Grimm> Anyway, when I request the Url (against WebSphere) Anton_Grimm> http://hostname:port/context/ServletRedirectoSecure? Anton_Grimm> I get forwarded to the login-page. Anton_Grimm> Anton_Grimm> Before submitting the Login-Page I request Anton_Grimm> javascript:alert(document.cookie) Anton_Grimm> and I get two cookies (WASReqURL and JSESSIONID). WebSphere may set a Set-Cookie header for JSESSIONID in the response for the login-page, which will not be accessed by FormAuthentication implementation. Could you trace HTTP messages for the following sequence by using packet cature tool? (1) C->S request the URL http://hostname:port/context/ServletRedirectoSecure? (2) S->C 302 response (3) C->S request the login-page (4) S->C 200 response with login-page (5) C->S request j_security_check with username, password and JSESSIONID Current implementation of the FormAuthentication class is assuming that a Set-Cookie header for JSESSIONID exists in a response at (2). Then, the FormAuthentication class does not perform (3)-(4), but perfoms (5) immediately. However, it's possible for AP server to start session tracking from the first login-page request (3), and for that case, AP server may send the Set-Cookie header for JSESSIONID at (4). Regards, Kazuhito SUGURI mailto:[EMAIL PROTECTED]
Re: Security (using FormAuthentication) not working against WebSphere 5.1
Hi, In article <[EMAIL PROTECTED]>, Tue, 8 Jun 2004 09:35:31 +0200, [EMAIL PROTECTED] wrote: Anton_Grimm> When I run our suite against WebSphere 5.1.0.4 the tests using Anton_Grimm> FormAuthentication fail reporting Anton_Grimm> Anton_Grimm> "Failed to authenticate the principal." [snip] Anton_Grimm> ### WebSphere ### Anton_Grimm> Anton_Grimm> getCookie(theConnection, theTarget) - Header: null:HTTP/1.1 302 Found Anton_Grimm> getCookie(theConnection, theTarget) - Header: Date:Tue, 08 Jun 2004 Anton_Grimm> 06:24:12 GMT Anton_Grimm> getCookie(theConnection, theTarget) - Header: Anton_Grimm> Server:IBM_HTTP_Server/2.0.47-PQ84017 Apache/2.0.47 (Unix) DAV/2 Anton_Grimm> getCookie(theConnection, theTarget) - Header: Anton_Grimm> Set-Cookie:WASReqURL=http://mmwasint.mn-man.biz:8085/mandeploymantwebapp/ServletRedirectorSecure?;Path=/ Anton_Grimm> getCookie(theConnection, theTarget) - Header: Anton_Grimm> Cache-Control:no-cache="set-cookie,set-cookie2" Anton_Grimm> getCookie(theConnection, theTarget) - Header: Expires:Thu, 01 Dec 1994 Anton_Grimm> 16:00:00 GMT Anton_Grimm> getCookie(theConnection, theTarget) - Header: Anton_Grimm> Location:http://mmwasint.mn-man.biz:8085/mandeploymantwebapp/jsp/LoginForm.jsp Anton_Grimm> getCookie(theConnection, theTarget) - Header: Content-Length:0 Anton_Grimm> getCookie(theConnection, theTarget) - Header: Content-Type:text/html; Anton_Grimm> charset=ISO-8859-1 Anton_Grimm> getCookie(theConnection, theTarget) - Header: Content-Language:en-US [snip] Anton_Grimm> Anyway, when I request the Url (against WebSphere) Anton_Grimm> http://hostname:port/context/ServletRedirectoSecure? Anton_Grimm> I get forwarded to the login-page. Anton_Grimm> Anton_Grimm> Before submitting the Login-Page I request Anton_Grimm> javascript:alert(document.cookie) Anton_Grimm> and I get two cookies (WASReqURL and JSESSIONID). WebSphere may set a Set-Cookie header for JSESSIONID in the response for the login-page, which will not be accessed by FormAuthentication implementation. Could you trace HTTP messages for the following sequence by using packet cature tool? (1) C->S request the URL http://hostname:port/context/ServletRedirectoSecure? (2) S->C 302 response (3) C->S request the login-page (4) S->C 200 response with login-page (5) C->S request j_security_check with username, password and JSESSIONID Current implementation of the FormAuthentication class is assuming that a Set-Cookie header for JSESSIONID exists in a response at (2). Then, the FormAuthentication class does not perform (3)-(4), but perfoms (5) immediately. However, it's possible for AP server to start session tracking from the first login-page request (3), and for that case, AP server may send the Set-Cookie header for JSESSIONID at (4). Regards, Kazuhito SUGURI mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Security (using FormAuthentication) not working against WebSphere 5.1
We are running our test on the workstation (using WebSphere Studio) against Tomcat 4.1.29 which works fine even for secured Urls (using FormAuthentication). When I run our suite against WebSphere 5.1.0.4 the tests using FormAuthentication fail reporting "Failed to authenticate the principal." Logging the Header-Keys in method getCookie() of the class FormAuthentication I can see different results against Tomcat / WebSphere ... There is no session-cookie jsessionid in the WebSphere headers and Cache-Control is set to no-cache="set-cookie,set-cookie2". ### Tomcat ### getCookie(theConnection, theTarget) - Header: null:HTTP/1.1 302 Moved Temporarily getCookie(theConnection, theTarget) - Header: Pragma:No-cache getCookie(theConnection, theTarget) - Header: Cache-Control:no-cache getCookie(theConnection, theTarget) - Header: Expires:Thu, 01 Jan 1970 00:00:00 GMT getCookie(theConnection, theTarget) - Header: Set-Cookie:JSESSIONID=4B109CE76EE490AABB3E1E4B0F23EA67; Path=/mandeploymantwebapp getCookie(theConnection, theTarget) - Header: Location:http://localhost:8080/mandeploymantwebapp/jsp/LoginForm.jsp;jsessionid=4B109CE76EE490AABB3E1E4B0F23EA67 getCookie(theConnection, theTarget) - Header: Content-Length:0 getCookie(theConnection, theTarget) - Header: Date:Tue, 08 Jun 2004 06:50:05 GMT getCookie(theConnection, theTarget) - Header: Server:Apache-Coyote/1.1 ### ### WebSphere ### getCookie(theConnection, theTarget) - Header: null:HTTP/1.1 302 Found getCookie(theConnection, theTarget) - Header: Date:Tue, 08 Jun 2004 06:24:12 GMT getCookie(theConnection, theTarget) - Header: Server:IBM_HTTP_Server/2.0.47-PQ84017 Apache/2.0.47 (Unix) DAV/2 getCookie(theConnection, theTarget) - Header: Set-Cookie:WASReqURL=http://mmwasint.mn-man.biz:8085/mandeploymantwebapp/ServletRedirectorSecure?;Path=/ getCookie(theConnection, theTarget) - Header: Cache-Control:no-cache="set-cookie,set-cookie2" getCookie(theConnection, theTarget) - Header: Expires:Thu, 01 Dec 1994 16:00:00 GMT getCookie(theConnection, theTarget) - Header: Location:http://mmwasint.mn-man.biz:8085/mandeploymantwebapp/jsp/LoginForm.jsp getCookie(theConnection, theTarget) - Header: Content-Length:0 getCookie(theConnection, theTarget) - Header: Content-Type:text/html; charset=ISO-8859-1 getCookie(theConnection, theTarget) - Header: Content-Language:en-US ### Anyway, when I request the Url (against WebSphere) http://hostname:port/context/ServletRedirectoSecure? I get forwarded to the login-page. Before submitting the Login-Page I request javascript:alert(document.cookie) and I get two cookies (WASReqURL and JSESSIONID). Can anybody please explain the different behaviour or point me in the right direction ... Thanks a lot 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-4550 mailto:[EMAIL PROTECTED] Internet: http://www.man-trucks.com --- 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]
FormAuthentication error
According to document "http://jakarta.apache.org/cactus/writing/howto_security.html";,
i've tried to do my application
works with cactus + security. But i always catch the same error:
[junit] Testcase: testFormAuthentication took 3,803 sec
[junit] Caused an ERROR
[junit] Failed to get the test results at
[http://felicia:7080/icaro/ServletRedirectorSecure]
[junit] org.apache.cactus.util.ChainedRuntimeException: Failed to get the test
results at [http:
//felicia:7080/icaro/ServletRedirectorSecure]
[junit] at
org.apache.cactus.client.connector.http.DefaultHttpClient.doTest_aroundBody0(Defa
ultHttpClient.java:131)
...
..
.
[junit] org.apache.cactus.client.ParsingException: Not a valid response [302 Moved
Temporarily]
...
..
.
[junit] Testcase: testFormAuthentication
[junit] TEST com.da.motion.infoAdmUserAdm.web.teste.TestLogin FAILED
Some help ?
++
My files and configurations are :
++
My class :
public class TestLogin extends TesteWebRoot
{
public TestLogin(String name)
{
super(name);
}
public void beginFormAuthentication(WebRequest theRequest) throws Exception
{
theRequest.setRedirectorName("ServletRedirectorSecure");
theRequest.setAuthentication(new FormAuthentication("root", "senha"));
}
public void testFormAuthentication() throws Exception
{
// not reach
System.out.println("Milagre !!!");
}
}
++
My web.xml file :
http://java.sun.com/j2ee/dtds/web-app_2_3.dtd";>
Seguranca
com.da.motion.geralComum.web.filter.WLSecurityFilter
Seguranca
/*
com.da.motion.geralComum.web.classe.MotionWebListener
action
org.apache.struts.action.ActionServlet
application
MotionWebResources
config
/WEB-INF/struts-config.xml
debug
2
detail
2
validate
true
useTokenByPass
true
2
ServletRedirector
org.apache.cactus.server.ServletTestRedirector
ServletRedirectorSecure
org.apache.cactus.server.ServletTestRedirector
ServletTestRunner
org.apache.cactus.server.runner.ServletTestRunner
action
*.do
ServletRedirector
/ServletRedirector
ServletRedirectorSecure
/ServletRedirectorSecure
ServletTestRunner
/ServletTestRunner
index.jsp
500
/com/da/motion/geralComum/web/jsp/erro.jsp
400
/login.do
MotionLogin
Página de Login
/login.do
logado
NONE
SecurityRestriction
Protect the Cactus redirector servlet.
/ServletRedirectorSecure
GET
POST
logado
NONE
FORM
MotionSecurityRealm
/logon.jsp
/logon.jsp
Todos os usuários logados do sistema
logado
++
My tomcat-users.xml file :
Thanks,
Icaro Tuicci
"Aprenda a viver contente em toda e qualquer situação" Filipenses 4:11
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: Login once using (FormAuthentication) for all tests in a class
On Jan 8, 2004, at 7:05 AM, Vincent Massol wrote:
So the question is - is it possible to combine the following 2
methods?
public void begin(WebRequest request) {
request.setRedirectorName("ServletRedirectorSecure");
request.setAuthentication(new FormAuthentication(
login.getString("username"),
login.getString("encryptedPassword")));
}
public void setUp() throws Exception {
super.setUp();
conn = ServiceLocator.getConnection();
// populate the userForm and place into session
String username = login.getString("username");
UserManager userMgr = new UserManagerImpl(conn);
userForm = (UserForm) userMgr.getUser(username);
session.setAttribute(Constants.USER_KEY, userForm);
}
I don't think so. The begin method is used to connect to the server
side, whereas the setup is used to set up server side objects. They are
executed in different JVM (client and server side).
Thanks
-Vincent
Cool - just wanted to clarify I'm doing it right. After using the
begin() and setUp() - I seem to like that better, then I can override
begin() as needed in subclass - for instance, to cancel form
authentication with an empty method.
Thanks,
Matt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Login once using (FormAuthentication) for all tests in a class
Matt,
> -Original Message-
> From: Matt Raible [mailto:[EMAIL PROTECTED]
> Sent: 08 January 2004 14:21
> To: Cactus Users List
> Subject: Re: Login once using (FormAuthentication) for all tests in a
> class
>
> > 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.
> >
>
> Ah ha - the begin() method is exactly what I was looking for. Of
> course, I'd prefer to use setUp() because then my test looks more like
> JUnit than Cactus (making it easier to understand for those familiar
> with JUnit). However, I'm unsure of how to get the WebRequest (in
> order to set authorization) in the setUp() method.
begin() is executed on the client side and setUp() on the server side.
Thus setup cannot have access to the WebRequest. However it has access
to the HttpServletRequest and other container objects.
>
> I tried removing all my beginXX() methods and just using one begin()
> method and this worked great - thanks!
>
> So the question is - is it possible to combine the following 2
methods?
>
> public void begin(WebRequest request) {
> request.setRedirectorName("ServletRedirectorSecure");
> request.setAuthentication(new FormAuthentication(
> login.getString("username"),
> login.getString("encryptedPassword")));
> }
>
> public void setUp() throws Exception {
> super.setUp();
>
> conn = ServiceLocator.getConnection();
> // populate the userForm and place into session
> String username = login.getString("username");
> UserManager userMgr = new UserManagerImpl(conn);
> userForm = (UserForm) userMgr.getUser(username);
> session.setAttribute(Constants.USER_KEY, userForm);
> }
>
I don't think so. The begin method is used to connect to the server
side, whereas the setup is used to set up server side objects. They are
executed in different JVM (client and server side).
Thanks
-Vincent
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Login once using (FormAuthentication) for all tests in a class
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.
Ah ha - the begin() method is exactly what I was looking for. Of
course, I'd prefer to use setUp() because then my test looks more like
JUnit than Cactus (making it easier to understand for those familiar
with JUnit). However, I'm unsure of how to get the WebRequest (in
order to set authorization) in the setUp() method.
I tried removing all my beginXX() methods and just using one begin()
method and this worked great - thanks!
So the question is - is it possible to combine the following 2 methods?
public void begin(WebRequest request) {
request.setRedirectorName("ServletRedirectorSecure");
request.setAuthentication(new FormAuthentication(
login.getString("username"),
login.getString("encryptedPassword")));
}
public void setUp() throws Exception {
super.setUp();
conn = ServiceLocator.getConnection();
// populate the userForm and place into session
String username = login.getString("username");
UserManager userMgr = new UserManagerImpl(conn);
userForm = (UserForm) userMgr.getUser(username);
session.setAttribute(Constants.USER_KEY, userForm);
}
Matt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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]
RE: Login once using (FormAuthentication) for all tests in a class
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]
RE: Login once using (FormAuthentication) for all tests in a class
> -Original Message-
> From: Matt Raible [mailto:[EMAIL PROTECTED]
> Sent: 08 January 2004 01:48
> To: Cactus Users List
> Subject: Re: Login once using (FormAuthentication) for all tests in a
> class
>
> A visual might be better. In my BaseStrutsTestCase class I have a
> login method that is designed so all subclasses can use it.
>
>
> public void login(WebRequest request) {
> request.setRedirectorName("ServletRedirectorSecure");
> request.setAuthentication(new FormAuthentication(
> login.getString("username"),
> login.getString("encryptedPassword")));
> }
>
> And in my ContactActionTest, I have to login for each method - below
is
> a trimmed down version of all my begin/test methods:
>
> public void beginEdit(WebRequest wr) { login(wr); }
>
> public void testEdit() throws Exception {
> ...
> }
>
> public void beginSave(WebRequest wr) { login(wr); }
>
> public void testSave() throws Exception {
> ...
> }
>
> public void beginSearch(WebRequest wr) { login(wr); }
>
> public void testSearch() throws Exception {
> ...
> }
>
> public void beginDisplayContactsForPosition(WebRequest wr) {
> login(wr); }
>
> public void testDisplayContactsForPosition() throws Exception {
> ...
> }
>
> public void beginPostJobs(WebRequest wr) { login(wr); }
>
> public void testPostJobs() throws Exception {
> ...
> }
>
> public void beginRemove(WebRequest wr) { login(wr); }
>
> public void testRemove() throws Exception {
>
> }
>
> I'd like to get rid of all the beginXX methods, or a confirmation that
> this is the easiest way to do this.
Why not use the global begin(WebRequest) method (or setUp() on the
server side)?
Thanks
-Vincent
>
> Thanks,
>
> Matt
>
> On Jan 7, 2004, at 5:21 PM, Matt Raible wrote:
>
> > Quick and dirty question:
> >
> > Is it possible to login once (using FormAuthentication) for a class,
> > rather than adding a beginXXTestName befor every testXXTestName
> > method?
> >
> > 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)?
> >
> > Thanks,
> >
> > Matt
> >
> >
> >
> >
> >
> >
> >
-
> > 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: Login once using (FormAuthentication) for all tests in a class
A visual might be better. In my BaseStrutsTestCase class I have a
login method that is designed so all subclasses can use it.
public void login(WebRequest request) {
request.setRedirectorName("ServletRedirectorSecure");
request.setAuthentication(new FormAuthentication(
login.getString("username"),
login.getString("encryptedPassword")));
}
And in my ContactActionTest, I have to login for each method - below is
a trimmed down version of all my begin/test methods:
public void beginEdit(WebRequest wr) { login(wr); }
public void testEdit() throws Exception {
...
}
public void beginSave(WebRequest wr) { login(wr); }
public void testSave() throws Exception {
...
}
public void beginSearch(WebRequest wr) { login(wr); }
public void testSearch() throws Exception {
...
}
public void beginDisplayContactsForPosition(WebRequest wr) {
login(wr); }
public void testDisplayContactsForPosition() throws Exception {
...
}
public void beginPostJobs(WebRequest wr) { login(wr); }
public void testPostJobs() throws Exception {
...
}
public void beginRemove(WebRequest wr) { login(wr); }
public void testRemove() throws Exception {
}
I'd like to get rid of all the beginXX methods, or a confirmation that
this is the easiest way to do this.
Thanks,
Matt
On Jan 7, 2004, at 5:21 PM, Matt Raible wrote:
Quick and dirty question:
Is it possible to login once (using FormAuthentication) for a class,
rather than adding a beginXXTestName befor every testXXTestName
method?
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)?
Thanks,
Matt
-
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]
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? 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)? Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bug17933: FormAuthentication with machine name
Has anybody already fixed this bug and would be pleasant enough and support the source file? Maybe Karthik Guru already did as he mentioned in earlier messages. We have configured SingleSignOn-Domain in WebSphere 5.0 and therefore need to specify a fully qualified domain-name in cactus-properties for authentication to be accepted by WebSphere. Help is very much appreciated. Regards, 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 --- 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]
RE: Regarding BUG: 17933 (FormAuthentication assumes "localhost" when adding cookies )
Hi Karthik,
Thanks for helping us. You shouldn't use the setURL() method as it is
used to set a simulation URL (not a real one). The Configuration
interface only provides a getContextURL() method that will return
something of the form:
http://servername:port/contextname
What is the domain name? Is it the servername:port part? In any case,
one good option to extract it is to use the URL class. Something like:
URL url = new URL(theConfiguration.getContextURL());
String domainname = url.getHost();
Thanks
-Vincent
> -Original Message-
> From: karthik Guru [mailto:[EMAIL PROTECTED]
> Sent: 01 August 2003 15:11
> To: Cactus Users List
> Subject: Regarding BUG: 17933 (FormAuthentication assumes "localhost"
when
> adding cookies )
>
>
> Hi,
>
> This is regarding the bug listed here.
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=17933
>
> I was trying to fix it .
>
> File: FormAuthentication.java
> Method:
>
> public void configure(WebRequest theRequest,
> Configuration theConfiguration);
>
>
> I guess i can get the context URL set in the
> cactus.properties file this way
> String contextURL = theConfiguration.getContextURL();
>
> Now can i do a substring operation to extract the
> domain name from the context URL and call
>
> theRequest.addCookie(domainName,this.sessionIdCookieName,
> this.sessionId);
>
> I mean does cactus have some utility methods /
> something that knows how to extract the domain name
> properly from the contextURL?
>
> I just want to make sure that i'm doing the right
> thing in a right way.
>
> I guess we can also do
>
> webRequest.setURL() when using FormAuthentication;
>
> if that is the case, i guess , I can extract the
> domain/host name using ServletURL.getHost()
>
> So what s'd i be doing in the implementation
> FormAuthentication::configure()?
>
> 1. Do substring on contextURL OR
> 2. ServletURL.getHost()
>
> OR try doing 1) and if it fails do 2)
>
> Hope am not bugging the cactus commiters too much
> here.
>
> thanks,
> karthik
>
> --- Sachin <[EMAIL PROTECTED]> wrote:
> > Hi All,
> > I am trying to write TestCase of example
> > Specified in StrutsTestCase
> > which says that we can use both CactusStrutsTestCase
> > or MockStrutsTestCase..
> >
> > But when i am trying to run it it is giving error
> > like this..
> >
> >
> > [main] INFO util.PropertyMessageResources -
> > Initializing,
> > config='org.apache.struts.util.LocalStrings',
> > returnNull=true
> > [main] INFO util.PropertyMessageResources -
> > Initializing,
> > config='org.apache.struts.action.ActionResources',
> > returnNull=true
> >
> > Time: 0.625
> > There was 1 failure:
> > 1)
> >
>
testAction(logic.struts.actions.TestFirstAction)junit.framework.Assertio
nF
> ai
> > ledError: Error running action.perform(): class
> > java.lang.NullPointerException - null
> > at
> >
>
servletunit.struts.MockStrutsTestCase.actionPerform(MockStrutsTestCase.j
av
> a:
> > 339)
> > at
> >
>
logic.struts.actions.TestFirstAction.testAction(TestFirstAction.java:47)
> > at
> > sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> > Method)
> > at
> >
>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:
> 39
> > )
> > at
> >
>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Im
> pl
> > .java:25)
> > at
> >
>
com.intellij.rt.execution.junit.TextTestRunner.main(TextTestRunner.java:
12
> )
> >
> > FAILURES!!!
> > Tests run: 1, Failures: 1, Errors: 0
> >
> > Process terminated with exit code -1
> >
> >
> >
> >
> > My Code is
> >
> >
> > package logic.struts.actions;
> >
> > import servletunit.struts.MockStrutsTestCase;
> > import servletunit.struts.CactusStrutsTestCase;
> >
> > import javax.servlet.ServletException;
> >
> > public class TestFirstAction extends
> > MockStrutsTestCase{
> >
> > public TestFirstAction(String testName) {
> > super(testName); }
> >
> > public void testAction() {
> >setRequestPathInfo("/firstAction");
> >actionPerform();
> >verifyForward("second");
> > }
> >
> > public void setUp() throws Exception {
> > super.setUp();
> > }
> >
> > protected void tearDown() throws Exception {
> > super.tearDown();
> > }
> >
> > }
> >
> >
> >
> >
> >
> -
> > To unsubscribe, e-mail:
> > [EMAIL PROTECTED]
> > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> >
>
>
> __
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Regarding BUG: 17933 (FormAuthentication assumes "localhost" when adding cookies )
Hi Karthik,
What about problem i have posted.Well Actually i have just start
learning on Cactus>now i am trying to do some practical work.test Which
Cactus Provide is working fine With browser.
but When For Struts We write a simple testCase..Why i amn getting Error.i am
sp desperate to know that where i am wrong??
Can any one Suggest..Where i am wrong Because i am not thinking That It is
such a big testCase..
Thanks
Sachin
-Original Message-
From: karthik Guru [mailto:[EMAIL PROTECTED]
Sent: Friday, August 01, 2003 6:41 PM
To: Cactus Users List
Subject: Regarding BUG: 17933 (FormAuthentication assumes "localhost"
when adding cookies )
Hi,
This is regarding the bug listed here.
http://issues.apache.org/bugzilla/show_bug.cgi?id=17933
I was trying to fix it .
File: FormAuthentication.java
Method:
public void configure(WebRequest theRequest,
Configuration theConfiguration);
I guess i can get the context URL set in the
cactus.properties file this way
String contextURL = theConfiguration.getContextURL();
Now can i do a substring operation to extract the
domain name from the context URL and call
theRequest.addCookie(domainName,this.sessionIdCookieName,
this.sessionId);
I mean does cactus have some utility methods /
something that knows how to extract the domain name
properly from the contextURL?
I just want to make sure that i'm doing the right
thing in a right way.
I guess we can also do
webRequest.setURL() when using FormAuthentication;
if that is the case, i guess , I can extract the
domain/host name using ServletURL.getHost()
So what s'd i be doing in the implementation
FormAuthentication::configure()?
1. Do substring on contextURL OR
2. ServletURL.getHost()
OR try doing 1) and if it fails do 2)
Hope am not bugging the cactus commiters too much
here.
thanks,
karthik
--- Sachin <[EMAIL PROTECTED]> wrote:
> Hi All,
> I am trying to write TestCase of example
> Specified in StrutsTestCase
> which says that we can use both CactusStrutsTestCase
> or MockStrutsTestCase..
>
> But when i am trying to run it it is giving error
> like this..
>
>
> [main] INFO util.PropertyMessageResources -
> Initializing,
> config='org.apache.struts.util.LocalStrings',
> returnNull=true
> [main] INFO util.PropertyMessageResources -
> Initializing,
> config='org.apache.struts.action.ActionResources',
> returnNull=true
>
> Time: 0.625
> There was 1 failure:
> 1)
>
testAction(logic.struts.actions.TestFirstAction)junit.framework.AssertionFai
> ledError: Error running action.perform(): class
> java.lang.NullPointerException - null
> at
>
servletunit.struts.MockStrutsTestCase.actionPerform(MockStrutsTestCase.java:
> 339)
> at
>
logic.struts.actions.TestFirstAction.testAction(TestFirstAction.java:47)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
> )
> at
>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
> .java:25)
> at
>
com.intellij.rt.execution.junit.TextTestRunner.main(TextTestRunner.java:12)
>
> FAILURES!!!
> Tests run: 1, Failures: 1, Errors: 0
>
> Process terminated with exit code -1
>
>
>
>
> My Code is
>
>
> package logic.struts.actions;
>
> import servletunit.struts.MockStrutsTestCase;
> import servletunit.struts.CactusStrutsTestCase;
>
> import javax.servlet.ServletException;
>
> public class TestFirstAction extends
> MockStrutsTestCase{
>
> public TestFirstAction(String testName) {
> super(testName); }
>
> public void testAction() {
>setRequestPathInfo("/firstAction");
>actionPerform();
>verifyForward("second");
> }
>
> public void setUp() throws Exception {
> super.setUp();
> }
>
> protected void tearDown() throws Exception {
> super.tearDown();
> }
>
> }
>
>
>
>
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Regarding BUG: 17933 (FormAuthentication assumes "localhost" when adding cookies )
Hi,
This is regarding the bug listed here.
http://issues.apache.org/bugzilla/show_bug.cgi?id=17933
I was trying to fix it .
File: FormAuthentication.java
Method:
public void configure(WebRequest theRequest,
Configuration theConfiguration);
I guess i can get the context URL set in the
cactus.properties file this way
String contextURL = theConfiguration.getContextURL();
Now can i do a substring operation to extract the
domain name from the context URL and call
theRequest.addCookie(domainName,this.sessionIdCookieName,
this.sessionId);
I mean does cactus have some utility methods /
something that knows how to extract the domain name
properly from the contextURL?
I just want to make sure that i'm doing the right
thing in a right way.
I guess we can also do
webRequest.setURL() when using FormAuthentication;
if that is the case, i guess , I can extract the
domain/host name using ServletURL.getHost()
So what s'd i be doing in the implementation
FormAuthentication::configure()?
1. Do substring on contextURL OR
2. ServletURL.getHost()
OR try doing 1) and if it fails do 2)
Hope am not bugging the cactus commiters too much
here.
thanks,
karthik
--- Sachin <[EMAIL PROTECTED]> wrote:
> Hi All,
> I am trying to write TestCase of example
> Specified in StrutsTestCase
> which says that we can use both CactusStrutsTestCase
> or MockStrutsTestCase..
>
> But when i am trying to run it it is giving error
> like this..
>
>
> [main] INFO util.PropertyMessageResources -
> Initializing,
> config='org.apache.struts.util.LocalStrings',
> returnNull=true
> [main] INFO util.PropertyMessageResources -
> Initializing,
> config='org.apache.struts.action.ActionResources',
> returnNull=true
>
> Time: 0.625
> There was 1 failure:
> 1)
>
testAction(logic.struts.actions.TestFirstAction)junit.framework.AssertionFai
> ledError: Error running action.perform(): class
> java.lang.NullPointerException - null
> at
>
servletunit.struts.MockStrutsTestCase.actionPerform(MockStrutsTestCase.java:
> 339)
> at
>
logic.struts.actions.TestFirstAction.testAction(TestFirstAction.java:47)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
> )
> at
>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
> .java:25)
> at
>
com.intellij.rt.execution.junit.TextTestRunner.main(TextTestRunner.java:12)
>
> FAILURES!!!
> Tests run: 1, Failures: 1, Errors: 0
>
> Process terminated with exit code -1
>
>
>
>
> My Code is
>
>
> package logic.struts.actions;
>
> import servletunit.struts.MockStrutsTestCase;
> import servletunit.struts.CactusStrutsTestCase;
>
> import javax.servlet.ServletException;
>
> public class TestFirstAction extends
> MockStrutsTestCase{
>
> public TestFirstAction(String testName) {
> super(testName); }
>
> public void testAction() {
>setRequestPathInfo("/firstAction");
>actionPerform();
>verifyForward("second");
> }
>
> public void setUp() throws Exception {
> super.setUp();
> }
>
> protected void tearDown() throws Exception {
> super.tearDown();
> }
>
> }
>
>
>
>
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Error when using machine name instead of "localhost" with FormAuthentication
karthik Guru wrote: Thanks Jason! The machines that run automated builds @ our place are different from the ones that host the application. Does that mean that i cannot automate unit testing along with our builds for now? / until the next cactus release is available? Can someone suggest a work around? Is downloading cactus source, modifying the source, and building cactus an option? Sure it's an option. I'd recommend you play with the latest from CVS, and provide a patch, so that it can be incorporated into the main trunk. Not sure what i s'd be modifying though. Automating unit testing is one of the prime objectives for me in this quarter :-( thanks, karthik. */Jason Arndt <[EMAIL PROTECTED]>/* wrote: Hi Karthik, There is already an open bug on this problem. It can be viewed at: http://issues.apache.org/bugzilla/show_bug.cgi?id=17933 Jason -- Christopher Lenz /=/ cmlenz at gmx.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Error when using machine name instead of "localhost" with FormAuthentication
Thanks Jason!
The machines that run automated builds @ our place are different from the ones that host the application. Does that mean that i cannot automate unit testing along with our builds for now? / until the next cactus release is available? Can someone suggest a work around?
Is downloading cactus source, modifying the source, and building cactus an option?
Not sure what i s'd be modifying though. Automating unit testing is one of the prime objectives for me in this quarter :-(
thanks,
karthik.
Jason Arndt <[EMAIL PROTECTED]> wrote:
Hi Karthik,There is already an open bug on this problem. It canbe viewed at:http://issues.apache.org/bugzilla/show_bug.cgi?id=17933Jason--- karthik Guru <[EMAIL PROTECTED]>wrote:> I changed localhost to machine name in the code and> ran into this error.> > "hostName" and "port" are 2 properties defined in> the cactus.properties file.> Moment i change hostName --> machine name i have a> problem.> As long as it remains "locahost" it is fine.> > Any idea as to what is going wrong? am able to> access the application from another machine.> > If I do>:7001/ppo/home.jsp">http://:7001/ppo/home.jsp> it works fine and am able to login.> > thanks> karthik.> > public void login(WebRequest
webRequest){> String userName = getTestParameter(USERNAME_KEY);> String password = getTestParameter(PASSWORD_KEY);> FormAuthentication fa = new> FormAuthentication(userName, password);> > webRequest.setRedirectorName("ServletRedirector");> webRequest.setAuthentication(fa);> String hostname=System.getProperty("hostName");> String port=System.getProperty("port"); > String firstPart = hostname+":"+port; > String secondPart = "/ppo";> String thirdPart = "/home.jsp";> System.out.println("Url: " + firstPart +> secondPart + thirdPart);> webRequest.setURL(firstPart, secondPart,> thirdPart, null, null);> }> > > [junit] - Standard Output> ---> > [junit] user: mdoadmin, password: mdoadmin> > [junit] Created FormAuthentication> > [junit] Hostname:port got=sjain:7001> >
[junit] Url: sjain:7001/ppo/home.jsp> > [junit] - > ---> > [junit] - Standard Error> -> > [junit] log4j:ERROR No appenders could be found for> category (org.apache.cac> > tus.client.initialization.ClientInitializer).> > [junit] log4j:ERROR Please initialize the log4j> system properly.> > [junit] - > ---> > [junit] Testcase:>testMarkdownSearch(com.i2.mdo.unittest.MarkdownSearchTest)> > : Caused an ERROR> > [junit] Failed to authenticate the principal> > [junit]> org.apache.cactus.util.ChainedRuntimeException:> Failed to authentica> > te the principal> > [junit] at>org.apache.cactus.client.authentication.FormAuthentication.au>
>thenticate$ajcPostAround24(FormAuthentication.java;org/apache/cactus/util/log/Lo> > gAspect.aj(1k):314)> > [junit] at>org.apache.cactus.client.authentication.FormAuthentication.au> >thenticate$ajcPostAround24$ajcVoidWrapper(FormAuthentication.java;org/apache/cac> > tus/util/log/LogAspect.aj(1k))> > [junit] at>org.apache.cactus.client.authentication.FormAuthentication.au> >thenticate(FormAuthentication.java;org/apache/cactus/util/log/LogAspect.aj(1k):1> > 151)> > [junit] at>org.apache.cactus.client.authentication.FormAuthentication.co> >nfigure$ajcPostAround15(FormAuthentication.java;org/apache/cactus/util/log/LogAs> > pect.aj(1k):155)> > [junit] at>org.apache.cactus.client.authentication.FormAuthentication.co>
>nfigure$ajcPostAround15$ajcVoidWrapper(FormAuthentication.java;org/apache/cactus> > /util/log/LogAspect.aj(1k))> > [junit] at>org.apache.cactus.client.authentication.FormAuthentication.co> >nfigure(FormAuthentication.java;org/apache/cactus/util/log/LogAspect.aj(1k):1151> > )> > [junit] at>org.apache.cactus.client.connector.http.HttpClientConnectionH> >elper.connect$ajcPostAround9(HttpClientConnectionHelper.java;org/apache/cactus/u> > til/log/LogAspect.aj(1k):123)> > [junit] at>org.apache.cactus.client.connector.http.HttpClientConnectionH> >elper.connect(HttpClientConnectionHelper.java;org/apache/cactus/util/log/LogAspe> > ct.aj(1k):1222)> > [junit] at>org.apache.cactus.client.connector.http.DefaultHttpClient.cal>
>lRunTest(DefaultHttpClient.java;org/apache/cactus/util/log/LogAspect.aj(1k):202)> > [junit] at>org.apache.cactus.client.connector.http.DefaultHttpClient.doT> >est$ajcPostAround7(DefaultHtt
Re: Error when using machine name instead of "localhost" with FormAuthentication
Hi Karthik,
There is already an open bug on this problem. It can
be viewed at:
http://issues.apache.org/bugzilla/show_bug.cgi?id=17933
Jason
--- karthik Guru <[EMAIL PROTECTED]> wrote:
> I changed localhost to machine name in the code and
> ran into this error.
>
> "hostName" and "port" are 2 properties defined in
> the cactus.properties file.
> Moment i change hostName --> machine name i have a
> problem.
> As long as it remains "locahost" it is fine.
>
> Any idea as to what is going wrong? am able to
> access the application from another machine.
>
> If I do
>
:7001/ppo/home.jsp">http://:7001/ppo/home.jsp
> it works fine and am able to login.
>
> thanks
> karthik.
>
> public void login(WebRequest webRequest){
>String userName = getTestParameter(USERNAME_KEY);
>String password = getTestParameter(PASSWORD_KEY);
>FormAuthentication fa = new
> FormAuthentication(userName, password);
>
> webRequest.setRedirectorName("ServletRedirector");
>webRequest.setAuthentication(fa);
>String hostname=System.getProperty("hostName");
>String port=System.getProperty("port");
>String firstPart = hostname+":"+port;
>String secondPart = "/ppo";
>String thirdPart = "/home.jsp";
>System.out.println("Url: " + firstPart +
> secondPart + thirdPart);
>webRequest.setURL(firstPart, secondPart,
> thirdPart, null, null);
> }
>
>
> [junit] - Standard Output
> ---
>
> [junit] user: mdoadmin, password: mdoadmin
>
> [junit] Created FormAuthentication
>
> [junit] Hostname:port got=sjain:7001
>
> [junit] Url: sjain:7001/ppo/home.jsp
>
> [junit] -
> ---
>
> [junit] - Standard Error
> -
>
> [junit] log4j:ERROR No appenders could be found for
> category (org.apache.cac
>
> tus.client.initialization.ClientInitializer).
>
> [junit] log4j:ERROR Please initialize the log4j
> system properly.
>
> [junit] -
> ---
>
> [junit] Testcase:
>
testMarkdownSearch(com.i2.mdo.unittest.MarkdownSearchTest)
>
> : Caused an ERROR
>
> [junit] Failed to authenticate the principal
>
> [junit]
> org.apache.cactus.util.ChainedRuntimeException:
> Failed to authentica
>
> te the principal
>
> [junit] at
>
org.apache.cactus.client.authentication.FormAuthentication.au
>
>
thenticate$ajcPostAround24(FormAuthentication.java;org/apache/cactus/util/log/Lo
>
> gAspect.aj(1k):314)
>
> [junit] at
>
org.apache.cactus.client.authentication.FormAuthentication.au
>
>
thenticate$ajcPostAround24$ajcVoidWrapper(FormAuthentication.java;org/apache/cac
>
> tus/util/log/LogAspect.aj(1k))
>
> [junit] at
>
org.apache.cactus.client.authentication.FormAuthentication.au
>
>
thenticate(FormAuthentication.java;org/apache/cactus/util/log/LogAspect.aj(1k):1
>
> 151)
>
> [junit] at
>
org.apache.cactus.client.authentication.FormAuthentication.co
>
>
nfigure$ajcPostAround15(FormAuthentication.java;org/apache/cactus/util/log/LogAs
>
> pect.aj(1k):155)
>
> [junit] at
>
org.apache.cactus.client.authentication.FormAuthentication.co
>
>
nfigure$ajcPostAround15$ajcVoidWrapper(FormAuthentication.java;org/apache/cactus
>
> /util/log/LogAspect.aj(1k))
>
> [junit] at
>
org.apache.cactus.client.authentication.FormAuthentication.co
>
>
nfigure(FormAuthentication.java;org/apache/cactus/util/log/LogAspect.aj(1k):1151
>
> )
>
> [junit] at
>
org.apache.cactus.client.connector.http.HttpClientConnectionH
>
>
elper.connect$ajcPostAround9(HttpClientConnectionHelper.java;org/apache/cactus/u
>
> til/log/LogAspect.aj(1k):123)
>
> [junit] at
>
org.apache.cactus.client.connector.http.HttpClientConnectionH
>
>
elper.connect(HttpClientConnectionHelper.java;org/apache/cactus/util/log/LogAspe
>
> ct.aj(1k):1222)
>
> [junit] at
>
org.apache.cactus.client.connector.http.DefaultHttpClient.cal
>
>
lRunTest(DefaultHttpClient.java;org/apache/cactus/util/log/LogAspect.aj(1k):202)
>
> [junit] at
>
org.apache.cactus.client.connector.http.DefaultHttpClient.doT
>
>
est$ajcPostAround7(DefaultHttpClient.java;org/apache/cactus/util/log/LogAspect.a
>
> j(1k):119)
>
> [junit] at
>
org.apache.cactus.client.connector.http.DefaultHttpClient.doT
>
>
est(DefaultHttpClient.java;org/apache/cactus/util/log/LogAspect.aj(1k):1222)
>
> [junit] at
>
org.apache.cactus.AbstractWebServerTestCase.runWebTest(Abstra
>
> ctWebServerTest
Error when using machine name instead of "localhost" with FormAuthentication
I changed localhost to machine name in the code and ran into this error.
"hostName" and "port" are 2 properties defined in the cactus.properties file.
Moment i change hostName --> machine name i have a problem.
As long as it remains "locahost" it is fine.
Any idea as to what is going wrong? am able to access the application from another machine.
If I do http://:7001/ppo/home.jsp it works fine and am able to login.
thanks
karthik.
public void login(WebRequest webRequest){ String userName = getTestParameter(USERNAME_KEY); String password = getTestParameter(PASSWORD_KEY); FormAuthentication fa = new FormAuthentication(userName, password); webRequest.setRedirectorName("ServletRedirector"); webRequest.setAuthentication(fa); String hostname=System.getProperty("hostName"); String port=System.getProperty("port"); String firstPart = hostname+":"+port; String secondPart = "/ppo"; String thirdPart = "/home.jsp"; System.out.println("Url: " + firstPart + secondPart + thirdPart); webRequest.setURL(firstPart, secondPart, thirdPart, null, null); }
[junit] ----- Standard Output ---
[junit] user: mdoadmin, password: mdoadmin
[junit] Created FormAuthentication
[junit] Hostname:port got=sjain:7001
[junit] Url: sjain:7001/ppo/home.jsp
[junit] - ---
[junit] - Standard Error -
[junit] log4j:ERROR No appenders could be found for category (org.apache.cac
tus.client.initialization.ClientInitializer).
[junit] log4j:ERROR Please initialize the log4j system properly.
[junit] - ---
[junit] Testcase: testMarkdownSearch(com.i2.mdo.unittest.MarkdownSearchTest)
: Caused an ERROR
[junit] Failed to authenticate the principal
[junit] org.apache.cactus.util.ChainedRuntimeException: Failed to authentica
te the principal
[junit] at org.apache.cactus.client.authentication.FormAuthentication.au
thenticate$ajcPostAround24(FormAuthentication.java;org/apache/cactus/util/log/Lo
gAspect.aj(1k):314)
[junit] at org.apache.cactus.client.authentication.FormAuthentication.au
thenticate$ajcPostAround24$ajcVoidWrapper(FormAuthentication.java;org/apache/cac
tus/util/log/LogAspect.aj(1k))
[junit] at org.apache.cactus.client.authentication.FormAuthentication.au
thenticate(FormAuthentication.java;org/apache/cactus/util/log/LogAspect.aj(1k):1
151)
[junit] at org.apache.cactus.client.authentication.FormAuthentication.co
nfigure$ajcPostAround15(FormAuthentication.java;org/apache/cactus/util/log/LogAs
pect.aj(1k):155)
[junit] at org.apache.cactus.client.authentication.FormAuthentication.co
nfigure$ajcPostAround15$ajcVoidWrapper(FormAuthentication.java;org/apache/cactus
/util/log/LogAspect.aj(1k))
[junit] at org.apache.cactus.client.authentication.FormAuthentication.co
nfigure(FormAuthentication.java;org/apache/cactus/util/log/LogAspect.aj(1k):1151
)
[junit] at org.apache.cactus.client.connector.http.HttpClientConnectionH
elper.connect$ajcPostAround9(HttpClientConnectionHelper.java;org/apache/cactus/u
til/log/LogAspect.aj(1k):123)
[junit] at org.apache.cactus.client.connector.http.HttpClientConnectionH
elper.connect(HttpClientConnectionHelper.java;org/apache/cactus/util/log/LogAspe
ct.aj(1k):1222)
[junit] at org.apache.cactus.client.connector.http.DefaultHttpClient.cal
lRunTest(DefaultHttpClient.java;org/apache/cactus/util/log/LogAspect.aj(1k):202)
[junit] at org.apache.cactus.client.connector.http.DefaultHttpClient.doT
est$ajcPostAround7(DefaultHttpClient.java;org/apache/cactus/util/log/LogAspect.a
j(1k):119)
[junit] at org.apache.cactus.client.connector.http.DefaultHttpClient.doT
est(DefaultHttpClient.java;org/apache/cactus/util/log/LogAspect.aj(1k):1222)
[junit] at org.apache.cactus.AbstractWebServerTestCase.runWebTest(Abstra
ctWebServerTestCase.java:272)
[junit] at org.apache.cactus.AbstractWebServerTestCase.runGenericTest(Ab
stractWebServerTestCase.java:214)
[junit] at org.apache.cactus.AbstractWebServerTestCase.runTest(AbstractW
ebServerTestCase.java:287)
[junit] at org.apache.cactus.AbstractClientTestCase.runBare(AbstractClie
ntTestCase.java:289)
[junit] org.apache.cactus.client.ClientException: Failed to create Cookie he
ader for [domain = [sjain, path = [/ppo/j_security_check, cookies = [[Lorg.apach
e.commons.httpclient.Cookie;@69cb75]]. Turn on HttpClient logging for more infor
mation about the error
[junit] at org.apache.cactus.client.connector.http.AbstractConnectionHel
per.createCookieHeader(AbstractConnectionHelper.java;org/apache/cactus/util/log/
LogAspect.aj(1k):270)
[junit] at org.apache.cactus.client.connector.http.AbstractConnectionHel
per.getCookieString$ajcPostAround6(AbstractConnectionHelper.java;org/apache/cact
us/util/log/LogAspect.aj(1k):221)
[junit] at org.apache.cactus.client.connector.http.AbstractConnectionHel
per.getC
RE: add POST parameters to the FormAuthentication security check URL request
It worked just fine. Thanks!
--- Vincent Massol <[EMAIL PROTECTED]> wrote:
> Hi Jason,
>
> I've just added support for your use case in cactus
> 1.5 (in CVS).
>
> Here's how to use it:
>
> public void beginXXX(WebRequest request)
> {
> FormAuthentication auth = new
> FormAuthentication(username, pwd);
>
>
auth.getSecurityRequest().addParameter("ias_request_appname",
> whatever);
>
>
auth.getSecurityRequest().addParameter("ias_request_real_appname",
> whatever);
> request.setAuthentication(auth);
> [...]
>
> Please note that I haven't tested it! (unfortunately
> we don't have any
> test yet for Form-Based authentication). Could you
> verify it works for
> you?
>
> Thanks
> -Vincent
>
> > -Original Message-
> > From: Jason Arndt [mailto:[EMAIL PROTECTED]
> > Sent: 08 March 2003 01:51
> > To: [EMAIL PROTECTED]
> > Subject: add POST parameters to the
> FormAuthentication security check
> URL
> > request
> >
> > Hi,
> >
> > I was wondering if anyone knows how to get the
> > FormAuthentication class to use additional
> parameters
> > during it's call to the security check URL in the
> > authenticate(WebRequest) method?
> >
> > I am using the iPlanet 6.5 application server and
> it
> > adds a few requirements to the standard form-based
> > authentication call. What I mean is that the
> security
> > check URL must be
> "/NASApp/System/FormAuthServlet",
> > which I can set. However, in addition to the
> standard
> > "j_username" and "j_password" parameters, it
> requires
> > 2 additional parameters, "ias_request_appname" and
> > "ias_request_real_appname", or it throws a
> > ServletException:
> >
> > [07/Mar/2003 17:42:43:6] error: Exception:
> > SERVLET-execution_failed: Error in executing
> servlet
> > FormAuthServlet: javax.servlet.ServletException:
> > Authorization information not provided to
> > BasicAuthServlet
> >
> > Anyway, I've gotten it to work by downloading the
> > latest cactus source from cvs and modifying the
> > FormAuthentication class' authenticate method to
> add
> > these parameters to the request, but this was just
> a
> > short term solution to test my theory and I need
> > another alternative. Any help would be
> appreciated.
> >
> > Thanks in advance!
> >
> > -- Jason
> >
> > __
> > Do you Yahoo!?
> > Yahoo! Tax Center - forms, calculators, tips, more
> > http://taxes.yahoo.com/
> >
> >
>
-
> > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
>
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: add POST parameters to the FormAuthentication security check URL request
Hi Jason,
I've just added support for your use case in cactus 1.5 (in CVS).
Here's how to use it:
public void beginXXX(WebRequest request)
{
FormAuthentication auth = new FormAuthentication(username, pwd);
auth.getSecurityRequest().addParameter("ias_request_appname",
whatever);
auth.getSecurityRequest().addParameter("ias_request_real_appname",
whatever);
request.setAuthentication(auth);
[...]
Please note that I haven't tested it! (unfortunately we don't have any
test yet for Form-Based authentication). Could you verify it works for
you?
Thanks
-Vincent
> -Original Message-
> From: Jason Arndt [mailto:[EMAIL PROTECTED]
> Sent: 08 March 2003 01:51
> To: [EMAIL PROTECTED]
> Subject: add POST parameters to the FormAuthentication security check
URL
> request
>
> Hi,
>
> I was wondering if anyone knows how to get the
> FormAuthentication class to use additional parameters
> during it's call to the security check URL in the
> authenticate(WebRequest) method?
>
> I am using the iPlanet 6.5 application server and it
> adds a few requirements to the standard form-based
> authentication call. What I mean is that the security
> check URL must be "/NASApp/System/FormAuthServlet",
> which I can set. However, in addition to the standard
> "j_username" and "j_password" parameters, it requires
> 2 additional parameters, "ias_request_appname" and
> "ias_request_real_appname", or it throws a
> ServletException:
>
> [07/Mar/2003 17:42:43:6] error: Exception:
> SERVLET-execution_failed: Error in executing servlet
> FormAuthServlet: javax.servlet.ServletException:
> Authorization information not provided to
> BasicAuthServlet
>
> Anyway, I've gotten it to work by downloading the
> latest cactus source from cvs and modifying the
> FormAuthentication class' authenticate method to add
> these parameters to the request, but this was just a
> short term solution to test my theory and I need
> another alternative. Any help would be appreciated.
>
> Thanks in advance!
>
> -- Jason
>
> __
> Do you Yahoo!?
> Yahoo! Tax Center - forms, calculators, tips, more
> http://taxes.yahoo.com/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
add POST parameters to the FormAuthentication security check URL request
Hi, I was wondering if anyone knows how to get the FormAuthentication class to use additional parameters during it's call to the security check URL in the authenticate(WebRequest) method? I am using the iPlanet 6.5 application server and it adds a few requirements to the standard form-based authentication call. What I mean is that the security check URL must be "/NASApp/System/FormAuthServlet", which I can set. However, in addition to the standard "j_username" and "j_password" parameters, it requires 2 additional parameters, "ias_request_appname" and "ias_request_real_appname", or it throws a ServletException: [07/Mar/2003 17:42:43:6] error: Exception: SERVLET-execution_failed: Error in executing servlet FormAuthServlet: javax.servlet.ServletException: Authorization information not provided to BasicAuthServlet Anyway, I've gotten it to work by downloading the latest cactus source from cvs and modifying the FormAuthentication class' authenticate method to add these parameters to the request, but this was just a short term solution to test my theory and I need another alternative. Any help would be appreciated. Thanks in advance! -- Jason __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ - 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
AW: FormAuthentication
Hi Jason, I would also be interested in this FormAuthentication Example. I didn't follow the discussion closely the last couple weeks is it also possible to test form based login with https? Regards, Michael -Ursprüngliche Nachricht- Von: Robertson, Jason [mailto:Jason.Robertson@;acs-inc.com] Gesendet am: Montag, 28. Oktober 2002 21:35 An: 'Cactus Users List' Betreff: RE: FormAuthentication I think this is a good solution. Separate WAR files is the only way I know of to use different authentication techniques. Plus, the side effect of making a clearer separation between the example and the unit tests I agree is a good thing. Do you want my test app? It's just a very simple web app with pages to do the form authentication as well, so you have a 2nd avenue to test configuration if you're having troubles with cactus. Its the one I used to test Tomcat and WLS. I'm sure it can be easily adapted to any other J2EE server. Let me know and I'll try to bundle it up. Jason -Original Message- From: Vincent Massol [mailto:vmassol@;octo.com] Sent: Saturday, October 26, 2002 2:12 PM To: 'Cactus Users List' Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: FormAuthentication Hi Jason/Pranab, Thank you both for the good analysis! There are indeed 2 bugs you have found: - one with the FormAuthentication using only the default redirector - one with the HttpClient fetching the test result using only the default redirector I have now fixed (hopefully) both bugs in CVS. You can check the CVS commit emails if you wish to see what I have modified. I would be happy to know if you agree with my changes... :-) However, there is still something missing which I was not able to code: it is a test for the FormAuthentication class. The problem is that apparently you can only have one method of authentication in a given webapp and ATM the sample webapp is using Basic authentication... Thus we cannot easily add one more test for testing Jason's FormaAuthentication code ... I was pondering about what route to take for that. Any idea? One solution would be to have several webapp of course and more specifically to have the following directory structure in CVS: jakarta-cactus |_ [...] |_ servlet-sample |_ servlet-unit servlet-sample: contains only the org.apache.cactus.sample.* packages. It is the sample application. servlet-unit: contains only the org.apache.cactus.unit.* packages. The goal of this application is to offer a full regression test suite for Cactus. It is not a sample application per see. The idea would then be to have a build file that produces 3 wars: one test.war (no authentication tests), one test-basic.war (basic authentication tests) and one test-form.war (form-based authentication tests). Note: Some persons have told me it was difficult to understand the differences between the unit/ and sample/ directories in the servlet-sample project. That would solve the problem. What do you think? Thanks -Vincent > -Original Message- > From: Robertson, Jason [mailto:Jason.Robertson@;acs-inc.com] > Sent: 26 October 2002 15:40 > To: 'Cactus Users List' > Subject: RE: FormAuthentication > > Time for Vincent to chime in! > > Vincent, Pranab's comments below show that there's a problem in the > reconfiguring of the Redirector in that you can configure it in two > places: > in WebRequest and in cactus.properties, but only the latter is persistent > between callRunTest and callGetResult. In callGetResult, a new WebRequest > is > created and gets initialized with the cactus.properties value. > > Should calling setRedirectorName in the WebRequest propagate that setting > to > the configuration? Or should that method be removed from WebRequest and > added to the WebConfiguration interface and then you'd say: > > aWebRequestObject.getConfiguration().setRedirectorName(...); > > Or should the same WebRequest object be shared between callRunTest and > callGetResult? I would think this would make the most sense, I don't know > if > I like accessing static properties through a transient object. > > If we take the reuse-the-WebRequest approach, the signature for > callGetResult would change to remove the AbstractAuthen. Thetication and add > the > WebRequest (the authentication object would already be configured in the > WebRequest) and you'd have to add something like a "setParameter" that > would > overwrite any existing parameter and allow you to reconfigure the service > name parameter. > > None of these changes are that difficult, but does any one look better or > worse in the "big picture"? > > Jason [snip] -- To unsubscribe, e-mail: <mailto:cactus-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:cactus-use
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
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.
My tests are simple like the examples in cactus distro.
/**
* Method beginBasicAuthentication.
*/
public void beginBasicAuthentication(WebRequest theRequest) {
log.info(" setting test
environment###");
theRequest.setURL("localhost:8080", "", "/secure/idsconf",
null, null);
theRequest.addCookie( "test", "test" );
theRequest.setRedirectorName("ServletRedirectorSecure");
theRequest.setAuthentication(new FormAuthentication("admin",
"admin22"));
}
/**
* Method testBasicAuthentication.
*/
public void testBasicAuthentication() {
try {
log.info("###Started
testing");
assertEquals("admin",
request.getUserPrincipal().getName());
assertEquals("admin",
request.getRemoteUser());
assertTrue("User not in 'admin' role",
request.isUserInRole("admin"));
// Verify URI
assertEquals("/secure/idsconf",
request.getRequestURI());
// Verify server name
assertEquals("localhost", request.getServerName());
// Returns 8080 when no port is specified
assertEquals(8080, request.getServerPort());
// Return "" when no context path is defined
assertEquals("", request.getContextPath());
idsconfServlet servlet = new
idsconfServlet();
servlet.init(this.config);
servlet.doGet(this.request,this.response);
} catch (ServletException e) {
log.error(e);
} catch (IOException e) {
log.error(e);
}
}
P.S. Am I doing something wrong with the tests ?
The logs after the FormAuthentication show that an attempt is being made to
CALL_TEST.
After which it gets the 404 Not found return code for this query
http://localhost:8080/ServletRedirectorSecure?Cactus_TestMethod=testBasicAut
hentication&Cactus_URL_ContextPath=&Cactus_URL_Server=localhost%3A8080&Cactu
s_URL_ServletPath=%2Fsecure%2Fidsconf&Cactus_TestClass=com.ids.servlet.TestL
oginServlet&Cactus_AutomaticSession=true&Cactus_URL_Protocol=http&Cactus_Ser
vice=CALL_TEST
It appears that cactus loses direction on the server side of the
framework.BTW how do you get the logs of the serverside of the framework ?
I couldn't help the huge logs ,just wanted to convey the idea. The last
cactus nightly build was 10/22 when is the next one scheduled ?
It was pain trying to build it from CVS with aspectJ and checkstyle giving
the most grief.
Pranab
20:22:09,207 [main] DEBUG hentication.FormAuthentication - >configure
20:22:09,207 [main] DEBUG cactus.WebRequest -
getParameterValuesGet = [[Ljava.lang.String;@99681b]
20:22:09,207 [main] DEBUG cactus.WebRequest -
getParameterValuesGet = [[Ljava.lang.String;@2d3205]
20:22:09,207 [main] DEBUG cactus.WebRequest -
getParameterValuesGet = [[Ljava.lang.String;@2f1921]
20:22:09,207 [main] DEBUG cactus.WebRequest -
getParameterValuesGet = [[Ljava.lang.String;@1adc30]
20:22:09,207 [main] DEBUG cactus.WebRequest -
getParameterValuesGet = [[Ljava.lang.String;@6df84b]
20:22:09,207 [main] DEBUG cactus.WebRequest -
getParameterValuesGet = [[Ljava.lang.String;@c832d2]
20:22:09,207 [main] DEBUG cactus.WebRequest -
getParameterValuesGet = [[Ljava.lang.String;@808199]
20:22:09,207 [main] DEBUG cactus.WebRequest -
getParameterValuesGet = [[Ljava.lang.String;@bc887b]
20:22:09,207 [main] DEBUG util.UrlUtil-
http://localhost:8080/ServletRedirectorSecure?Cactus_TestMethod=te
stBasicAuthentication&Cactus_URL_ContextPath=&Cactus_URL_Server=localhost%3A
8080&Cactus_URL_ServletPath=%2Fsecure%2Fidsconf&Cactus_TestClass=com.ids.ser
vlet.TestLoginServlet&Cactus_AutomaticSession=true&Cactus_U
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.se
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
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 -
121f1d])
18:00:13,971 [main] DEBUG util.ChainedRuntimeException- >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)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
nner.java:329)
at
org.eclipse.jdt.i
