Hi,
Role based permissions works best for coarse grained permissions.
Having a generic ProjectManager role works well when you want to give
permissions to all projects.
When you want to do permissions at an instance level - projectA ,
projectB , projectC and so on
you are better of associating the permissions directly with user.
You would associate
User1 has permissions
project:edit:project_a
project:view:project_b
User2 has permissions
project:view:Project_a
project:edit:project_b
If you try to do instance specific permission using roles, you will
need to create many roles like
ProjectManagerforA, ConsultantforA .. and so on.
Hope that helps
Manoj
On Tue, Oct 18, 2011 at 6:32 AM, thlim <[email protected]> wrote:
> Knowing that Shiro allows me to define permissions onto an instance, for e.g.
> "project:edit:project_a", is there another way to do this differently?
>
> For e.g., he is the Project Manager for Project A and he is allowed to
> edit/view/delete Project A properties. However, he's is a Consultant who can
> only view Project B. Given this scenario, I will assign him the Project
> Manager and Consultant roles. Given how Shiro checks permissions (or how I
> understood it), Shiro would allow him to edit Project B as well. How to I
> limit his Project Manager role (along with the permissions) to Project A
> without having to copying multiple permissions e.g.
> "project:edit:project_c", "project:edit:project_d" for different projects
> where he is also the Project Manager.
>
> Please advice
>
> Thanks
>
> /lim/
>
>
>
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/Adding-Scope-to-Permission-Check-tp6904602p6904602.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>
--
http://khangaonkar.blogspot.com/
