struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Hardy <>
Subject Re: Security in Struts
Date Sun, 29 May 2005 23:32:27 GMT
what put you off CMA?

if you don't mind me asking.

On 28/05/05 19:00&nbsp;Eddie Bush wrote:
> Tarek,
> Java provides a standard mechanism for you to tell if the person 
> accessing your application has a certain permission.  This is available 
> through request.isUserInRole(String).  Unfortunately, that only works 
> for Container-Managed Authentication (CMA).  You can make it work 
> without using CMA, but it takes a little (not too much) work.
> Firstly, a Filter instance that is mapped to all your actions (and JSPs 
> if you access them directly and they need security).  This filter is 
> really simple - if the user isn't authenticated, it sends them to the 
> login page. If they are authenticated, the filter lets them pass 
> through.  There is one additional responsibility that I'll address later.
> Your login process authenticates your users and puts a bean out in the 
> session to indicate the person is logged in - which is how your Filter 
> knows they are logged in.  I would recommend to you that the class for 
> this bean implement, since you can then use 
> request.getUserPrincipal() to retrieve your bean (caveat later).  Your 
> login process will, additionally, determine the permissions that the 
> person logging in has and make those available somehow in the session 
> (my user bean actually stores these).
> Now, the caveat I spoke of:
> To make request.getUserPrincipal() and request.isUserInRole(String) 
> work, you're going to have to write an HttpServletRequestWrapper 
> implementation. This is very straight-forward and shouldn't take long.  
> What you do here is to implement getUserPrincipal() to return the user 
> bean after having retrieved it from the session - under the key you 
> bound it to in your login process.  Piece of cake!  You'll also overload 
> isUserInRole(String) to retrieve the users roles and determine if the 
> passed-in parameter is in their list of roles.  Again - piece of cake!
> Your Filter's additional responsibility:
> Before calling doChain(request, response), you'll want to wrap the 
> request with an instance of your request wrapper.  This is the trick 
> (aka Magic!) that makes your application able to use standard methods 
> available on the request.
> It sounds kind of cumbersome - complex, even - but once you start down 
> the road, you'll soon see that it isn't much work at all.  You *might* 
> spend a day on all of this - two or three if you're totally unfamiliar 
> with everything I've spoken about and have to do some research.  This is 
> - far and above - the best approach, but there's actually one better, if 
> you can use it:
> Essentially, the security filter project does what I just said you 
> needed to do, but it doesn't provide database access to all RDBMS yet.  
> Depending on how closely you want to simulate CMA and depending on if 
> they have an adapter for your RDBMS, you might be better off 
> implementing what I spoke of above yourself.  For me, I wanted to see 
> what role a person had inside of an action.  It was easier for me to 
> grow my own than write an adapter and have to learn how to use 
> SecurityFilter.  That may not be the case for you.
> Hope that helps!
> Eddie Bush

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

View raw message