Michael Osipov (Migrated from SEC-2129) said:
AntPathRequestMatcher claims to work much like AntPathMatcher but treats everything in lowercase.
This has several flaws:
1. AntPathMatcher does not do that. Inconsistent.
2. One has to create a custom matcher in order to get case-sensitivity.
3. You might expose resources which differ in case but should be protected by other means.
4. You rely on Locale.getDefault() which might cause problems.
The solution would be to remove the toLowerCase() call and add another matcher which retains ci comparison. So we would have four request-matcher enum values: regex, ciRegex, ant and ciAnt.
Comment From: spring-projects-issues
Rob Winch said:
Note: I think that we will probably add a boolean property for caseSensitive to the existing matcher and leave the default as false (for passivity)
Comment From: spring-projects-issues
Michael Osipov said:
This means that one cannot really use request-matcher, one has to create a bean explicitly. Since you are fixing in a minor version, I think this rectifies a change in standard behavior.
Comment From: spring-projects-issues
Rob Winch said:
I actually think the bug is on the documentation. This has been the behavior of the ant matchers for quite some time and 3.2 is a passive release. The problem is that if we start making it case sensitive we will introduce security vulnerabilities for applications. Most likely the documentation will be corrected to state that it is case in-sensitive variant of ant patterns. The boolean property should still give you what you need (esp with the introduction of SEC-1953 which would easily allow any request matcher).
Comment From: spring-projects-issues
Michael Osipov said:
bq. I actually think the bug is on the documentation. This has been the behavior of the ant matchers for quite some time and 3.2 is a passive release.
If you are used to use AntPathMatcher in Spring core or Ant itself it is case-sensitive or are you solely referring to the AntPathRequestMatcher?
what is acutally meant by passive release?
bq. The problem is that if we start making it case sensitive we will introduce security vulnerabilities for applications.
Maybe but I expect every developer to read release notes/changelog before upgrading to a new minor version. At least I do.
Anyway, how I am supposed to set the boolean value? I was assuming that I could do the following after a fix:
<security:http request-matcher="regex|ciRegex|ant|ciAnt" ...>
...
</security:http>
A boolean property would actually require to use request-matcher-ref + an explicit bean declaration. Am I wrong?
Comment From: spring-projects-issues
Rob Winch said:
If you are used to use AntPathMatcher in Spring core or Ant itself it is case-sensitive or are you solely referring to the AntPathRequestMatcher?
This statement wasn't as clear as it should have been. I'm speaking about intercept-url behavior (which is backed by AntPathRequestMatcher and previously AntUrlPathMatcher).
what is acutally meant by passive release?
It means that if I am using Spring Security 3.1.x then the updating to 3.2.x should require no changes to configuration or code in order to work. Passivity is not necessarily required for a major release (i.e. 3.x to 4.x) although Spring tends to remain quite passive between major releases as well.
Maybe but I expect every developer to read release notes/changelog before upgrading to a new minor version. At least I do.
One would hope, but the versions are an agreement to remain passive so many do not read them. If it non passive changes were made, a bug would be sure to follow (and rightfully so).
Anyway, how I am supposed to set the boolean value? I was assuming that I could do the following after a fix:
I'm not sure if we will address this with a change to the namespace configuration or not. One option might be to allow
<security:http request-matcher-ref="someBeanIdThatImplementsRequestMatcher" ...>
More than likely we will require use of Java Configuration for less common configurations. If you are wanting to see a basic idea of how you would do it with Java Config you can refer to https://github.com/rwinch/getting-started-springsecurity-31/blob/javaconfig/src/main/java/org/springframework/security/samples/config/SecurityConfig.java Keep in mind this is just a prototype and is not yet included in 3.2 (I'm currently working on this now).
Comment From: spring-projects-issues
Michael Osipov said:
I think at least for 4.0 we should enforce consistency and provide those four request matchers. While I personally would do this for 3.2, it's your decision of course. If you really care for backwards-compat leave ant as-is, introduce ciAnt and csAnt. With 4.x you can drop csAnt and make it default as ant.
I have already used a BeanPostProcessor with the core framework and I am not really happy with mixing configuration styles. I'd like to keep a low profile on config.
Comment From: spring-projects-issues
Rob Winch said:
I think it makes sense to remain case insensitive for expressions that use URLs since many sites use case-insensitive URLs.
Comment From: spring-projects-issues
Michael Osipov said:
While this maybe true, a URL path is case-sensitive, though it's up to the server to decide. See this wikipedia ref: http://en.wikipedia.org/wiki/Uniform_resource_locator and please see this: http://tools.ietf.org/html/rfc2616#section-3.2.3
Comment From: spring-projects-issues
Rob Winch said:
I probably should clarify. At this time, the passivity will remain for this feature through 4.0. In other words, users that are creating a URL with ant patterns with the namespace configuration will still get a case in-sensitive comparison. However, there will be a way to do case sensitive comparison. In short, I think there should be a way to do case sensitive comparison, but I do not think it will become the default.
Comment From: spring-projects-issues
Rob Winch said:
I have updated this to an enhancement to support case sensitive operations. Note that the javadoc already states it is case-insenstive "The query string of the URL is ignored and matching is case-insensitive." See http://static.springsource.org/spring-security/site/docs/3.1.x/apidocs/org/springframework/security/web/util/AntPathRequestMatcher.html
Comment From: Lonzak
This was a bad idea 👎 Now (spring 5.6) the matcher is case sensitive by default and (via XML configuration) there seems to be no way to make it case-insensitive like it was before (so no ciAnt available). And then the AntPathRequestMatcher class is final and also its caseSensitive attribute which makes it even more difficult to find a solution...
Comment From: jzheaux
@Lonzak, sorry that you are having trouble with this change. Given that the change was made over six years ago, I'm guessing that you are trying to move from Spring Security 3.x up to 5.x, which certainly can be daunting! Thanks for putting in the effort to get onto the latest.
In the future, may I recommend posting a question to StackOverflow? This will likely result in more help from the community and the team. If you haven't already, take a look at the request-matcher-ref property.
Comment From: Lonzak
@jzheaux Yes you are right - did the long overdue update from 3.X to 5.X recently. I could probably write a migration guide right now ;-) However this change is hopefully the last hurdle to take. And actually I did already write on Stackoverflow and even put a bounty on it. Regarding the "request-matcher-ref" that is the only solution I can think of right now...however I have to add >30 new beans to our configuration which makes it even more unreadable. But there doesn't seems to be another solution...