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 >>> >> >
