On Fri, Feb 11, 2011 at 10:48 AM, Les Hazlewood <[email protected]> wrote: > 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
I'm just switching the thread to a new title - the Jira title was distracting in the midst of all the other Jira notifications. Les
