Hrm, this should not be the case. Also note that 'first match wins' when it comes to url matching - urls are checked for a match in the order that they are defined. So this definition has a problem:
/user/signin /user/** = authc /user/reset/confirm = blah Since /user/** matches, that chain is used immediately and the /user/reset/confirm chain is never executed. Can you please check that this does not occur in your config anywhere? And if you're sure it does not, can you provide a simple test configuration that demonstrates your problem in a Jira issue? Paths of any depth should be supported without problem. Thanks, Les On Tue, Feb 16, 2010 at 4:41 PM, charlie <[email protected]> wrote: > Hi, am i right in thinking that I can only specify 2 level deep for the anon > filter? I have a REST service with 2 paths that need to use this filter. > /user/signin and /user/reset/confirm. /user/signin works fine but the other > don't until i shorten the path to 2 level deep i.e. /user/reset then it > works. Any idea? > C
