> Looks similar to mine. Why is the key value pair inside the set of roles? > Would it not be semantically better > > /premium/** = myFilter, roles[paid], > unauthorizedUrl[/upgrade.jspa] > > Is this a technical requirement or an "aesthetic" preference?
It is a technical requirement: the value to the right of the equals sign is an order-sensitive filter chain. Each filter you specify is executed in the order it is defined. This, and a lot more, is covered in http://shiro.apache.org/web.html. So in your example, you've specified the roles filter before the unauthorizedUrl filter. This means that if a request's Subject didn't have the 'paid' role, the roles filter would redirect them to any previously configured (Shiro-wide) unauthorizedUrl. It doesn't 'know' about any filters upstream or downstream in the chain. The unauthorizedUrl filter at the end of your chain in your example would never execute because the roles filter would have short-circuited the chain and issued a redirect already. I should also stress that the inside of the brackets denotes that filter's configuration for _that specific url_. So while the roles filter typically takes in a comma delimited list of roles, it would be more semantically correct to say that the roles filter accepts a list of url-specific String configuration parameters. The roles filter (or any PathMatchingFilter implementation for that matter) is free to interpret those strings however it wants. At the moment, the roles filter assumes those strings are all role names. Your subclass could have role names, name/value pairs for additional configuration, or whatever else you may want/need. > Ahh, is this why your configuration is structured that particular way? Yes - the config is an order-specific filter chain. There is no interpretation of a [urls] config line other than to construct a filter chain from it. Doing otherwise would be incredibly messy. It's much easier (and more efficient) to allow users to specify the intricacies of their rules based on simple filter chain ordering, just as it has worked well in web.xml filter chain definitions for years. I would just argue that the conciseness of Shiro's filter chain definitions, and its greater power in path-specific config is _muuuuch_ nicer than doing this stuff in web.xml. I've said in presentations: if you used Shiro for nothing more than to replace web.xml filter chain definitions and didn't even use any of its security features, this feature alone would be worth having the Shiro .jars in your classpath. > I'll give the former a try. I have a question. What happens if a number of > patterns match the URL: > > /premium/A/** = myFilter, roles[paid], > unauthorizedUrl[/upgradeA.jspa] > /premium/B/** = myFilter, roles[paid], > unauthorizedUrl[/upgrade.Bjspa] > /premium/** = myFilter, roles[paid], > unauthorizedUrl[/upgrade.jspa] > > and the user goes to /premium/A/storefront.jspa? I don't anticipate doing > this but am curious. This is covered in http://shiro.apache.org/web.html in the 'Order Matters!' note box. Paths are matched based on the order they are defined. The first path to match the incoming request 'wins'. In your example, the /premium/A/** filter chain would be executed and all other path chain definitions below it are ignored. The documentation page's note box gives a good example of why this is important too. > Thanks. Gotta go help w/ the stuffing... Enjoy the turkey! :) Cheers, Les
