Glad to hear it!
On Thu, May 13, 2010 at 9:43 AM, Kalle Korhonen <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> 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 >>>> <[email protected]> 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 <[email protected]> >>>>> 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 >>>>>> <[email protected]> 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 <[email protected]> >>>>>>> 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 <[email protected]> >>>>>>>> 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 >>>>>>>>> <[email protected]> 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 >>>>>>>>>> <[email protected]> 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 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
