Yeap, that did it, cookie's retaining the context path now (and it worked just the same even with a previous cookie at root path). Thanks, I knew you'd have a pretty good handle on it.
Kalle On Thu, May 13, 2010 at 12:44 AM, Les Hazlewood <lhazlew...@apache.org> wrote: > I tested a few sample apps after removing the ROOT_PATH default and > all works well. The default cookie path value now remains null (as it > was originally) which instructs the cookie implementation to use the > request's context path by default. User-specified path values of > course override this, but at least the contextPath will be used by > default now. > > I committed the fix - I hope that all is well now! > > On Thu, May 13, 2010 at 12:04 AM, Les Hazlewood <lhazlew...@apache.org> wrote: >> I know why I did it - I saw the ROOT_PATH constant and thought that >> was assigned by default to the internal 'path' attribute. Upon >> looking at the CookieAttribute source, this is not the case. We >> should remove that default in DefaultWebSessionManager and >> CookieRememberMeManager and I think that would clear it up. I'll test >> now. >> >> On Thu, May 13, 2010 at 12:01 AM, Les Hazlewood <lhazlew...@apache.org> >> wrote: >>> 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 >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
