Another option is to implement something in line with AppFuse's
UserSecurityAdvice which acts as a security interceptor on the save() method
of the UserManager - it prevents anyone who is not an Administrator from
modifying user details other than their own. Has the advantage that you do
not need to modify any model classes, has the disadvantage that it is likely
more complicated than the solution proposed by Rob. At the end of the day,
whatever works ;-)

Mike

On 11/19/07, Rob Hills <[EMAIL PROTECTED]> wrote:
>
> Hi Phillip,
>
> Philip Barlow wrote:
> > I'm just wondering is there a general solution to the following example:
> >
> > I pass a TeamId as a request parameter to a PersonAction to list all
> people
> > in a team with Person.TeamId=TeamId.
> >
> > However I want to stop a logged in user being able to manually change
> the
> > Team Id and look up people they do not have permission to view.
> >
> > Any pointers on this would be appreciated.
> >
> I've done something very similar in my current project where users
> belong to specific companies and I don't want users from one company to
> have access to another company's scope.
>
> The general pattern I used was:
>
> 1.   I added a Company attribute to the User entity.  To do this I
> needed to follow the AppFuse Core Classes tutorial:
> http://www.appfuse.org/display/APF/AppFuse+Core+Classes
>
> 2.   If you don't want to do anything fancy, it's simply a case then of
> checking the the currently logged in user's Company attribute (or in
> your case team attribute) to constrain anything they do accordingly.
>
> 3.   In my case, I needed to allow the system administrator to browse
> any Company's scope, so I store a Company entity in the Session and
> allow the administrator to change this to a company other than his/her
> own.
>
> It may be that with your app, a user can be a member of more than one
> team - that shouldn't present any problem, you simply model a
> many-to-many relationship - a bonus is that you'd probably get away
> without modifying the User entity.
>
> In my app, I created my own BaseAction that each of my Action classes
> extends.  I've put all my Company handling code in the BaseAction class
> so I don't have to incorporate the code into each action.
>
> HTH,
>
> Rob Hills
> Waikiki, Western Australia
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Reply via email to