Thanks Jared, It's interresting. This was my first idea, but how to handle the fact that severals users have access to the same permission on the item. 1 - user that is the original creator of document can delete it (ok with your code) 2 - admin user should be allowed to delete the document too (so, you have to add this case in the code)... 3 ... Maybe other roles should have the right of deleting it too... It could become a bit hard to maintain.
2010/12/23 Jared Bunting <[email protected]> > I can tell you what I am currently doing to handle this situation, but I > too am curious if there is a better way. > > I have two slightly different situations that I am handling differently. > > In the first, we’ll call the item “dataStore” - there are only a few of > them (but still created dynamically by the application), and users have > different access to individual ones depending on if they’re added as data > consumers or data creators (read/write). For this, I have simply > customized my realm logic to build permissions based on a separate table. > For any users in the data_store_reader table, they get the permission: > dataStore:read:id1,id2,id5 – where the ids are the names of datastores that > they have access to. > > In the second, we’ll call the item “document”. There are lots of them, > they’re created and deleted all the time. Only the original creator has > access to them. For this situation, I have ignored the concept of > permissions altogether. In the item methods themselves (either directly, or > via aop, I haven’t decided which is best, it probably depends on the exact > situation) I simply do something along the lines of: > > If(!SecurityUtils.getSubject().isAuthenticated()) { > throw new UnauthenticatedException(“User must be logged in to access > documents.”); > } else > If(!this.getOwner().equals(SecurityUtils.getSubject().getPrincipal()) { > throw new UnauthorizedException(“Document “ + this.getId() + “ is not > owned by “ + SecurityUtils.getSubject().getPrincipal()); > } > > I’d be happy to further discuss any techniques and would love to hear from > anyone else regarding other/better ways of approaching this sort of > situation. > > Thanks, > Jared > > > On 12/23/10 7:39 AM, "Nicolas Antoniazzi" <[email protected]> > wrote: > > Hello, > > I am using shiro for the server side of a gwt application. I did not find a > clear explanation in the documentation about instance permission handling. > My permissions are stored in a database. With a users_roles table and a > roles_permissions table. > > The doc says that we can use instance level for permission > ("item:delete:13") with the WildcardPermission default system, where 13 is > the ID of the item. > > Now, my question is : > 1 - how to associate levels to permissions ? Do I have to store the > permission name + the level (edit, create, delete, ...) in the > roles_permissions table ? > example : > admin | item:create > admin | item:delete > admin | item:edit > > 2 - how to set up the instance access ? > If I grant access to everything, I suppose that I could something like : > (if previous example is correct) > admin | item:create:* > admin | item:delete:* > admin | item:edit:* > > But if I only want to grant edit access on an item to users that have > created this item, how can I do ? I suppose that there should have a method > to overload somewhere but I am a bit lost. > > Thanks, > Nicolas. > >
