On Wed, Sep 16, 2009 at 7:38 AM, Les Hazlewood <[email protected]> wrote: > Currently the ShiroFilter delegates to a WebConfiguration instance to > build the SecurityManager instance. My latest (not committed) > WebConfiguration interface also returns a FilterChainResolver instance > that has one method: FilterChain getFilterChain(ServletRequest > request, ServletResponse response, FilterChain original); The > ShiroFilter uses this at runtime to determine exactly which > FilterChain to execute. > At this point the WebConfiguration class is essentially working just > like the ShiroFilter originally worked: It takes in some > configuration values and spits out a SecurityManager instance (and now > a FilterChainResolver). > This leads me to believe that the WebConfiguration is no different > than a normal Filter in function, but now we've added an additional > class that still needs to know about a FilterConfig. I feel like > we've duplicated things unnecessarily.
I'd need to see the code give better comments, but here goes: As you know I'm not using the ShiroFilter in my environment. I looked at WebConfiguration and the classes in the Configuration hierarchy but since they were using an ini file that I was not planning to use, I simply decided to combine aspects of ShiroFilter and Configuration into one class (in essence the same conclusion you reached) - in fact, it's even called SecurityConfiguration. I would probably be able to use the FilterChainResolver but I don't think WebConfiguration would do anything for me. > Wouldn't it make more sense then to have ShiroFilter subclasses that > perform configuration-specific activities instead of complicating > things with this 'WebConfiguration' concept? > That is, IniShiroFilter (ini-specific config), GroovyShiroFilter, > SpringShiroFilter, GuiceShiroFilter, etc. Agree - ShiroFilter is essentially an entry point to initializing the system, so it makes sense that it can be customized (sub-classed, replaced) to the needs of particular environments, rather than adding another level of indirection there (that likely would still need to be customized). Where there are reusable parts with distinct responsibilities (independent of the configuration), the filter should delegate those responsibilities to specific handlers, such as FilterChainResolver. Removing WebConfiguration completely simplifies the interfaces and straightens out the inheritance hierarchy. Kalle
