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:01:24 GMT
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.


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 <> 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
>> <> 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.  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 <>
>>>>> 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 <>
>>>>>> Hi Kalle,
>>>>>> I wasn't aware of this, and I'm not sure what is wrong :/  I'll
>>>>>> 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
>>>>>> 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
>>>>>>> used. Run the Spring sample - the default configuration uses
>>>>>>> context and authentication just doesn't work because the resolver
>>>>>>> finds nothing configured for that url. However, if you change
>>>>>>> Jetty configuration to publish to root context, everything works.
>>>>>>> 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
>>>>>>> for this but I bet you have a pretty good hunch of what might
>>>>>>> broken it.
>>>>>>> Kalle

View raw message