Hi there, What are you trying to restrict exactly? Does your current implementation retrieve a bunch of log entries first and then tries to filter out the ones that can be seen by the current user?
WildcardPermissions work very well when you want to restrict things like performing an action with "all log entries" or "this exact log entry". They don't work so well if you need to apply restriction criteria, e.g."all log entries matching X criteria". That restriction criteria is _very_ domain/implementation specific. However, a custom implementation of the Permission interface could very well encapsulate the implication logic based on user id, report id and account id instead of using a WildcardPermission string. Implementing the interface is better suited for these more complex checks. You typically don't have to override the Realm methods since they depend on Permission.implies working correctly. But there is another way that kind of blurs the lines as to what should be delegated to the security subsystem and what should be handled by custom business logic. A security check for each individual log entry would obviously not scale well, so instead I would probably use the user's identity to proactively filter what they can see. For example, if using a relational database, instead of all log entries, get the ones for the accounts to which the user belongs: In SQL (psuedo code) "select all log entries where the log entry report's account id equals the current user's account id". Is this possible in your situation? Because of your intimate knowledge of the business requirements and the domain model, you can have a view that shows only what they're allowed to see in a very efficient manner. You can still have a security check before executing the query, but it would be more akin to "can they see log entries for account 12345", and then if they can, execute that query. I tend to think of the security checkpoints in code as doorways to business logic: can you enter the door or not to get to some functionality? Filtering lists of individual items by a security check doesn't make as much sense to me personally - it feels more like a door to each line item for display which seems very heavyweight. Proactive filtering (sql, preemptive caching, NoSQL, whatever) are often much better suited for filtering logic. Does this make sense? HTH, Les P.S. cc'ing to the Shiro user list as this is not grails-specific and can help others there too. On Sun, Mar 21, 2010 at 6:34 AM, fatzopilot <[email protected]> wrote: > > Looks promising, thanks. > There is one thing I am unsure how to proceed best. > I have the following set-up > > Account > |__User > |__Report > |__LogEntry > > So everything is somehow related to Account. In case of the LogEntry, this > is a transitive relation via Report. Now it should be ensured that a user > can only see the LogEntries that belong to the Account that he also belongs > to. > The idea was to implement a new Realm with customized isPermitted(principal, > requiredPermission) and to see whether User (principal) and LogEntry > (encoded in requiredPermission) coalesce in Account. > AFAICS this would need to restore the LogEntry from the requiredPermission, > which is a WildCardPermission. However, I do not see how this can be done > other than reparsing the toString method return value of the > WildCardPermission. > > Is that what you would do in this case? > Thanks > fatzopilot > -- > View this message in context: > http://n4.nabble.com/Securing-instances-with-Shiro-but-without-ACLs-tp1589767p1676663.html > Sent from the Grails - user mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
