On Fri, Feb 11, 2011 at 9:58 PM, Kalle Korhonen <[email protected]> wrote: > On Fri, Feb 11, 2011 at 11:11 AM, Les Hazlewood <[email protected]> wrote: >> On Fri, Feb 11, 2011 at 10:48 AM, Les Hazlewood <[email protected]> >> wrote: >>> As you know, Filters are currently maintained in a 'pool' from which >>> they can be referenced multiple times for separate chains. In every > > Yes, and I'm saying there's no benefit pooling them. > >>> 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 > > Right, we have the default configuration per filter type and then > configuration per filter instance. Obviously the enabled bit is part > of the filter instance configuration.
The crux of this discussion for me lies in the following 2 questions: How would a user configure filters such that each filter instance created reflects that configuration. Then, how would they provide chain-specific configuration overrides on a particular filter instance? That is, how would either scenario look in shiro.ini? I don't have any problems with new filter instances being created for each filter chain. I'd just like to see how this can be configured simply without users having to repeat themselves. Any ideas? Best, Les
