jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Qingxian Wang <qingxian_w...@sunsystems.com>
Subject RE: Form Authentication
Date Mon, 16 Sep 2002 09:58:13 GMT
I have tried to use the FormAuthentication class with the
CactusStrutsTestCase of the Struts test case framework.  My test case has
problem to find the user name and password.  I got an
IllegalArgumentException thrown from the FormAuthentication class.  I will
try to use the Cactus directly, i.e. ServletTestCase class. 


-----Original Message-----
From: Vincent Massol [mailto:vmassol@octo.com]
Sent: 15 September 2002 22:19
To: 'Cactus Users List'
Subject: RE: Form Authentication

Thanks Jason! I've committed your code (modified slightly to add missing
javadoc, and the checkstyle violations ... :)).

I don't have any answer to your questions below. What we now need to do

1- write a test case for it
2- try it on several application servers
3- add web site documentation to explain how to use it

I guess 1 and 2 will give us the answers to your questions...

Thanks again

> -----Original Message-----
> From: Robertson, Jason [mailto:Jason.Robertson@acs-inc.com]
> Sent: 12 September 2002 23:04
> To: 'Cactus Users List'
> Subject: RE: Form Authentication
> Ok, attached is a slightly updated file with some comments and such.
> The basic premise is:
> 1. Is JSESSIONID non-null? If yes, stick it into a cookie and we're
> 2. If it's null, authenticate.
> 3. To authenticate, connect to ${ContextURL}/j_security_check with the
> username/password. This _should_ authenticate you.
> 4. Cache the returned JSESSIONID.
> 5. To verify we were authenticated, check a combination of the
> code
> and maybe redirect location. See question below.
> A TestCase could create a new FormAuthentication object for each test,
> could have a static one in the TestCase that will get initialized once
> reused. The latter would provide quicker testcases at the expense of
> keeping
> state between test cases, which is a philosophical expense at best.
> cool
> thing is in this case, though, that even if a single test case is run
> the
> middle of the sequence it will still work. It doesn't really rely on
> TestCase before it (the authentication will just happen when needed),
> it
> may not really violate any of the unit test philosophy.
> Only a couple questions:
> 1. Will all app servers send a 302 response with the location being
> ContextURL after a successful login? WebLogic does, and that's my only
> source right now. What about on an unsuccessful login? WebLogic
returns a
> 200 and the content is that of the login page, but I think it would be
> acceptable to return a 302 with a Location of the login page. I think
> code will work with both, but testing will be the only proof.
> 2. Do I need the setSecurityCheck method? Or will
> ${ContextURL}/j_security_check always work? It's really a safety net,
> it
> might be unnecessary.
> Jason
> -----Original Message-----
> From: Erik Hatcher [mailto:lists@ehatchersolutions.com]
> Sent: Thursday, September 12, 2002 9:17 AM
> To: Cactus Users List
> Subject: Re: Form Authentication
> Wow, just in the nick of time too!  I haven't looked at your code, but
> this is exactly what we need as well.
> I look forward to the Cactus committers having a look at this to see
> it fits in and getting it committed!  :)
> Thanks Jason!
> 	Erik
> Robertson, Jason wrote:
> > Here's a FormAuthentication implementation that doesn't need any
> of
> > the standard flow. The only modification needed to make this compile
> to
> > make the base class AbstractAuthentication's member variables
> and
> > 'thePassword' protected instead of private.
> >
> > This is a first pass. It's short on comments, and has some debugging
> code
> > temporarily commented out, but it works. At least for me, on
> 7.0.
> > :)
> >
> > I'll comment it and express some minor concerns especially with
> to
> > various app servers in the coming days, but I thought I'd throw this
> > now.
> >
> > I tried to include a sample ear that has a basic example, but the
> lib
> > directory is too big and it bounced. So I've included the project,
> > adjust the jar file properties in build.xml to make it all work.
> >
> > Jason
> >
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:cactus-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:cactus-user-help@jakarta.apache.org>
> --
> To unsubscribe, e-mail:
> <mailto:cactus-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:cactus-user-help@jakarta.apache.org>

To unsubscribe, e-mail:
For additional commands, e-mail:

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom it is addressed. If
you have received this e-mail in error you must not copy, distribute or take
any action in reliance on it. Please notify the sender by e-mail or
We utilise an anti-virus system and therefore any files sent via e-mail will
have been checked for known viruses. You are however advised to run your own
virus check before opening any attachments received as we will not in any
event accept any liability whatsoever once an e-mail and/or any attachment
is received. Any views expressed by an individual within this e-mail do not
necessarily reflect the views of Systems Union Group plc or any of its
subsidiary companies.

To unsubscribe, e-mail:   <mailto:cactus-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:cactus-user-help@jakarta.apache.org>

View raw message