[
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.
