shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Hazlewood <lhazlew...@apache.org>
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.

Les

On Wed, May 12, 2010 at 10:50 PM, Kalle Korhonen
<kalle.o.korhonen@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 <lhazlewood@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.korhonen@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 <lhazlewood@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 <lhazlewood@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 <lhazlewood@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.korhonen@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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Mime
View raw message