Thanks Rob and Mike, I will take this advice on board and try to come up
with a solution that is right for our application.
Michael Horwitz wrote:
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]
<mailto:[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]
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
