This is similar to how we do permissions in our core app. Essentially, all of our permissions are generated from our domain model. The interesting fields tend to be owner and guest access.
-Jared On Nov 20, 2012 5:02 PM, "Richard Adams" <[email protected]> wrote: > Hi > > Nobody seems to have jumped in with an immediate answer, so here's a > brief explanation of how we're addressing these sorts of issues > in a web-based authoring tool. Of course this might not be a a 'good' > solution but maybe will get some discussion going and give you some ideas: > > We've extended the Shiro wildcard permissions filter to define permissions > in several ways as well as id. > For example, we can specify permissions based on object properties such as > document creation date, folder location, and ownership status. > So instead of a long list of document ids we might have something like > "document:edit:datefrom=2004-**02-19&dateTo=2006-02-19&group=**$self1&path=/a/b/c*". > This permission is applied to a user or group. $self is a variable that > means permission for the user who owns that permission, allowing re-use of > permissions. > > The permission would mean 'user can edit all documents in folder a/b/c or > any subfolder, that was last modified over a 2 year date range, that are > owned by anyone in a group that the user belongs to'' > > We then match this permission against the properties of records in the > database. E.g., in the Permission.implies(Permission ) method; the subject > is the permission under test, and the argument permission is an > implementation of Permission that holds the specific properties of the > record under test. > In our system users can inherit permissions from group membership, for > example - we just iterate over all permissions that a user has access to > until we find a match. > > We're actually just implementing this at the moment so I'm unable to say > if it's a great idea or not just now.... the idea is to avoid a whole > Access Control List implementation where every record has its own > permissions, but to be able to specify a broad range of permissions in a > few statements. > > Cheers > Richard > > > > > > > On 17 Nov 2012, at 10:53, Shiro4389273 wrote: > > Hi, >> I'd like to use shiro with a jdbc-realm to secure a example app... >> >> Now I don't find a solution/doc/tutorial how to implement my app so that a >> authenticated user can only see it's own data, e.g. a document... >> >> I've got my tables in the db, (roles, permissions, users, >> roles_permissions, >> users_roles) and as roles I've got >> "admin" and "user", now I thougt I can create permissions like >> "document:read", "document:write" and "document:delete" and the admin role >> gets "document:*" so that it can do all with all documents. >> >> But how to I set the user permissions only for it's own documents? >> E.g. a user has 3 documents, with unique ids, 4, 7, 12. >> So he should have a permission like "document:*:4,7,12". >> Is that right? >> But where do I have so store this permission? >> Or do I have to have to set this permission at runtime, like first select >> all docs where the user is owner and then set the permission dynamicly? >> >> >> Thx and Regards... >> >> >> >> -- >> View this message in context: http://shiro-user.582556.n2.** >> nabble.com/Permissions-on-**specific-Objects-tp7577956.**html<http://shiro-user.582556.n2.nabble.com/Permissions-on-specific-Objects-tp7577956.html> >> Sent from the Shiro User mailing list archive at Nabble.com. >> > > Richard Adams > [email protected] > > > >
