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 done.
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 response code
and maybe redirect location. See question below.
A TestCase could create a new FormAuthentication object for each test, or
could have a static one in the TestCase that will get initialized once and
reused. The latter would provide quicker testcases at the expense of keeping
state between test cases, which is a philosophical expense at best. The cool
thing is in this case, though, that even if a single test case is run in the
middle of the sequence it will still work. It doesn't really rely on the
TestCase before it (the authentication will just happen when needed), so 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 the
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 my
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, but it
might be unnecessary.
Jason
-----Original Message-----
From: Erik Hatcher [mailto:[EMAIL PROTECTED]]
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 if
it fits in and getting it committed! :)
Thanks Jason!
Erik
Robertson, Jason wrote:
> Here's a FormAuthentication implementation that doesn't need any rework of
> the standard flow. The only modification needed to make this compile is to
> make the base class AbstractAuthentication's member variables 'theName'
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 WebLogic 7.0.
> :)
>
> I'll comment it and express some minor concerns especially with regards to
> various app servers in the coming days, but I thought I'd throw this out
> now.
>
> I tried to include a sample ear that has a basic example, but the war's
lib
> directory is too big and it bounced. So I've included the project, just
> adjust the jar file properties in build.xml to make it all work.
>
> Jason
>
>
>
> ------------------------------------------------------------------------
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
FormAuthentication.java
Description: Binary data
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
