shiro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Antoniazzi <nicolas.antonia...@gmail.com>
Subject Re: Permission on instance
Date Thu, 23 Dec 2010 17:33:28 GMT
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 <jared.bunting@digitalreasoning.com>

>  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" <nicolas.antoniazzi@gmail.com>
> 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.
>
>

Mime
View raw message