I think I might know what is happening - but it's just a guess: I see some of the 'No FilterChain configured...' messages myself. But these messages are due to resources that are not protected by a url pattern - such as style.css or logo.jpg.
However when I access a resource that is protected by a chain definition (http://localhost:9080/shiro/s/index in this case), I see this: 2010-05-12 17:28:05,954 TRACE [org.apache.shiro.web.filter.mgt.PathMatchingFilterChainResolver] - Matched path pattern [/s/index] for requestURI [/s/index]. Utilizing corresponding filter chain... 2010-05-12 17:28:05,954 TRACE [org.apache.shiro.web.servlet.AbstractShiroFilter] - Resolved a configured FilterChain for the current request. 2010-05-12 17:28:05,954 TRACE [org.apache.shiro.web.servlet.ProxiedFilterChain] - Invoking wrapped filter at index [0] 2010-05-12 17:28:05,954 TRACE [org.apache.shiro.web.servlet.OncePerRequestFilter] - Filter 'authc' not yet executed. Executing now. ... Perhaps we should modify that trace statement (the 'No FilterChain configured..') to also print out the path of what is being accessed? Then it would be clear as to what is using the default chain vs one of the URL matching chains. Les On Wed, May 12, 2010 at 5:12 PM, Kalle Korhonen <kalle.o.korho...@gmail.com> wrote: > Oddity odd. Clean re-built everything and I get the same result: > 2010-05-12 17:07:33,649 TRACE > [org.apache.shiro.web.servlet.AbstractShiroFilter] - No FilterChain > configured for the current request. Using the default. > when /shiro context is used. > > Otherwise I'd say it has something to do with my environment only but > the fact that it doesn't matter whether I run it in Eclipse or via mvn > jetty:run and that changing to root context fixes the issue makes me > suspect a problem in the codebase. Will debug further.. > > Kalle > > > On Wed, May 12, 2010 at 4:41 PM, Les Hazlewood <lhazlew...@apache.org> wrote: >> Ok, I'm officially confused. >> >> I just ran the spring sample (after ensuring I was updated to the >> latest code) which defaults to starting up on the /shiro context. I >> tried to go to http://localhost:9080/shiro and it immediately >> redirected me to http://localhost:9080/shiro/s/login which means that >> the 'authc' filter (defined in applicationContext.xml -> >> shiroFilterFactoryBean 'filterChainDefinitions' property) caught the >> request and redirected it. >> >> I logged in successfully and it immediately redirected me to >> http://localhost:9080/shiro/s/index without problem. >> >> Everything seems to be working... >> >> Les >> >> On Wed, May 12, 2010 at 4:19 PM, Les Hazlewood <lhazlew...@apache.org> wrote: >>> I'm really confused by this - the Spring ShiroFilterFactoryBean uses >>> the same PathMatchingFilterChainResolver that the IniShiroFilter does. >>> >>> Still tracing... >>> >>> On Wed, May 12, 2010 at 4:07 PM, Les Hazlewood <lhazlew...@apache.org> >>> wrote: >>>> Hi Kalle, >>>> >>>> I wasn't aware of this, and I'm not sure what is wrong :/ I'll start >>>> looking in to it right now. In the meantime, any test you could >>>> provide would be helpful. I'll hopefully find out what is going on >>>> though. >>>> >>>> Thanks for the heads-up! >>>> >>>> On Wed, May 12, 2010 at 3:29 PM, Kalle Korhonen >>>> <kalle.o.korho...@gmail.com> wrote: >>>>> Les - are you aware that some recent change has broken the path >>>>> matching when you configure things via Spring and webapp context is >>>>> used. Run the Spring sample - the default configuration uses "shiro" >>>>> context and authentication just doesn't work because the resolver >>>>> finds nothing configured for that url. However, if you change the >>>>> Jetty configuration to publish to root context, everything works. This >>>>> is not an issue with with the simple jsp "web" sample even if you use >>>>> some other context than root. I can easily whip up an integration test >>>>> for this but I bet you have a pretty good hunch of what might have >>>>> broken it. >>>>> >>>>> Kalle >>>>> >>>> >>> >> >
