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 <[email protected]> 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
