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 (JIRA)" <ji...@apache.org> on 2011/02/11 01:16:57 UTC
[jira] Created: (SHIRO-257) Support case insensitive url path
matching
Support case insensitive url path matching
------------------------------------------
Key: SHIRO-257
URL: https://issues.apache.org/jira/browse/SHIRO-257
Project: Shiro
Issue Type: Improvement
Components: Web
Affects Versions: 1.1.0, 1.0.0, 0.9
Reporter: Kalle Korhonen
Fix For: 1.2.0
Three places to modify: 1) configuration needs to normalized (lowercases), PathMatchingFilterChainResolver (perhaps just a property of PatternMatcher?) and PathMatchingFilter, the last related to SHIRO-256, hopefully I could just remove the filter functionality.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Created: (SHIRO-257) Support case insensitive url path matching
Posted by Les Hazlewood <lh...@apache.org>.
Right, agreed - that implies that the IniShiroFilter needs to be
refactored to allow more flexible configuration options, so you can
set your own FilterChainResolver and SecurityManager to allow it to be
more 'frameworky'. Then add in some additional filter config-params
to trigger common logic. Whatever is not covered by the common-logic
can easily be supported by subclassing.
Perhaps an even better option is to allow end-users to configure any
of these custom objects in [main] and we can 'pull' them out and apply
them to the IniShiroFilter at startup. That sounds like a pretty
slick option. And if end-users are anything like me (who hates
configuration anything in web.xml), it sounds like a convenient
approach :)
Les
On Thu, Feb 10, 2011 at 6:36 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> Try it. You cannot (currently) supply a pattern matcher of your choice
> and have it propagated everywhere. PatternMatchingFilter instantiates
> its own default patternMatcher that differentiates from the one used
> in the resolver and there are not setters in the former.
>
> Kalle
>
>
> On Thu, Feb 10, 2011 at 6:01 PM, Les Hazlewood <lh...@apache.org> wrote:
>> The only change I see for this is a PatternMatcher implementation that
>> ignores case (maybe the existing class supports it via an additional
>> attribute. Nothing else needs to change I don't think, right?
>>
>> There is probably no need to preemptively normalize/lower-case pattern
>> definitions because the PatternMatcher would do that in its
>> implementation. That is, it is the PatternMatcher's responsibility
>> for this logic rather than the IniShiroFilter.
>>
>> My desire is to not permanently change the user's config in any way,
>> and instead rely on logic to do it as necessary. Retaining original
>> config is good IMO since we can reference it in log messages,
>> exceptions, output streams, etc, without confusing the user.
>>
>> My .02,
>>
>> Les
Re: [jira] Created: (SHIRO-257) Support case insensitive url path matching
Posted by Kalle Korhonen <ka...@gmail.com>.
Try it. You cannot (currently) supply a pattern matcher of your choice
and have it propagated everywhere. PatternMatchingFilter instantiates
its own default patternMatcher that differentiates from the one used
in the resolver and there are not setters in the former.
Kalle
On Thu, Feb 10, 2011 at 6:01 PM, Les Hazlewood <lh...@apache.org> wrote:
> The only change I see for this is a PatternMatcher implementation that
> ignores case (maybe the existing class supports it via an additional
> attribute. Nothing else needs to change I don't think, right?
>
> There is probably no need to preemptively normalize/lower-case pattern
> definitions because the PatternMatcher would do that in its
> implementation. That is, it is the PatternMatcher's responsibility
> for this logic rather than the IniShiroFilter.
>
> My desire is to not permanently change the user's config in any way,
> and instead rely on logic to do it as necessary. Retaining original
> config is good IMO since we can reference it in log messages,
> exceptions, output streams, etc, without confusing the user.
>
> My .02,
>
> Les
>
Re: [jira] Created: (SHIRO-257) Support case insensitive url path matching
Posted by Les Hazlewood <lh...@apache.org>.
The only change I see for this is a PatternMatcher implementation that
ignores case (maybe the existing class supports it via an additional
attribute. Nothing else needs to change I don't think, right?
There is probably no need to preemptively normalize/lower-case pattern
definitions because the PatternMatcher would do that in its
implementation. That is, it is the PatternMatcher's responsibility
for this logic rather than the IniShiroFilter.
My desire is to not permanently change the user's config in any way,
and instead rely on logic to do it as necessary. Retaining original
config is good IMO since we can reference it in log messages,
exceptions, output streams, etc, without confusing the user.
My .02,
Les
[jira] Updated: (SHIRO-257) Support case insensitive url path
matching
Posted by "Kalle Korhonen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHIRO-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kalle Korhonen updated SHIRO-257:
---------------------------------
Fix Version/s: (was: 1.2.0)
2.0.0
Assignee: (was: Kalle Korhonen)
> Support case insensitive url path matching
> ------------------------------------------
>
> Key: SHIRO-257
> URL: https://issues.apache.org/jira/browse/SHIRO-257
> Project: Shiro
> Issue Type: Improvement
> Components: Web
> Affects Versions: 0.9, 1.0.0, 1.1.0
> Reporter: Kalle Korhonen
> Fix For: 2.0.0
>
>
> Three places to modify: 1) configuration needs to normalized (lowercases), PathMatchingFilterChainResolver (perhaps just a property of PatternMatcher?) and PathMatchingFilter, the last related to SHIRO-256, hopefully I could just remove the filter functionality.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira