shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Hazlewood <lhazlew...@apache.org>
Subject Re: @RequiresAssociation
Date Mon, 06 Dec 2010 19:11:57 GMT
Hi Kalle,

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.

Thanks,

Les

On Mon, Dec 6, 2010 at 9:29 AM, Kalle Korhonen
<kalle.o.korhonen@gmail.com> 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

Mime
View raw message