Hrm - I just started thinking about it the other way too. What if you don't want to repeat each url 4 or 5 times just because the HTTP Method differs but the chains will pretty much be mostly the same.
Maybe we should provide both options. At the url configuration level as already mentioned, and maybe each filter also has the ability to decide. But given this is boilerplate, maybe it could be written in the top-level PathMatchingFilter (from which all other Shiro filters extend). That way an end user can use what they prefer or what the situation deems most appropriate. Thoughts? As to the syntax, my preference is that the request path + method be specified on the left-side of the equals sign since those two together define the matching criteria. After a match is made, the right-hand side is the chain to be executed. This approach plays nicely with the existing FilterChainResolver/FilterChainManager implementations. How about: /rest/**[GET,POST,...] = foo, bar, baz The reason I propose this format is that there is no equals sign, space or colon before the chain definition: if you want to use an equals sign, colon or space in the key, you have to escape it, since that's how INI and .properties parsing works. That can look pretty ugly IMO. It also maintains a congruent configuration concept (the brackets) that is used with the filters already. My .02, Les On Fri, Oct 15, 2010 at 2:42 PM, Peter Ledbrook <[email protected]> wrote: >> For example: >> >> /rest/**,GET = anon, foo, bar >> /rest/**,POST = authcBasic, perms[blah] >> >> or even more robust, to allow for other matching criteria later (e.g. >> header values?) >> >> rest/**[method:GET,blah:x] = anon, foo, bar >> >> This feels a little more robust to me than perhaps duplicating this >> stuff across the HttpMethodPermissionFilter or Authc filters... >> >> Thoughts? > > I agree that whether a filter should apply to a particular HTTP method > is orthogonal to the filter implementation. Attaching it to the rule > itself does make sense. To my mind, it's simply a question of what > syntax to use. > > GET:/rest/** = ... > POST,PUT,DELETE:/rest/** = ... > > or > > /rest/** = anon, foo, bar -- GET > /rest/** = authcBasic, perms[user] -- POST,PUT,DELETE > > All sorts of options available. > > Peter >
