On Mon, Dec 6, 2010 at 11:11 AM, Les Hazlewood <[email protected]> wrote: > Do you envision this as existing in the Shiro API namespace, but > perhaps not interpreted by anything in Shiro at the moment? I.e. > adding it to Shiro so it can be 'common' among integrating frameworks? > I'm not entirely sure how Shiro core could support such a thing since > it requires knowledge of a data model (i.e. I don't know what would be > the 'bare bones support'). How would it be used and/or supported by > other frameworks? > Anything we can do to support this use case would be great - I'm just > trying to see how it would be used in practice so we can make it > useful in a generic way.
Yes, I'd envision the @RequiresAssociation go into shiro core, possibly accompanied with an enum for denoting the targeted CRUD-operation. Perhaps a getAssociation() helper for aspectj-module and whatever helpers you could possibly use together with Spring (say you put the annotation on a Spring bean and the association maps to a referenced bean by that name), sort of as a reference implementation. Not just like, but similar to how @RequiresPermission is currently handled. Kalle > On Mon, Dec 6, 2010 at 9:29 AM, Kalle Korhonen > <[email protected]> wrote: >> In my projects, I repeatedly find a need to express a permission rule >> for allowing the currently executing subject to access or modify an >> instance of a persistent type when the subject is in some way >> associated to the said instance. For example, a user should only be >> allowed update his own profile. I had implemented this >> association/instance based security concept for Trails framework (see >> http://trails.codehaus.org/Security+module) earlier and now, I'd like >> to be able to do the same for tapestry-security >> (http://tynamo.org/tapestry-security+guide). With the more flexible >> @RequiresPermissions you could theoretically implement much more >> complex association-based permission rules but in practice I've found >> that the security rules based on primary type's association to the >> executing subject solves at least 80% of the use cases, which could be >> expressed with a more specialized and simpler-to-use >> @RequiresAssociation annotation. >> >> I could simply implement @RequiresAssociation for tapestry-security >> only, but I would assume that it would be equally useful for Wicket >> and Grails and especially for any framework using Hibernate/JPA >> persistence because add-on security rules are easy to express with the >> criteria API. @RequiresAssociation could live in Shiro and have bare >> bones support for it similar to @RequiresPermissions. Shiro-based >> security libraries could then make more complete integrations with >> their favorite web framework, utilizing the same annotation. Would >> other Shiro devs and community find this useful and reasonable and >> worth implementing in the Shiro core itself? >> >> Kalle >
