Mailing-List: contact dev-help@shiro.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@shiro.apache.org
Received-SPF: softfail (athena.apache.org: transitioning domain of
 list@toolazydogs.com does not designate 209.85.210.45 as permitted sender)
Subject: Re: Unauthorized URL for different entries in filter chain
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: "Alan D. Cabrera" <list@toolazydogs.com>
In-Reply-To: <BANLkTinWseGW07d8xFgG+6+TMwm+q2sWfA@mail.gmail.com>
Date: Sun, 26 Jun 2011 21:46:41 -0700
Cc: dev@shiro.apache.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9B00800F-CEE8-429E-BAAA-20E2838677E1@toolazydogs.com>
References: <0544AF5F-C1DF-4153-8042-1EB2F3B57807@toolazydogs.com>
 <4A126ABD-0A88-47DE-9356-39D4AFA0362B@toolazydogs.com>
 <BANLkTinWseGW07d8xFgG+6+TMwm+q2sWfA@mail.gmail.com>
To: Les Hazlewood <lhazlewood@apache.org>

I like approach #1 and don't care so much for #2.  :)  Creating a filter =
just so that you could set a property in other filters seems a bit =
awkward; it's not a mixin, imo, since all the participating filters have =
to be prepared to collaborate ahead of time. =20

/whatever/** =3D someFilter, roles[admin, =
unauthzUrl=3D/service/notadmin.jsp]

How would this work from a filter's perspective?  We can keep a single =
instance of a filter around and it handles all requests or we can create =
a new instance of the filter per call.  The former would be backward =
compatible so I'll discuss that first.

When set of filters match a path, a set of the filters's methods are =
called by the framework.  This allows the filters to participate in the =
framework's processing of the client's request.  Let's say that these =
methods are foo and bar.  The methods foo and bar have a set of required =
arguments; these would be the arguments that Shiro 1.1 has.  But some =
filters could have additional parameters and we map the key/value pairs =
in the filter chain config to those parameters.  For the roles filter =
foo could be:

foo(ServletRequest request, ServletResponse response, String =
mappedValue, String unauthzUrl)

for the someFilter it would be:

foo(ServletRequest request, ServletResponse response)

where the last signature would have a default do-nothimg implementation. =
 The only problem with this is that the current implementation =
extensively uses class inheritance to extend/override features and it's =
not clear to me that we have a concise set of "event" methods between =
the framework and filters; the events seem to be buried inside abstract =
classes.

The other way is for if we create the filter per request; something we =
are apparently thinking for 2.0.  When we create that instance set we =
set it's bean properties from the key/value pairs in the filter chain =
config.

Thoughts?


Regards,
Alan

On Jun 26, 2011, at 12:14 PM, Les Hazlewood wrote:

> Hi Alan,
>=20
> Yep, that's one of two ways I can see this working (although I'd
> probably represent the string a bit differently - see below).
>=20
> Approach #1:
>=20
> Have url configurable on a per-request (e.g. per path) basis like
> you've shown, available to any of the AuthorizationFilter subclasses.
>=20
> I'd probably represent this as a named key/value pair in the config
> string, e.g.:
>=20
> /whatever/** =3D someFilter, roles[admin, =
unauthzUrl=3D/service/notadmin.jsp]
>=20
> 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)
>=20
> I believe this approximates more of what the 2.0 codebase will =
probably be like.
>=20
> Approach #2:
>=20
> Have a filter that configures the URL as a request attribute so any
> filter in the chain can react to it as needed.
>=20
> 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.
>=20
> For example:
>=20
> /whatever/** =3D unauthzUrl[/service/notadmin.jsp], someFilter, =
roles[admin]
>=20
> 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.
>=20
> 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).
>=20
> Thoughts?
>=20
> Cheers,
>=20
> --=20
> 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
>=20
>=20
> On Sun, Jun 26, 2011 at 11:47 AM, Alan D. Cabrera =
<list@toolazydogs.com> wrote:
>=20
>> Looking at the code I'm wondering if I shouldn't extend the =
particular filter to do something like this.
>>=20
>>       <property name=3D"filterChainDefinitions">
>>           <value>
>>               /admin/** =3D myFilter, =
myRoles[admin|/service/notadmin.jsp]
>>               /work/** =3D myFilter, =
myRoles[verified|/service/notverified.jsp]
>>               /owners/** =3D myFilter, =
myRoles[owner|/service/notowner.jsp]
>>               /account/** =3D myFilter
>>           </value>
>>       </property>
>>=20
>> No code changes needed then.
>>=20
>>=20
>> Regards,
>> Alan