Personally, I'd lean towards having showSales.action always show a report specific to the current user.
Then the manager wouldn't click on showSales.action. She'd click on showSalesSummary.action which would have a completely customized query. -Brian On Tue, Dec 28, 2010 at 3:25 PM, <stanl...@gmail.com> wrote: > Dave is right in that there are truly a dozen ways to do this. However, > Struts does not have an out-of-the-box solution governing user/role level > permissions. Does your company have a user user based permissions system > in > house today where permissions are determined according to the user logged > in? You should be able to latch into it with a Struts 2 interceptor and do > with the requests only what is authorized. I worked in a shop that > integrated a home-grown LDAP back end security system via a Struts 2 > interceptor where the specific URL was a feature that a user had to be > specifically authorized to. I thought it was crazy, however, if you want > short employees to only access short reports while tall employees can run > slightly longer reports, you sort of have to bite the bullet somewhere. > > Peace, > Scott > > On Tue, Dec 28, 2010 at 11:49 AM, Amol Ghotankar <ghotankaru...@gmail.com > >wrote: > > > I can elaborate on the requirement as follows, > > > > Assume a simple action which is authorized to be called by sales dept > > people > > only. i.e showSales.action > > > > When a user from purchase dept tries to call this action then, an > > interceptors will check whether the user in role has the authorization to > > access or not and deny access to purchase dept user to access this action > > this is simple. > > > > I have implemented this using before advice of Spring AOP rather than > > interceptor. I hope i am not wrong? > > > > But the bigger problem is > > > > By how much, I mean for eg. if an *sales execute *logs in and clicks > > showSales.action then he must be get view of his own sales list, but > > when *sales > > manager* logs in and calls same action i.e showSales.action then he must > > get > > more* bigger n wider list, which can be union of data from all sales > > executives. > > > > Here authorization of some kind must be implemented which intercepts > DAO's > > and automatically sets the "where clause" in the sql query. > > > > I tried before advice of spring for DAO's also but problem is if where > > clause is set somewhere within business logic then double where clause is > > set which gives error and because I am using hibernate criteria's to set > > restrictions on queries I have noticed this hibernate critera's are > > immutable* (Is there anyway to change them?) > > > > > > what should be the best way to solve this problem. Any Design Pattern > > or s*omething > > in struts that can help me here* or something other advice for it? > > > > > > > > > > On Tue, Dec 28, 2010 at 10:01 PM, Dave Newton <davelnew...@gmail.com> > > wrote: > > > > > On Tue, Dec 28, 2010 at 11:10 AM, Amol Ghotankar < > > ghotankaru...@gmail.com > > > >wrote: > > > > > > > Even I am searching for some better way in which authentication can > be > > > done > > > > using struts2 or spring security toghether. > > > > > > > > No direct or simple example to explain it working together. > > > > > > > > Specially for these two cases where > > > > > > > > 1. which user can access which action, is stored in database -> > > > > authorization table > > > > 2. which user can access how much data from a table in database, is > > > > decided > > > > by authorization logic. > > > > > > > > How to implement this any example or references welcomed. > > > > > > > > > > There are essentially unlimited ways this can be implemented. > > > > > > It also depends what technology you want to use. I haven't used Spring > > > Security for some time, so I won't be much help there, but I *do* know > > it's > > > incredibly granular and flexible, occasionally a bit too much so for my > > > taste, but it can be made to look simple. > > > > > > "How much" data can be accessed has multiple meanings: do you mean > > > *quantity* of data? I've never even considered trying to implement > that. > > > *Which* data would be handled the same way as everything else, however > > it's > > > being handled. > > > > > > When I've dealt with legacy authentication mechanisms I usually just do > > > something like a filter/interceptor that checks the action for an > > > annotation > > > (or a known action method naming convention to map action method => > > access > > > control). After the user logs in their user info is available in the > > > session, and if they're allowed access the interceptor just moves > along, > > > and > > > if they're not, they're redirected somewhere reasonable. > > > > > > For Spring Security stuff I would refer you to the Spring > documentation, > > > since it's not directly related to Struts 2. > > > > > > Dave > > > > > > > > > > > -- > > > > > > With Best Regards, > > > > Amol Ghotankar > > Cursive Technologies Pvt. Ltd. > > www.cursivetech.com > > >