You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Erik Price <ep...@ptc.com> on 2003/05/19 17:29:29 UTC
two-step container managed authentication
Hi,
I am soliciting advice from other struts and web developers. I am
moving my in-progress project (JSP & servlets only) to Struts framework
after having been converted at a JUG meeting, and am planning things
out. One of the things I would like to do is move from my current
security model (which uses a homebrewed authentication filter) to
container-managed authorization/authentication. However, I would like
to perform two steps in the login and am not sure if this is possible
with CMA.
When a user requests a resource of the webapp, a login (form-based auth)
should be presented, and the user enters username and password. The
authorization is performed against LDAP (partly the motivation to move
from my security filter to container-managed auth is to make JNDI/LDAP
auth easier to set up). If the user authorizes successfully, then a
*second* step is performed -- authenticate against a local (non-LDAP)
database of registered users. If the user's name is present in this
database, fine, log in as normal. However, if the username is not
present in this database, then the user must be requesting an account to
use this webapp: execute the NewUserRequestAction.
This is something I can easily do with my filter, simply by implementing
the code myself. But is it possible to do with container-managed
authorization? Any suggestions? BTW I would like to perform all of
this within a single HTTP request so that there is no opportunity for
the user to change the username after authorizing against LDAP but
before querying the database.
Thanks,
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: two-step container managed authentication
Posted by Erik Price <ep...@ptc.com>.
Adam Hardy wrote:
> A possible enhancement (assuming that the filter will work directly
> after the CMS returns) - it would save user interaction if you
> automatically imported the user's account, rather than asking if they
> want to do that.
Well, that's a good point, but I sort of simplified my actual intent.
What will actually happen if a user isn't registered is a message will
be added to a queue so that an administrator will be made aware that
there is a request for a new account from user X, and the adminstrator
will approve or reject the account creation. Since the application will
not be used by a large number of users this is do-able.
Thanks Adam.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: two-step container managed authentication
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
A possible enhancement (assuming that the filter will work directly
after the CMS returns) - it would save user interaction if you
automatically imported the user's account, rather than asking if they
want to do that.
At my last project, we imported a Lotus Notes LDAP directory every
midnight into the app so that all the potential users were already set
up. We still authenticated against Lotus Notes though.
Erik Price wrote:
>
>
> Adam Hardy wrote:
>
>> The heavy bit about JAAS was working out how it worked. Lots of two
>> headed toad toads with red eyes. But I got the hang of it and it is
>> actually not a complex framework (at least until you add in 3 or 4
>> different login modules with different priorities accessing different
>> LDAP directories)
>>
>> The native java JAAS classes apparently have an LDAP login module
>> class ready and waiting. I didn't look at it though so it might not be
>> what you need.
>
>
> Hmm... I think I'm going to hold off on JAAS for the moment, in case I
> can come up with something simpler to implement (see below). Thanks for
> your input though.
>
>> A quick test shows that j_username is lost from the request after
>> j_security_check is done. I think a servlet dumps the login request
>> and reincarnates the original request that prompted the security
>> check. Might be wrong though.
>
>
> Right, relying on the j_username still being present might not be very
> reliable. However, I think this might work:
>
> 0. There is a resource protected by MyOwnSecurityFilter and the user
> requests it.
> 1. container managed authorization intercepts request for the resource
> and redirects to the login page.
> 2. user fills out login page, which authorizes against LDAP server
> successfully
> 3. now the user is headed for the resource but this time
> MyOwnSecurityFilter intercepts the request.
> 4. MyOwnSecurityFilter calls "request.isUserInRole(role)" to determine
> if the user already exists in the database as a member of the Role.
> 5. If the user is in the role, they go to the resource, if not, then the
> filter sends the user to the "please register for this application" screen.
>
> So, in summary, container-managed auth is used to make sure that the
> user is in LDAP at all, and then a filter is used to redirect the user
> to register for the application if they are not yet registered. I would
> like to do this to enforce two levels of access, one for barring *all*
> entry to the application to non-LDAP users, and two for providing a
> means for users to request application-specific accounts.
>
> Can anyone see any holes in this approach? Will container-managed auth
> reliably pass control on to a Filter if a Filter is mapped to a resource?
>
>
> Thanks for any suggestions.
>
> Erik
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: two-step container managed authentication
Posted by Erik Price <ep...@ptc.com>.
Adam Hardy wrote:
> The heavy bit about JAAS was working out how it worked. Lots of two
> headed toad toads with red eyes. But I got the hang of it and it is
> actually not a complex framework (at least until you add in 3 or 4
> different login modules with different priorities accessing different
> LDAP directories)
>
> The native java JAAS classes apparently have an LDAP login module class
> ready and waiting. I didn't look at it though so it might not be what
> you need.
Hmm... I think I'm going to hold off on JAAS for the moment, in case I
can come up with something simpler to implement (see below). Thanks for
your input though.
> A quick test shows that j_username is lost from the request after
> j_security_check is done. I think a servlet dumps the login request and
> reincarnates the original request that prompted the security check.
> Might be wrong though.
Right, relying on the j_username still being present might not be very
reliable. However, I think this might work:
0. There is a resource protected by MyOwnSecurityFilter and the user
requests it.
1. container managed authorization intercepts request for the resource
and redirects to the login page.
2. user fills out login page, which authorizes against LDAP server
successfully
3. now the user is headed for the resource but this time
MyOwnSecurityFilter intercepts the request.
4. MyOwnSecurityFilter calls "request.isUserInRole(role)" to determine
if the user already exists in the database as a member of the Role.
5. If the user is in the role, they go to the resource, if not, then the
filter sends the user to the "please register for this application" screen.
So, in summary, container-managed auth is used to make sure that the
user is in LDAP at all, and then a filter is used to redirect the user
to register for the application if they are not yet registered. I would
like to do this to enforce two levels of access, one for barring *all*
entry to the application to non-LDAP users, and two for providing a
means for users to request application-specific accounts.
Can anyone see any holes in this approach? Will container-managed auth
reliably pass control on to a Filter if a Filter is mapped to a resource?
Thanks for any suggestions.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: [OT] two headed toad toads with red eyes - viral meme?
Posted by Andrew Hill <an...@gridnode.com>.
<snip>
Is the mailing list being invaded by struts coding herpetologists or what?
</snip>
Si Baroni!
...Perhaps someone should call DangerMouse and his trusty assistant Penfold
to come deal with all these toads?
...or maybe I should just go home and get some sleep....
-----Original Message-----
From: Jim Krygowski [mailto:james.krygowski@shaws.com]
Sent: Tuesday, 20 May 2003 01:26
To: Struts Users Mailing List
Subject: [OT] two headed toad toads with red eyes - viral meme?
Hey-
Is the mailing list being invaded by struts coding herpetologists or what?
Seriously, can someone explain the etymology of this "two headed toad toads
with red eyes" thing? I've spotted it in a few posts recently and I'm
curious to know what culture, literature, etc. gave birth to this phrase.
> -----Original Message-----
> From: Adam Hardy [mailto:ahardy.struts@cyberspaceroad.com]
> Sent: Monday, May 19, 2003 1:12 PM
> To: Struts Users Mailing List
> Subject: Re: two-step container managed authentication
>
>
> The heavy bit about JAAS was working out how it worked. Lots of two
> headed toad toads with red eyes. But I got the hang of it and it is
> actually not a complex framework (at least until you add in 3 or 4
> different login modules with different priorities accessing different
> LDAP directories)
>
> The native java JAAS classes apparently have an LDAP login module class
> ready and waiting. I didn't look at it though so it might not be what
> you need.
>
> A quick test shows that j_username is lost from the request after
> j_security_check is done. I think a servlet dumps the login request and
> reincarnates the original request that prompted the security check.
> Might be wrong though.
>
> Erik Price wrote:
> >
> >
> > Adam Hardy wrote:
> >
> >> Last time I had a conversation about this, it got very off-topic
> >> quickly, because it's much more tomcat than struts. Struts does tie in
> >> with CMA via struts' ability to specify roles as security constraints
> >> on action mappings though.
> >
> >
> > Well, actually I had considered prefixing OT because it does seem
> > unrelated, but then I wondered if perhaps the solution is to
> incorporate
> > an Action that does this somehow (which would seem more Strutsish)? In
> > other words, something like:
> >
> > - Incoming request for resource is intercepted by container managed
> > authorization
> > - Authorization is performed against JNDI/LDAP
> > - If authorization is successful, proceed to LoginAction
> > - LoginAction checks if the user exists in the DB and takes appropriate
> > steps depending (presumably the "j_username" form data is still
> > available to the Action?)
> >
> > ... since at this point, JAAS sounds a bit heavy for my needs (although
> > certainly useful if my project were larger in scale). I would be
> > interested in hearing what you have to say about it when you're done
> > digging through it, though.
> >
> > Just not sure if the above will actually work, or if there are better
> > strategies.
> >
> >
> > Erik
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
[OT] two headed toad toads with red eyes - viral meme?
Posted by Jim Krygowski <ja...@shaws.com>.
Hey-
Is the mailing list being invaded by struts coding herpetologists or what?
Seriously, can someone explain the etymology of this "two headed toad toads
with red eyes" thing? I've spotted it in a few posts recently and I'm
curious to know what culture, literature, etc. gave birth to this phrase.
> -----Original Message-----
> From: Adam Hardy [mailto:ahardy.struts@cyberspaceroad.com]
> Sent: Monday, May 19, 2003 1:12 PM
> To: Struts Users Mailing List
> Subject: Re: two-step container managed authentication
>
>
> The heavy bit about JAAS was working out how it worked. Lots of two
> headed toad toads with red eyes. But I got the hang of it and it is
> actually not a complex framework (at least until you add in 3 or 4
> different login modules with different priorities accessing different
> LDAP directories)
>
> The native java JAAS classes apparently have an LDAP login module class
> ready and waiting. I didn't look at it though so it might not be what
> you need.
>
> A quick test shows that j_username is lost from the request after
> j_security_check is done. I think a servlet dumps the login request and
> reincarnates the original request that prompted the security check.
> Might be wrong though.
>
> Erik Price wrote:
> >
> >
> > Adam Hardy wrote:
> >
> >> Last time I had a conversation about this, it got very off-topic
> >> quickly, because it's much more tomcat than struts. Struts does tie in
> >> with CMA via struts' ability to specify roles as security constraints
> >> on action mappings though.
> >
> >
> > Well, actually I had considered prefixing OT because it does seem
> > unrelated, but then I wondered if perhaps the solution is to
> incorporate
> > an Action that does this somehow (which would seem more Strutsish)? In
> > other words, something like:
> >
> > - Incoming request for resource is intercepted by container managed
> > authorization
> > - Authorization is performed against JNDI/LDAP
> > - If authorization is successful, proceed to LoginAction
> > - LoginAction checks if the user exists in the DB and takes appropriate
> > steps depending (presumably the "j_username" form data is still
> > available to the Action?)
> >
> > ... since at this point, JAAS sounds a bit heavy for my needs (although
> > certainly useful if my project were larger in scale). I would be
> > interested in hearing what you have to say about it when you're done
> > digging through it, though.
> >
> > Just not sure if the above will actually work, or if there are better
> > strategies.
> >
> >
> > Erik
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: two-step container managed authentication
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
The heavy bit about JAAS was working out how it worked. Lots of two
headed toad toads with red eyes. But I got the hang of it and it is
actually not a complex framework (at least until you add in 3 or 4
different login modules with different priorities accessing different
LDAP directories)
The native java JAAS classes apparently have an LDAP login module class
ready and waiting. I didn't look at it though so it might not be what
you need.
A quick test shows that j_username is lost from the request after
j_security_check is done. I think a servlet dumps the login request and
reincarnates the original request that prompted the security check.
Might be wrong though.
Erik Price wrote:
>
>
> Adam Hardy wrote:
>
>> Last time I had a conversation about this, it got very off-topic
>> quickly, because it's much more tomcat than struts. Struts does tie in
>> with CMA via struts' ability to specify roles as security constraints
>> on action mappings though.
>
>
> Well, actually I had considered prefixing OT because it does seem
> unrelated, but then I wondered if perhaps the solution is to incorporate
> an Action that does this somehow (which would seem more Strutsish)? In
> other words, something like:
>
> - Incoming request for resource is intercepted by container managed
> authorization
> - Authorization is performed against JNDI/LDAP
> - If authorization is successful, proceed to LoginAction
> - LoginAction checks if the user exists in the DB and takes appropriate
> steps depending (presumably the "j_username" form data is still
> available to the Action?)
>
> ... since at this point, JAAS sounds a bit heavy for my needs (although
> certainly useful if my project were larger in scale). I would be
> interested in hearing what you have to say about it when you're done
> digging through it, though.
>
> Just not sure if the above will actually work, or if there are better
> strategies.
>
>
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: two-step container managed authentication
Posted by Erik Price <ep...@ptc.com>.
Adam Hardy wrote:
> Last time I had a conversation about this, it got very off-topic
> quickly, because it's much more tomcat than struts. Struts does tie in
> with CMA via struts' ability to specify roles as security constraints on
> action mappings though.
Well, actually I had considered prefixing OT because it does seem
unrelated, but then I wondered if perhaps the solution is to incorporate
an Action that does this somehow (which would seem more Strutsish)? In
other words, something like:
- Incoming request for resource is intercepted by container managed
authorization
- Authorization is performed against JNDI/LDAP
- If authorization is successful, proceed to LoginAction
- LoginAction checks if the user exists in the DB and takes appropriate
steps depending (presumably the "j_username" form data is still
available to the Action?)
... since at this point, JAAS sounds a bit heavy for my needs (although
certainly useful if my project were larger in scale). I would be
interested in hearing what you have to say about it when you're done
digging through it, though.
Just not sure if the above will actually work, or if there are better
strategies.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: two-step container managed authentication
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
I have just been looking at this myself. CMA is based on realms and at
present there are several realm solutions in tomcat.
one solution is pure LDAP, although I am afraid you wouldn't be able to
configure it to manage your second requirement with the extra login.
There is no hook to allow you to step in and do the second login.
Secondly though there is a prototype JAAS realm manager in tomcat which
allows you to write your own login module, which would be give you
leeway to do all you want. Check out the tomcat realm-HOWTO docs and
Sun's JAAS authentication tutorial. I just ploughed thro' it all to sort
out what is what and I'm trying to document it for myself at the moment.
Give me an hour and you can have a look if you want.
Alternatively you could override the catalina LDAP realm class.
Last time I had a conversation about this, it got very off-topic
quickly, because it's much more tomcat than struts. Struts does tie in
with CMA via struts' ability to specify roles as security constraints on
action mappings though.
Adam
Erik Price wrote:
> Hi,
>
> I am soliciting advice from other struts and web developers. I am
> moving my in-progress project (JSP & servlets only) to Struts framework
> after having been converted at a JUG meeting, and am planning things
> out. One of the things I would like to do is move from my current
> security model (which uses a homebrewed authentication filter) to
> container-managed authorization/authentication. However, I would like
> to perform two steps in the login and am not sure if this is possible
> with CMA.
>
> When a user requests a resource of the webapp, a login (form-based auth)
> should be presented, and the user enters username and password. The
> authorization is performed against LDAP (partly the motivation to move
> from my security filter to container-managed auth is to make JNDI/LDAP
> auth easier to set up). If the user authorizes successfully, then a
> *second* step is performed -- authenticate against a local (non-LDAP)
> database of registered users. If the user's name is present in this
> database, fine, log in as normal. However, if the username is not
> present in this database, then the user must be requesting an account to
> use this webapp: execute the NewUserRequestAction.
>
> This is something I can easily do with my filter, simply by implementing
> the code myself. But is it possible to do with container-managed
> authorization? Any suggestions? BTW I would like to perform all of
> this within a single HTTP request so that there is no opportunity for
> the user to change the username after authorizing against LDAP but
> before querying the database.
>
>
> Thanks,
>
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: two-step container managed authentication
Posted by Erik Price <ep...@ptc.com>.
Hi John, thanks for responding.
I think that what I will do (if I ever get to that stage of this
project, right now I'm still working on domain layer), is use CMA via
JNDI (JNDIRealm) to authenticate against LDAP. Then, if the
authentication proves successful, the HTTP request continues to the
webapp where it is intercepted by a filter, which performs
authentication against the app-specific DB (with its own username list).
Then, if authentication is successful, the user is logged in and goes
wherever they were headed -- but if not, they are redirected to an
Action where they can fill out a form to request an app-specific account.
I'll post here if I'm able to get that up and running, though again,
right now I'm focused on another part of the code.
Erik
PS: interesting -- you got this email pretty late?
John Tangney wrote:
> The way CMA works, the auth happens completely transparently. That is, auth
> happens before your app even sees the HttpRequest.
>
> If you want to do a second auth-like thing with that request, the you'd set
> up an action to do so.
>
> Note that the CMA can access the same db tables as the rest of the app,
> using a JDBCRealm (rather than JNDI.) But I guess you want to maintain
> separate lists of users, right?
>
> Sorry if this is not much help. If you could explain the use case(s) a
> little, maybe we can help come up with an architecture that'll do the trick.
>
> --johnt
> Strictly speaking this is OT, since CMA is not a Struts thing, but who ya
> gonna ask? ;->
>
> in article 3EC8F859.8060504@ptc.com, Erik Price at eprice@ptc.com wrote on
> 5/19/03 8:29 AM:
>
>
>>Hi,
>>
>>I am soliciting advice from other struts and web developers. I am
>>moving my in-progress project (JSP & servlets only) to Struts framework
>>after having been converted at a JUG meeting, and am planning things
>>out. One of the things I would like to do is move from my current
>>security model (which uses a homebrewed authentication filter) to
>>container-managed authorization/authentication. However, I would like
>>to perform two steps in the login and am not sure if this is possible
>>with CMA.
>>
>>When a user requests a resource of the webapp, a login (form-based auth)
>>should be presented, and the user enters username and password. The
>>authorization is performed against LDAP (partly the motivation to move
>>from my security filter to container-managed auth is to make JNDI/LDAP
>>auth easier to set up). If the user authorizes successfully, then a
>>*second* step is performed -- authenticate against a local (non-LDAP)
>>database of registered users. If the user's name is present in this
>>database, fine, log in as normal. However, if the username is not
>>present in this database, then the user must be requesting an account to
>>use this webapp: execute the NewUserRequestAction.
>>
>>This is something I can easily do with my filter, simply by implementing
>>the code myself. But is it possible to do with container-managed
>>authorization? Any suggestions? BTW I would like to perform all of
>>this within a single HTTP request so that there is no opportunity for
>>the user to change the username after authorizing against LDAP but
>>before querying the database.
>>
>>
>>Thanks,
>>
>>Erik
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: two-step container managed authentication
Posted by John Tangney <jo...@jdtangney.com>.
The way CMA works, the auth happens completely transparently. That is, auth
happens before your app even sees the HttpRequest.
If you want to do a second auth-like thing with that request, the you'd set
up an action to do so.
Note that the CMA can access the same db tables as the rest of the app,
using a JDBCRealm (rather than JNDI.) But I guess you want to maintain
separate lists of users, right?
Sorry if this is not much help. If you could explain the use case(s) a
little, maybe we can help come up with an architecture that'll do the trick.
--johnt
Strictly speaking this is OT, since CMA is not a Struts thing, but who ya
gonna ask? ;->
in article 3EC8F859.8060504@ptc.com, Erik Price at eprice@ptc.com wrote on
5/19/03 8:29 AM:
> Hi,
>
> I am soliciting advice from other struts and web developers. I am
> moving my in-progress project (JSP & servlets only) to Struts framework
> after having been converted at a JUG meeting, and am planning things
> out. One of the things I would like to do is move from my current
> security model (which uses a homebrewed authentication filter) to
> container-managed authorization/authentication. However, I would like
> to perform two steps in the login and am not sure if this is possible
> with CMA.
>
> When a user requests a resource of the webapp, a login (form-based auth)
> should be presented, and the user enters username and password. The
> authorization is performed against LDAP (partly the motivation to move
> from my security filter to container-managed auth is to make JNDI/LDAP
> auth easier to set up). If the user authorizes successfully, then a
> *second* step is performed -- authenticate against a local (non-LDAP)
> database of registered users. If the user's name is present in this
> database, fine, log in as normal. However, if the username is not
> present in this database, then the user must be requesting an account to
> use this webapp: execute the NewUserRequestAction.
>
> This is something I can easily do with my filter, simply by implementing
> the code myself. But is it possible to do with container-managed
> authorization? Any suggestions? BTW I would like to perform all of
> this within a single HTTP request so that there is no opportunity for
> the user to change the username after authorizing against LDAP but
> before querying the database.
>
>
> Thanks,
>
> Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org