shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Hazlewood <>
Subject Re: Filter chain path matching broken for Spring
Date Thu, 13 May 2010 07:44:34 GMT
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 <> 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 <> 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
>> <> 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 <>
>>>> 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
>>>> <> 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 <>
>>>>>> 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.
>>>>>> tried to go to http://localhost:9080/shiro and it immediately
>>>>>> redirected me to http://localhost:9080/shiro/s/login which means
>>>>>> the 'authc' filter (defined in applicationContext.xml ->
>>>>>> shiroFilterFactoryBean 'filterChainDefinitions' property) caught
>>>>>> 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 <>
>>>>>>> I'm really confused by this - the Spring ShiroFilterFactoryBean
>>>>>>> the same PathMatchingFilterChainResolver that the IniShiroFilter
>>>>>>> Still tracing...
>>>>>>> On Wed, May 12, 2010 at 4:07 PM, Les Hazlewood <>
>>>>>>>> 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
>>>>>>>> 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
>>>>>>>> <> 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

View raw message