On Thu, Sep 17, 2009 at 7:36 AM, Peter Ledbrook <[email protected]> wrote: >> That is, IniShiroFilter (ini-specific config), GroovyShiroFilter, >> SpringShiroFilter, GuiceShiroFilter, etc. > > I'm pretty confused now, but the above seems like the wrong way to go. > Shiro configuration and a web/servlet filter seem to be orthogonal > concerns
Sort of - the web support muddies the water a bit. There are two types of configuration in a web environment: 1. Configuration of the SecurityManager and its constituent components (Realms, etc) 2. Configuration of Filters and their chains based on URL pattern matching. These are orthogonal, yes, but #2 is very servlet/http specific, and it is (currently) considered part of the overall configuration. > so wrapping them together into an inheritance hierarchy > seems wrong. I think the idea there is the base ShiroFilter wouldn't configure anything - it would just perform the normal doFilter logic but delegate to an internal SecurityManager and FilterManager instances for subject creation/binding and request processing respectively. Subclasses of the ShiroFilter would actually have to construct the the SecurityManager and FilterChainManager instances however they wanted based on any config mechanism. This way all the common request processing logic that should almost never differ across environments (create Subject, bind it to the thread, look up the appropriate FilterChain, execute it) is in one base class, and the subclasses can focus only on configuration depending on environment. I'm not tied to this idea at all - I'm just throwing ideas out there. But the current WebConfiguration implementations work almost exactly like a Filter anyway and have the same requirements, so I don't see the need for it anymore - not if the above inheritance approach makes sense. I'd love to hear suggestions if anyone things there might be a better way. > that might clear things up for me: > > 1. Is ShiroFilter intended to be a servlet filter? Yes - it exists in the org.apache.shiro.web.servlet package and is definitely servlet specific. For other web filtering (e.g. Portlets), I suspect we'd need another base Filter catering to those other APIs.
