On Thu, Feb 10, 2011 at 8:06 PM, Kalle Korhonen
<[email protected]> wrote:
> On Thu, Feb 10, 2011 at 5:48 PM, Les Hazlewood <[email protected]> wrote:
>> As it currently stands (at least until 2.0), I don't believe this is
>> possible.
>> PathMatchingFilter does more with the paths beyond just seeing if it
>> should execute. It uses the configured paths to determine
>> path-specific configuration as well as support the
>> isFilterChainContinued method (which allows inspection of
>> path-specific config).
>> Being able to dynamically react to path-specific configuration during
>> a request is a big feature of many of the Shiro filters, as well as
>> many custom subclasses out of our control.
>> Just out of curiosity, what is the push to refactor the hierarchy?
>
> Perhaps I didn't explain the issue properly, but re-read the issue
> description again. Since the path specific configuration is the only
> actual attribute of the filter, it should be part of each specific
> filter instance. If we just created a separate filter instance for
> each chain, it'd simplify the logic, make it perform better and divide
> the responsibilities better.
I'm still not sure this would be ideal (at least until we find a
suitable alternative):
As you know, Filters are currently maintained in a 'pool' from which
they can be referenced multiple times for separate chains. In every
web app I've ever used with Shiro, I rely on that to know that I can
configure any object in the pool and that configuration applies in all
chains where I use it. I then use path-specific config for
finer-grained control.
For example, I can turn on or off the SSL filter application wide, but
then turn it on or off for an individual chain *without* removing it
from the chain:
/some/feature/** = ssl[enabled=${someFeature.ssl.enabled}], authc
I leverage this a lot in my apps and it allows for an extremely
powerful/flexible security control experience.
Creating a new filter instance per chain would be very frustrating if
I would have to configure the same filter type _every_ time it needs
to go in a chain. web.xml uses a single filter instance for multiple
chains, and I think this is still probably the most intuitive for
people IMO.
As an alternative, I suppose you could use a factory approach (where
you configure the Factory instance and it creates a new Filter each
time you create a chain) but that is far more complex than configuring
a 'global' filter directly. I don't believe we should force the
Factory approach on all Shiro users when the alternative is much
simpler. I think the Factory approach can co-exist, but they're not
mutually exclusive IMO.
Now if we can find a slick way of supporting this without being
painful to configure or implement for end-users, I'm totally open to
that. Any ideas? Any examples of how you think this could work (code
or config or otherwise)?
Best,
Les
