struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Shneyderman" <>
Subject RE: Looking for ideas for action servlet checking for logged in user.
Date Wed, 25 Jun 2003 11:33:04 GMT
> I have a webapp which have several pages which require the user to be
> logged in(have a httpSession with a "usercontainer" object stored) ,
and a
> few pages that doesn't require a log in(the log-in page, references,
> indexes...). All pages are fronted by actions.
> My current solution is to check for valid login in every action class
> needs to protect its invocation. That seems tedious. I though about
> extending the action servlet to do it, but then it would check for all
> requests.
> And I do want to distinguish between if the user is
> authorized(isUSerInRole) and if he/she is even logged in, so I can't
> the role parameter in the action element.
> My next idea is extending the action servlet pluss adding parameters
> can go into the action element in the struts-config.xml file.
> (some thing like <action path="/doImportantAction"
> usersession="true"> )
> This would require my action servlet to know about my userContainer
> in the httpsession. Pluss modifying the struts-config file.
> I haven't looked into how hard this is, figure I'd ask someone who's
> into this before.
> Any other good approaches, or should I just stick with what I
> individually in every action)

You do not have to check inidividually every action, I think. The way I
do my authentication/authorization is thru extending Action so I have
something like:

public abstract ProtectedAction extends Action {

protected authorize (...) {

public final ActionForward execute (...) {
   authorize (...);
   return pExecute (...);

public abstract pExecute (...) .... ;

now extend all your protected actions from ProtectedAction and all the
protected actions from the struts' acction. This gives you total
flexibility. If there are non trivial actions that do not fall under
your regular logic of authorize method you just override it for that

I am not sure if this is a good approach but seems to work for my
application. It probably will not integrate really well with other parts
and plugins, for example tiles. Since in tiles you can disable a whole
tile based on role the user has. But from what I understand, you would
need container managed user/role management.

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

View raw message