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 >
