shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mathieu Carbou (JIRA)" <j...@apache.org>
Subject [jira] Updated: (SHIRO-184) ShiroFilterFactoryBean 'filterChainDefinitions' property does not retain URL path matching order
Date Fri, 01 Oct 2010 05:56:32 GMT

     [ https://issues.apache.org/jira/browse/SHIRO-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mathieu Carbou updated SHIRO-184:
---------------------------------

    Attachment: shiro-jsecurity.patch

Hi,

We really need this issue to be fixed in our project. We are not using Spring, but an Ini
configuration with realms injected by Google Guice.

I've patched the code to support LInkedHashMap instead of Properties.  You can see the patch
attached.

It breaks the long property value support for multiline, but it is not a stopper for us, as
it should'nt be for many people also. 

Mathieu.


> ShiroFilterFactoryBean 'filterChainDefinitions' property does not retain URL path matching
order
> ------------------------------------------------------------------------------------------------
>
>                 Key: SHIRO-184
>                 URL: https://issues.apache.org/jira/browse/SHIRO-184
>             Project: Shiro
>          Issue Type: Bug
>          Components: Integration: Spring
>    Affects Versions: 1.0.0
>            Reporter: Les Hazlewood
>             Fix For: 1.0.1
>
>         Attachments: shiro-jsecurity.patch
>
>
> Workaround until the next point release: use the 'filterChainDefinitionMap' property
instead - it does retain correct path matching order.
> The problem: the current 'setFilterChainDefinitions' implementation uses a java.util.Properties
object to load the text block into key/value pairs.  Unlike a LinkedHashMap, Properties do
not retain definition order.  For example, the following chain definitions would fail:
> / = anon
> /UIDL/ = anon
> /** authc
> In a simple test, the pattern matcher first evaluated a /UIDL/ request against /, which
didn't match.  It then tried to match the request against /** which did match.  However, this
is incorrect behavior, because there is a /UIDL/ chain defined which was never matched, resulting
in a denied request, even though there is a validly defined (and ordered) pattern for it.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message