> 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
that
> 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
use
> the role parameter in the action element.
> 
> My next idea is extending the action servlet pluss adding parameters
that
> can go into the action element in the struts-config.xml file.
> (some thing like <action path="/doImportantAction"
type="my.actionClass"
> usersession="true"> )
> This would require my action servlet to know about my userContainer
stored
> 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
run
> into this before.
> 
> Any other good approaches, or should I just stick with what I
got?(check
> 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
non
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
particular 
Action.

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to