You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@shiro.apache.org by Kalle Korhonen <ka...@gmail.com> on 2010/05/13 00:29:08 UTC

Filter chain path matching broken for Spring

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

Re: Filter chain path matching broken for Spring

Posted by Les Hazlewood <le...@hazlewood.com>.

Glad to hear it!

On Thu, May 13, 2010 at 9:43 AM, Kalle Korhonen
<ka...@gmail.com> 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 <lh...@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 <lh...@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 <lh...@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
>>>> <ka...@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 <lh...@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
>>>>>> <ka...@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 <lh...@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 <lh...@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 <lh...@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
>>>>>>>>>> <ka...@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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>