shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kalle Korhonen <kalle.o.korho...@gmail.com>
Subject Re: Unauthorized URL for different entries in filter chain
Date Sun, 26 Jun 2011 20:45:55 GMT
For 2.0, the third approach would be to have each multiples instances
of the same filter, each carrying its own configuration. That way, you
wouldn't constantly need to write and read request attributes. It'd
would simplify things and allow more flexibility (disabling specific
filter instances etc.). We had a long discussion on that with Les in a
different thread, but so far he was opposing the idea. I've
implemented the concept for the purposes of tapestry-security module
(http://tynamo.org/tapestry-security+guide).

Kalle


On Sun, Jun 26, 2011 at 12:14 PM, Les Hazlewood <lhazlewood@apache.org> wrote:
> Hi Alan,
>
> Yep, that's one of two ways I can see this working (although I'd
> probably represent the string a bit differently - see below).
>
> Approach #1:
>
> Have url configurable on a per-request (e.g. per path) basis like
> you've shown, available to any of the AuthorizationFilter subclasses.
>
> I'd probably represent this as a named key/value pair in the config
> string, e.g.:
>
> /whatever/** = someFilter, roles[admin, unauthzUrl=/service/notadmin.jsp]
>
> This way the string is a bit more specific and allows any configurable
> property to be configured no matter the order it is written.  A little
> nicer so people don't need to remember a particular string format or
> potentially leave empty spaces if other fields are introduced in the
> future (e.g. admin||somethingElse)
>
> I believe this approximates more of what the 2.0 codebase will probably be like.
>
> Approach #2:
>
> Have a filter that configures the URL as a request attribute so any
> filter in the chain can react to it as needed.
>
> This is my preferred approach and is definitely how the newer filters
> (and whatever mechanism we choose for 2.0) will probably work.  This
> technique is what will allow end-users to not have to subclass Shiro
> Filter classes so much since they can inspect the request in whatever
> way they wish.
>
> For example:
>
> /whatever/** = unauthzUrl[/service/notadmin.jsp], someFilter, roles[admin]
>
> The 'unauthzUrl' filter will place the configured URL in the request
> as an attribute (request.setAttribute) using a well-known key.  Then,
> any AuthorizingFilter subclass (roles, ssl, perms, etc) can lookup
> that attribute if it exists.  If it exists, they redirect using that
> url.  If it doesn't exist, then they fallback to their
> 'unauthorizedUrl' property.
>
> I believe both approaches should be supported, but I prefer the 2nd
> approach due to how clean it feels to me - it feels more like a
> 'mixin' which is much more flexible than subclassing (which we'd like
> to move away from as we've discussed).  It is definitely backwards
> compatible too (new support would be added, but existing functionality
> wouldn't be lost).
>
> Thoughts?
>
> Cheers,
>
> --
> Les Hazlewood
> CTO, Katasoft | http://www.katasoft.com | 888.391.5282
> twitter: http://twitter.com/lhazlewood
> katasoft blog: http://www.katasoft.com/blogs/lhazlewood
> personal blog: http://leshazlewood.com
>
>
> On Sun, Jun 26, 2011 at 11:47 AM, Alan D. Cabrera <list@toolazydogs.com> wrote:
>
>> Looking at the code I'm wondering if I shouldn't extend the particular filter to
do something like this.
>>
>>       <property name="filterChainDefinitions">
>>           <value>
>>               /admin/** = myFilter, myRoles[admin|/service/notadmin.jsp]
>>               /work/** = myFilter, myRoles[verified|/service/notverified.jsp]
>>               /owners/** = myFilter, myRoles[owner|/service/notowner.jsp]
>>               /account/** = myFilter
>>           </value>
>>       </property>
>>
>> No code changes needed then.
>>
>>
>> Regards,
>> Alan
>

Mime
View raw message