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
> >
>

Reply via email to