I adopted the caching approach. Upon successful user login, I scan my permission project-group access mapping table and add all the possible permissions to a SimpleAuthorizationInfo which is then added to Shiro session.
Also the permission are in following format "userx:update,delete,edit:1,2,3,4,5 (not individual permission string for each privilege). The doGetAuthorizationInfo then just returns this. I did not change the isPermitted or an other methods. I am hoping that it will not create performance issues since I have a rather small user base. Again - I haven't fully tested this approach to know its strengths and weaknesses. On Wed, Aug 21, 2013 at 10:13 PM, otter606 [via Shiro User] < [email protected]> wrote: > Hello, > > We subclassed Wildcard permission to develop a way to store richer > instance based permissions. > We store the permissions as Strings, but have methods such as > addIdRestriction, addDateRangeRestriction, addPropertyRestriction, > etc. So users can be given read access to documents created over a > given date range, for example. > > I always say that our approach is essentially home-grown and I > hesitate to recommend it unreservedly as we have not thoroughly tested > the performance of this approach for large numbers of rows. Having > said that, other people have asked similar questions recently and as > far as I'm aware there isn't an out-of-the-box solution in Shiro. > > Best wishes > Richard > > I > On 21 Aug 2013, at 19:59, Antti O. wrote: > > > I'm doing something similar - I need to do row level permission > > checks in my > > Grails application with Grails-Shiro-Plugin. I need some help > > getting my > > head around the permission check implementation. Below is a simple > > example > > on what I'm doing: > > > > Let's say I have domain objects like these: > > > > class Doc { > > Long id > > User owner > > } > > > > class User { > > Long id > > } > > > > A permission check in a service method: > > > > currentSubject.isPermitted("doc:update:${doc.id}") > > > > I'd like to have wildcard permission strings like this for the user. > > Maybe > > they would be read from a database table USER_ROLE_PERMISSIONS or > > something...: > > > > def perms = [ "doc:read:*", "doc:update,delete:owner=${userId}", > > "doc:save:*" ] > > > > The permission check implementation is in my DbRealm class. The > > Grails-Shiro-Plugin calls DbRealm.isPermitted() when a > > Subject.isPermitted() > > call is made: > > > > boolean isPermitted(principal, requiredPermission) { > > def perms = [ "doc:read:*", "doc:update,delete:owner=${principal}", > > "doc:save:*" ] > > def permission = perms?.find { > > Permission perm = shiroPermissionResolver.resolvePermission(it) > > return (perm.implies(requiredPermission)) > > } > > return (permission != null) > > } > > > > The permission check is the troublesome bit for me. > > - Should I subclass the WildcardPermission class and implement my own > > implies() method which could understand the notation for item owner > > id? > > - Should I build and cache the permissions for user in advance so > > that it > > would contain all possible items the user could access? Something > > like [ > > "doc:update:123", "doc:update:124", "doc:delete:123", "doc:delete: > > 124", ...] > > ? This seems like a runtime ACL. > > > > I can't be the first one doing this but I haven't found a simple > > solution > > yet. I'm trying to avoid creating something unnecessarily complex :) > > > > Regards, > > Antti > > > > > > > > -- > > View this message in context: > http://shiro-user.582556.n2.nabble.com/Best-Permission-Structure-e-g-User-departments-tp7578991p7579060.html > > > Sent from the Shiro User mailing list archive at Nabble.com. > > Richard Adams > [hidden email] <http://user/SendEmail.jtp?type=node&node=7579061&i=0> > > > > > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://shiro-user.582556.n2.nabble.com/Best-Permission-Structure-e-g-User-departments-tp7578991p7579061.html > To unsubscribe from Best Permission Structure (e.g. User departments), click > here<http://shiro-user.582556.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=7578991&code=YWhtYWRraGFuMThAZ21haWwuY29tfDc1Nzg5OTF8MTQ3NjgyMjE5Mw==> > . > NAML<http://shiro-user.582556.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- ------------------------------------ http://www.operationbadar.net -- View this message in context: http://shiro-user.582556.n2.nabble.com/Best-Permission-Structure-e-g-User-departments-tp7578991p7579062.html Sent from the Shiro User mailing list archive at Nabble.com.
