I think I found something: The DefaultWebSessionManager defaults the session ID cookie's path to '/'. I don't believe that was there before when using the old CookieAttribute. Can you comment that line out of the DefaultWebSessionManager's constructor and see if that fixes it?
I also now see that the CookieRememberMeManager is also setting the rememberMe cookie on the root path by default. I have no idea why I added that in there when I converted from CookieAttribute to Cookie. I think both lines should be removed. I'll test locally - please report what you find on your end. Les On Wed, May 12, 2010 at 10:50 PM, Kalle Korhonen <kalle.o.korho...@gmail.com> wrote: > Though my authentication still doesn't work... but yes, that log > message lead me to a wrong path. The actual reason was that I had an > existing JSESSIONID cookie with /shiro path. Shiro was not able to > delete it but as soon as I deleted it manually, login started working > again. However, and I think this is related, the new JSESSIONID cookie > is created *without* the /shiro context path. This is of course all > assuming native sessions as is the case with the Spring sample. The > earlier JESSIONID cookie was also Shiro originated so something must > have changed there - maybe it's just the configuration that needs to > be fixed - but would this give you more ideas Les? > > Kalle > > > On Wed, May 12, 2010 at 5:33 PM, Les Hazlewood <lhazlew...@apache.org> wrote: >> 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 >>>>>>> >>>>>> >>>>> >>>> >>> >> >
