Re: FormAuthentication problem

[Kazuhito SUGURI]

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

[Petar Tahchiev]

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-userm=119098089904045w=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

[Kazuhito SUGURI]

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-userm=119098089904045w=2

If it works for you, please let me know.

Kazuhito SUGURI

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: FormAuthentication problem

[Eric Barendt]

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-userm=119098089904045w=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

[Nicolas Chalumeau]

Do you use the ant task or the maven plugin ?

For the ant task add in your catifywar :
servletredirector name=ServletRedirectorSecure
 mapping=/ServletRedirectorSecure
 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]

Re: FormAuthentication

[David Turley]

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 :
servletredirector name=ServletRedirectorSecure
mapping=/ServletRedirectorSecure
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 and Error Code 500

[Setanta Mathews]

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

[Kazuhito SUGURI]

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

[Kazuhito SUGURI]

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=0j_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]

RE: FormAuthentication and Error Code 500

[Setanta Mathews]

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=0j_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

[Kazuhito SUGURI]

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

[Setanta Mathews]

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 with machine name

[Vincent Massol]

Hi Anton,

Sorry for the late answer. The status is in the bug itself:

http://issues.apache.org/bugzilla/show_bug.cgi?id=17933

It's still open and thus has not been fixed. Would you have patch for
it?

Thanks
-Vincent

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
 Sent: 08 January 2004 11:11
 To: Cactus Users List
 Subject: FormAuthentication with machine name
 
 
 
 
 
 I already asked this question five months ago and did not get any
answer
 ...
 
 There was/is a Bug (17933) with FormAuthentication using not localhost
as
 the machine name
 in the cactus.properties file (cactus.contextURL).
 
 The fix was announced earlier for version 1.6.
 Is this already fixed in one of the nightly builds?
 
 I already tried two or three of the earlier ones but without success.
 
 Thanks for any help!
 
 Toni Grimm
 
 ---
 Anton Grimm
 MAN Nutzfahrzeuge AG
 IDP - Software Produktionsumgebungen
 Dachauerstr.667
 D - 80995 München
 
 Fon:   +49-89-1580-1054
 Fax:   +49-89-1580-911054
 mailto:[EMAIL PROTECTED]
 Internet: http://www.man-trucks.com
 ---
 
 
 
 
 
   Vincent Massol
   [EMAIL PROTECTED]An:   'Cactus
Users
 List' [EMAIL PROTECTED]
   com Kopie:
Thema:RE: Login
once
 using (FormAuthentication) for all tests in a class
   04/01/08 09:55 AM
   Bitte antworten
   an Cactus Users
   List
 
 
 
 
 
 
 Hi Matt,
 
  -Original Message-
  From: Matt Raible [mailto:[EMAIL PROTECTED]
  Sent: 08 January 2004 01:21
  To: Cactus Users List
  Subject: Login once using (FormAuthentication) for all tests in a
 class
 
  Quick and dirty question:
 
  Is it possible to login once (using FormAuthentication) for a class,
  rather than adding a beginXXTestName befor every testXXTestName
 method?
 
 
 hmm... There is a global begin(WebRequest) method. But it is called
 before every test (it's the equivalent of setUp() but on the client
 side). What we should do really is create the equivalent of JUnit
 TestSetup but with methods names begin/end instead of SetUp/tearDown.
 Patches much welcome :-)
 
  Longer explanation:
 
  I have a number of tests in my ContactActionTest - this test extends
  CactusStrutsTestCase, which extends ServletTestCase - nothing is
 really
  Struts specific in this scenario.
 
  In order to simulate logging in, I've simply retrieved a user object
 in
  by setUp() method and stuffed it into the session - this seems to
  simulate a login good enough.  However, today, I started logging
down
  my Actions/Servlets with roles.  So now this doesn't work - do I
have
  to have a beginXX before each testXX that logs the user in (with
  FormAuthentication)?
 
 Thinking more about it, I'm not so sure that the solution is a method
 that is called only once... Each test must set its own fixture. So you
 should group test using the same fixture (i.e. user being logging in)
in
 the same TestCase class. Then simply use either begin() or even better
 setUp() (it has direct access to the session) to log the user in
before
 *each* test.
 
 Cactus is about unitary tests so each test must set its own fixture
and
 not depend on other tests or side effects.
 
 Thanks
 -Vincent
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
 
 This message and any attachments are confidential and may be
privileged or
 otherwise protected from disclosure.
 If you are not the intended recipient, please telephone or email the
 sender and delete this message and any attachment
 from your system. If you are not the intended recipient, you must not
copy
 this message or attachment or disclose the
 contents to any other person.
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: FormAuthentication

[Vincent Massol]

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 !-- Jar files -- section to fit
your
 setup.
 
 As far as I know, form authentication over https shouldn't be a
problem as
 it's really not much different than any other form submission. As long
as
 the server is setup right and the context URL has https I'd assume it
 would
 all work, but I've never tested it.
 
 Jason
 
 -Original Message-
 From: Koegel, Michael [mailto:Michael.Koegel;partner.commerzbank.com]
 Sent: Tuesday, October 29, 2002 3:23 AM
 To: Cactus Users List
 Subject: AW: FormAuthentication
 
 
 Hi Jason,
 
 I would also be interested in this FormAuthentication Example.
 I didn't follow the discussion closely the last couple weeks is it
also
 possible to test form based login with https?
 
 Regards,
  Michael
 
 -Ursprüngliche Nachricht-
 Von: Robertson, Jason [mailto:Jason.Robertson;acs-inc.com]
 Gesendet am: Montag, 28. Oktober 2002 21:35
 An: 'Cactus Users List'
 Betreff: RE: FormAuthentication
 
 I think this is a good solution. Separate WAR files is the only way I
know
 of to use different authentication techniques.
 
 Plus, the side effect of making a clearer separation between the
example
 and
 the unit tests I agree is a good thing.
 
 Do you want my test app? It's just a very simple web app with pages to
do
 the form authentication as well, so you have a 2nd avenue to test
 configuration if you're having troubles with cactus. Its the one I
used to
 test Tomcat and WLS. I'm sure it can be easily adapted to any other
J2EE
 server. Let me know and I'll try to bundle it up.
 
 Jason
 
 -Original Message-
 From: Vincent Massol [mailto:vmassol;octo.com]
 Sent: Saturday, October 26, 2002 2:12 PM
 To: 'Cactus Users List'
 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Subject: RE: FormAuthentication
 
 
 Hi Jason/Pranab,
 
 Thank you both for the good analysis! There are indeed 2 bugs you have
 found:
 - one with the FormAuthentication using only the default redirector
 - one with the HttpClient fetching the test result using only the
 default redirector
 
 I have now fixed (hopefully) both bugs in CVS. You can check the CVS
 commit emails if you wish to see what I have modified. I would be
happy
 to know if you agree with my changes... :-)
 
 However, there is still something missing which I was not able to
code:
 it is a test for the FormAuthentication class. The problem is that
 apparently you can only have one method of authentication in a given
 webapp and ATM the sample webapp is using Basic authentication... Thus
 we cannot easily add one more test for testing Jason's
 FormaAuthentication code ... I was pondering about what route to take
 for that. Any idea?
 
 One solution would be to have several webapp of course and more
 specifically to have the following directory structure in CVS:
 
 jakarta-cactus
   |_ [...]
   |_ servlet-sample
   |_ servlet-unit
 
 servlet-sample: contains only the org.apache.cactus.sample.* packages.
 It is the sample application.
 
 servlet-unit: contains only the org.apache.cactus.unit.* packages. The
 goal of this application is to offer a full regression test suite for
 Cactus. It is not a sample application per see. The idea would then be
 to have a build file that produces 3 wars: one test.war (no
 authentication tests), one test-basic.war (basic authentication tests)
 and one test-form.war (form-based authentication tests).
 
 Note: Some persons have told me it was difficult to understand the
 differences between the unit/ and sample/ directories in the
 servlet-sample project. That would solve the problem.
 
 What do you think?
 
 Thanks
 -Vincent
 
  -Original Message-
  From: Robertson, Jason [mailto:Jason.Robertson;acs-inc.com]
  Sent: 26 October 2002 15:40
  To: 'Cactus Users List'
  Subject: RE: FormAuthentication
 
  Time for Vincent to chime in!
 
  Vincent, Pranab's comments below show that there's a problem in the
  reconfiguring of the Redirector in that you can configure it in two
  places:
  in WebRequest and in cactus.properties, but only the latter is
 persistent
  between callRunTest and callGetResult. In callGetResult, a new
 WebRequest
  is
  created and gets initialized with the cactus.properties value

RE: FormAuthentication

[Robertson, Jason]

Here's my SimpleFormLogin project. This is project source, so look into
the build.xml file and adjust the !-- Jar files -- section to fit your
setup.

As far as I know, form authentication over https shouldn't be a problem as
it's really not much different than any other form submission. As long as
the server is setup right and the context URL has https I'd assume it would
all work, but I've never tested it.

Jason

-Original Message-
From: Koegel, Michael [mailto:Michael.Koegel;partner.commerzbank.com]
Sent: Tuesday, October 29, 2002 3:23 AM
To: Cactus Users List
Subject: AW: FormAuthentication


Hi Jason,

I would also be interested in this FormAuthentication Example.
I didn't follow the discussion closely the last couple weeks is it also
possible to test form based login with https?

Regards,
 Michael

-Ursprüngliche Nachricht-
Von: Robertson, Jason [mailto:Jason.Robertson;acs-inc.com]
Gesendet am: Montag, 28. Oktober 2002 21:35
An: 'Cactus Users List'
Betreff: RE: FormAuthentication

I think this is a good solution. Separate WAR files is the only way I know
of to use different authentication techniques.

Plus, the side effect of making a clearer separation between the example and
the unit tests I agree is a good thing.

Do you want my test app? It's just a very simple web app with pages to do
the form authentication as well, so you have a 2nd avenue to test
configuration if you're having troubles with cactus. Its the one I used to
test Tomcat and WLS. I'm sure it can be easily adapted to any other J2EE
server. Let me know and I'll try to bundle it up.

Jason

-Original Message-
From: Vincent Massol [mailto:vmassol;octo.com]
Sent: Saturday, October 26, 2002 2:12 PM
To: 'Cactus Users List'
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: FormAuthentication


Hi Jason/Pranab,

Thank you both for the good analysis! There are indeed 2 bugs you have
found:
- one with the FormAuthentication using only the default redirector
- one with the HttpClient fetching the test result using only the
default redirector

I have now fixed (hopefully) both bugs in CVS. You can check the CVS
commit emails if you wish to see what I have modified. I would be happy
to know if you agree with my changes... :-)

However, there is still something missing which I was not able to code:
it is a test for the FormAuthentication class. The problem is that
apparently you can only have one method of authentication in a given
webapp and ATM the sample webapp is using Basic authentication... Thus
we cannot easily add one more test for testing Jason's
FormaAuthentication code ... I was pondering about what route to take
for that. Any idea?

One solution would be to have several webapp of course and more
specifically to have the following directory structure in CVS:

jakarta-cactus
  |_ [...]
  |_ servlet-sample
  |_ servlet-unit

servlet-sample: contains only the org.apache.cactus.sample.* packages.
It is the sample application.

servlet-unit: contains only the org.apache.cactus.unit.* packages. The
goal of this application is to offer a full regression test suite for
Cactus. It is not a sample application per see. The idea would then be
to have a build file that produces 3 wars: one test.war (no
authentication tests), one test-basic.war (basic authentication tests)
and one test-form.war (form-based authentication tests). 

Note: Some persons have told me it was difficult to understand the
differences between the unit/ and sample/ directories in the
servlet-sample project. That would solve the problem.

What do you think?

Thanks
-Vincent

 -Original Message-
 From: Robertson, Jason [mailto:Jason.Robertson;acs-inc.com]
 Sent: 26 October 2002 15:40
 To: 'Cactus Users List'
 Subject: RE: FormAuthentication
 
 Time for Vincent to chime in!
 
 Vincent, Pranab's comments below show that there's a problem in the
 reconfiguring of the Redirector in that you can configure it in two
 places:
 in WebRequest and in cactus.properties, but only the latter is
persistent
 between callRunTest and callGetResult. In callGetResult, a new
WebRequest
 is
 created and gets initialized with the cactus.properties value.
 
 Should calling setRedirectorName in the WebRequest propagate that
setting
 to
 the configuration? Or should that method be removed from WebRequest
and
 added to the WebConfiguration interface and then you'd say:
 
 aWebRequestObject.getConfiguration().setRedirectorName(...);
 
 Or should the same WebRequest object be shared between callRunTest and
 callGetResult? I would think this would make the most sense, I don't
know
 if
 I like accessing static properties through a transient object.
 
 If we take the reuse-the-WebRequest approach, the signature for
 callGetResult would change to remove the AbstractAuthen. Thetication
and add
 the
 WebRequest (the authentication object would already be configured in
the
 WebRequest) and you'd have to add something like a setParameter that
 would
 overwrite any existing

RE: FormAuthentication

[Dhar, Pranab]

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

[Robertson, Jason]

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

[Robertson, Jason]

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) {
theRequest.setURL(localhost:8080, /, /secure/idsconf,
null, null); --
theRequest.addCookie( test, test

RE: FormAuthentication

[Vincent Massol]

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

[Dhar, Pranab]

, 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:-
application-policy name = IDSCONF-REALM
   !-- A simple server login module, which can be used when the number
   of users is relatively small. It uses two properties files:
   WEB-INF/classes/users.properties, which holds users (key) and their
password (value).
   WEB-INF/classes/roles.properties, which holds users (key) and a
comma-separated list of
   their roles (value).
   The unauthenticatedIdentity property defines the name of the
principal
   that will be used when a null username and password are presented as
is
   the case for an unuathenticated web client or MDB. If you want to
   allow such users to be authenticated add the property, e.g.,
   unauthenticatedIdentity=nobody
   --
   authentication
  login-module code =
org.jboss.security.auth.spi.UsersRolesLoginModule
 flag = required 
 module-option name =
unauthenticatedIdentityguest/module-option
  /login-module
   /authentication
/application-policy
--
Tomcat Security:-
security-constraint
web-resource-collection
web-resource-nameSecurityRestriction/web-resource-name
descriptionProtect the Cactus redirector
servlet./description
url-pattern/ServletRedirectorSecure/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
auth-constraint
descriptionAuthorized Users Group/description
role-nameidsconf_admin/role-name
role-nameidsconf_user/role-name
/auth-constraint
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
login-config
   auth-methodFORM/auth-method
   realm-nameIDSCONF-REALM/realm-name
   form-login-config
  form-login-page/LoginForm.jsp/form-login-page
  form-error-page/LoginError.jsp/form-error-page
   /form-login-config
/login-config
security-role
  !-- This role is mapped to EjbRoles using the
  application deployment descriptor logical roles --
descriptionThe Secure ROLE/description
role-nameidsconf_admin/role-name
/security-role
security-role
  !-- This role is mapped to EjbRoles using the
  application deployment descriptor logical roles --
descriptionThe Non Secure ROLE/description
role-nameidsconf_user/role-name
/security-role
--
J2EE application roles:-
application
 .. app jars.
   security-role
  !-- This role provides the mapping between Web App roles and Ejb
Roles --
descriptionAdministrator Role/description
role-nameidsconf_admin/role-name
   /security-role
   security-role
  !-- This role provides the mapping between Web App roles and Ejb
Roles --
descriptionUser Role/description
role-nameidsconf_user/role-name
   /security-role   
   security-role
  !-- This role is an internal role and must not be mapped --
descriptionInternal Role/description
role-nameidsconf_internal/role-name
   /security-role  
/application
JBoss EJB Security mapping jboss.xml
jboss
   security-domainjava:jaas/IDSCONF-REALM/security-domain
. entity/session beans jndi mapping

  container-configurations
!-- StatelessSession beans are secure by default --
container-configuration
container-nameStandard Stateless
SessionBean/container-name

security-domainjava:/jaas/IDSCONF-REALM/security-domain
/container-configuration
!-- Entity beans are secure by default --
container-configuration
container-nameStandard BMP EntityBean/container-name

security-domainjava:/jaas/IDSCONF-REALM/security-domain
/container-configuration
!-- A stateless session config that is not secured --
container-configuration extends=Standard Stateless SessionBean
container

RE: FormAuthentication

[Robertson, Jason]

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:-
application-policy name = IDSCONF-REALM
   !-- A simple server login module, which can be used when the number
   of users is relatively small. It uses two properties files:
   WEB-INF/classes/users.properties, which holds users (key) and their
password (value).
   WEB-INF/classes/roles.properties, which holds users (key) and a
comma-separated list of
   their roles (value).
   The unauthenticatedIdentity property defines the name of the
principal
   that will be used when a null username and password are presented as
is
   the case for an unuathenticated web client or MDB. If you want to
   allow such users to be authenticated add the property, e.g.,
   unauthenticatedIdentity=nobody
   --
   authentication
  login-module code =
org.jboss.security.auth.spi.UsersRolesLoginModule
 flag = required 
 module-option name =
unauthenticatedIdentityguest/module-option
  /login-module
   /authentication
/application-policy
--
Tomcat Security:-
security-constraint
web-resource-collection
web-resource-nameSecurityRestriction/web-resource-name
descriptionProtect the Cactus redirector
servlet./description
url-pattern/ServletRedirectorSecure/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
auth-constraint
descriptionAuthorized Users Group/description
role-nameidsconf_admin/role-name
role-nameidsconf_user/role-name
/auth-constraint
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
login-config
   auth-methodFORM/auth-method
   realm-nameIDSCONF-REALM/realm-name
   form-login-config
  form-login-page/LoginForm.jsp/form-login-page
  form-error-page/LoginError.jsp/form-error-page
   /form-login-config
/login-config
security-role
  !-- This role is mapped to EjbRoles using the
  application deployment descriptor logical roles --
descriptionThe Secure ROLE/description
role-nameidsconf_admin/role-name
/security-role
security-role
  !-- This role is mapped to EjbRoles using the
  application deployment descriptor logical roles --
descriptionThe Non Secure ROLE/description
role-nameidsconf_user/role-name
/security-role
--
J2EE application roles:-
application
 .. app jars.
   security-role
  !-- This role provides the mapping between Web App roles and Ejb
Roles --
descriptionAdministrator Role/description
role-nameidsconf_admin/role-name
   /security-role
   security-role
  !-- This role provides the mapping between Web App roles and Ejb
Roles --
descriptionUser Role/description
role-nameidsconf_user/role-name
   /security-role   
   security-role
  !-- This role is an internal role and must not be mapped --
descriptionInternal Role/description
role-nameidsconf_internal/role-name
   /security-role  
/application
JBoss EJB Security mapping jboss.xml
jboss
   security-domainjava:jaas/IDSCONF-REALM/security-domain
. entity/session beans jndi mapping

  container-configurations
!-- StatelessSession beans are secure by default --
container-configuration
container-nameStandard Stateless
SessionBean/container-name

security-domainjava:/jaas

RE: FormAuthentication

[Robertson, Jason]

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
  !-- Cactus Servlet Redirectors --
  servlet
servlet-nameServletRedirector/servlet-name
 
servlet-classorg.apache.cactus.server.ServletTestRedirector/servlet-class

  /servlet
  servlet
servlet-nameServletRedirectorSecure/servlet-name
 
servlet-classorg.apache.cactus.server.ServletTestRedirector/servlet-class

  /servlet
two aliases for the same Redirector servlet and the security constraint is
on the 
ServletRedirectorSecure alias.
security-constraint
web-resource-collection
web-resource-nameSecurityRestriction/web-resource-name
descriptionProtect the Cactus
redirectorservlet./description
url-pattern/ServletRedirectorSecure/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
auth-constraint
descriptionAuthorized Users Group/description
role-nameidsconf_admin/role-name
role-nameidsconf_user/role-name
/auth-constraint
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
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
codecactus.properties/code.
 * 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

RE: FormAuthentication

[Dhar, Pranab]

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
  !-- Cactus Servlet Redirectors --
  servlet
servlet-nameServletRedirector/servlet-name
 
servlet-classorg.apache.cactus.server.ServletTestRedirector/servlet-class

  /servlet
  servlet
servlet-nameServletRedirectorSecure/servlet-name
 
servlet-classorg.apache.cactus.server.ServletTestRedirector/servlet-class

  /servlet
two aliases for the same Redirector servlet and the security constraint is
on the 
ServletRedirectorSecure alias.
security-constraint
web-resource-collection
web-resource-nameSecurityRestriction/web-resource-name
descriptionProtect the Cactus
redirectorservlet./description
url-pattern/ServletRedirectorSecure/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
auth-constraint
descriptionAuthorized Users Group/description
role-nameidsconf_admin/role-name
role-nameidsconf_user/role-name
/auth-constraint
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
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
codecactus.properties/code.
 * 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

RE: FormAuthentication

[Dhar, Pranab]

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-
getPath([http://localhost:8080/ServletRedirectorSecure?Cactus_TestMethod=te
stBasicAuthenticationCactus_URL_ContextPath=%2FCactus_URL_Server=localhost
%3A8080Cactus_URL_ServletPath=%2Fsecure%2FidsconfCactus_TestClass=com.ids.
servlet.TestLoginServletCactus_AutomaticSession=trueCactus_URL_Protocol=ht
tpCactus_Service=CALL_TEST]) 
15:25:40,563 [main] DEBUG util.UrlUtil- getPath =
[/ServletRedirectorSecure] 
15:25:40,563 [main] DEBUG util.UrlUtil-
getQuery([http://localhost:8080/ServletRedirectorSecure?Cactus_TestMethod=t
estBasicAuthenticationCactus_URL_ContextPath=%2FCactus_URL_Server=localhos
t%3A8080Cactus_URL_ServletPath=%2Fsecure%2FidsconfCactus_TestClass=com.ids
.servlet.TestLoginServletCactus_AutomaticSession=trueCactus_URL_Protocol=h
ttpCactus_Service=CALL_TEST]) 
15:25:40,563 [main] DEBUG util.UrlUtil- getQuery =
[Cactus_TestMethod=testBasicAuthenticationCactus_URL_ContextPath=%2FCactus
_URL_Server=localhost%3A8080Cactus_URL_ServletPath=%2Fsecure%2FidsconfCact
us_TestClass=com.ids.servlet.TestLoginServletCactus_AutomaticSession=trueC
actus_URL_Protocol=httpCactus_Service=CALL_TEST] 
15:25:40,563 [main] DEBUG ent.HttpClientConnectionHelper  -
getCookieString([simulation URL = [protocol = [http], host name =
[localhost], port = [8080], context path = [/], servlet path =
[/secure/idsconf], path info = [null], query string = [null]], automatic
session = [true], cookies = [[name = [test], value = [test], domain =
[localhost], path = [null], isSecure = [false], comment = [null], expiryDate
= [null]][name = [JSESSIONID], value = [B9D9DDE0DD962B211E36D92FBE854D67],
domain = [localhost], path = [null], isSecure = [false], comment = [null],
expiryDate = [null]]], headers = [], GET parameters = [[[Cactus_TestMethod]
= [[testBasicAuthentication]]][[Cactus_URL_ContextPath] =
[[/]]][[Cactus_URL_Server] = [[localhost:8080]]][[Cactus_URL_ServletPath] =
[[/secure/idsconf]]][[Cactus_TestClass] =
[[com.ids.servlet.TestLoginServlet]]][[Cactus_AutomaticSession] =
[[true]]][[Cactus_URL_Protocol] = [[http]]][[Cactus_Service] =
[[CALL_TEST, POST parameters = []],
[http://localhost:8080/ServletRedirectorSecure?Cactus_TestMethod=testBasicAu
thenticationCactus_URL_ContextPath=%2FCactus_URL_Server=localhost%3A8080C
actus_URL_ServletPath=%2Fsecure%2FidsconfCactus_TestClass=com.ids.servlet.T
estLoginServletCactus_AutomaticSession=trueCactus_URL_Protocol=httpCactus
_Service=CALL_TEST]) 
15:25:40,563 [main] DEBUG cactus.Cookie   -
getCookiePath([simulation URL = [protocol = [http], host name =
[localhost], port = [8080], context path = [/], servlet path =
[/secure/idsconf], path info = [null], query string = [null]], automatic
session = [true], cookies = [[name = [test], value = [test], domain =
[localhost], path = [null], isSecure = [false], comment = [null], expiryDate
= [null]][name = [JSESSIONID], value = [B9D9DDE0DD962B211E36D92FBE854D67],
domain = [localhost], path = [null], isSecure = [false], comment = [null],
expiryDate = [null]]], headers = [], GET parameters = [[[Cactus_TestMethod]
= [[testBasicAuthentication]]][[Cactus_URL_ContextPath] =
[[/]]][[Cactus_URL_Server] = [[localhost:8080]]][[Cactus_URL_ServletPath] =

RE: FormAuthentication

[Robertson, Jason]

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-
getPath([http://localhost:8080/ServletRedirectorSecure?Cactus_TestMethod=te
stBasicAuthenticationCactus_URL_ContextPath=%2FCactus_URL_Server=localhost
%3A8080Cactus_URL_ServletPath=%2Fsecure%2FidsconfCactus_TestClass=com.ids.
servlet.TestLoginServletCactus_AutomaticSession=trueCactus_URL_Protocol=ht
tpCactus_Service=CALL_TEST]) 
15:25:40,563 [main] DEBUG util.UrlUtil- getPath =
[/ServletRedirectorSecure] 
15:25:40,563 [main] DEBUG util.UrlUtil-
getQuery([http://localhost:8080/ServletRedirectorSecure?Cactus_TestMethod=t
estBasicAuthenticationCactus_URL_ContextPath=%2FCactus_URL_Server=localhos
t%3A8080Cactus_URL_ServletPath=%2Fsecure%2FidsconfCactus_TestClass=com.ids
.servlet.TestLoginServletCactus_AutomaticSession=trueCactus_URL_Protocol=h
ttpCactus_Service=CALL_TEST]) 
15:25:40,563 [main] DEBUG util.UrlUtil- getQuery =
[Cactus_TestMethod=testBasicAuthenticationCactus_URL_ContextPath=%2FCactus
_URL_Server=localhost%3A8080Cactus_URL_ServletPath=%2Fsecure%2FidsconfCact
us_TestClass=com.ids.servlet.TestLoginServletCactus_AutomaticSession=trueC
actus_URL_Protocol=httpCactus_Service=CALL_TEST] 
15:25:40,563 [main] DEBUG ent.HttpClientConnectionHelper  -
getCookieString([simulation URL = [protocol = [http], host name =
[localhost], port = [8080], context path = [/], servlet path =
[/secure/idsconf], path info = [null], query string = [null]], automatic
session = [true], cookies = [[name = [test], value = [test], domain =
[localhost], path = [null], isSecure = [false], comment = [null], expiryDate
= [null]][name = [JSESSIONID], value = [B9D9DDE0DD962B211E36D92FBE854D67],
domain = [localhost], path = [null], isSecure = [false], comment = [null],
expiryDate = [null]]], headers = [], GET parameters = [[[Cactus_TestMethod]
= [[testBasicAuthentication]]][[Cactus_URL_ContextPath] =
[[/]]][[Cactus_URL_Server] = [[localhost:8080]]][[Cactus_URL_ServletPath] =
[[/secure/idsconf]]][[Cactus_TestClass] =
[[com.ids.servlet.TestLoginServlet]]][[Cactus_AutomaticSession] =
[[true]]][[Cactus_URL_Protocol] = [[http]]][[Cactus_Service] =
[[CALL_TEST, POST parameters = []],
[http://localhost:8080/ServletRedirectorSecure?Cactus_TestMethod=testBasicAu
thenticationCactus_URL_ContextPath=%2FCactus_URL_Server=localhost%3A8080C
actus_URL_ServletPath=%2Fsecure%2FidsconfCactus_TestClass=com.ids.servlet.T
estLoginServletCactus_AutomaticSession=trueCactus_URL_Protocol=httpCactus
_Service=CALL_TEST]) 
15:25:40,563 [main] DEBUG cactus.Cookie   -
getCookiePath([simulation URL = [protocol = [http], host name =
[localhost], port = [8080], context path = [/], servlet path =
[/secure/idsconf], path info = [null], query string = [null]], automatic
session = [true], cookies = [[name = [test], value = [test], domain =
[localhost], path = [null], isSecure = [false], comment = [null], expiryDate

RE: FormAuthentication

[Dhar, Pranab]

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-
getPath([http://localhost:8080/ServletRedirectorSecure?Cactus_TestMethod=te
stBasicAuthenticationCactus_URL_ContextPath=%2FCactus_URL_Server=localhost
%3A8080Cactus_URL_ServletPath=%2Fsecure%2FidsconfCactus_TestClass=com.ids.
servlet.TestLoginServletCactus_AutomaticSession=trueCactus_URL_Protocol=ht
tpCactus_Service=CALL_TEST]) 
15:25:40,563 [main] DEBUG util.UrlUtil- getPath =
[/ServletRedirectorSecure] 
15:25:40,563 [main] DEBUG util.UrlUtil-
getQuery([http://localhost:8080/ServletRedirectorSecure