AntUrlPathMatcher backwards compatibility

[raziel]

Hi, I am trying to use Oauth 1.0.0.M1 with spring security 3.0.3. However, the spring code (I've seen references on OAuth2ClientBeanDefinitionParser) depends on org.springframework.security.web.util.AntUrlPathMa tcher, which is not available anymore, replaced by the nicer RequestMatcher classes.

It seems to me the project in being based on Spring Security 3.0, which still has those classes. However, being this the latest version, wouldn't it make sense to be using at least the oldest version that has such important backward compatibility changes?

In the mean time, is there a recommended way to address this issue? I cannot rollback to 3.0 since the rest of my application is based on the 3.x code.

Thanks a lot!

[xpat]

I am using 1.0.0M1 with SS 3.0.3 with no problem.. along with spring 3.0.5
make sure you are referencing the correct module for spring-security-web:
...
<spring.security.version>3.0.3.RELEASE</spring.security.version>
...
<!-- Spring Security -->
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-core</artifactId>
<version>${spring.security.version}</version>
</dependency>
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-web</artifactId>
<version>${spring.security.version}</version>
</dependency>
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-config</artifactId>
<version>${spring.security.version}</version>
</dependency>
<dependency>
<groupId>org.springframework.security.oauth</groupId>
<artifactId>spring-security-oauth</artifactId>
<version>1.0.0.M1</version>
</dependency>

[raziel]

My bad, we're actually using 3.1.0.M1, because we need some of the new features.

Are there any plans on using spring security 3.1 for this release of oauth? Or any recommendation to address the backwards compatibility issue?

Also, in this thread http://forum.springsource.org/showthread.php?p=335162 Luke mentions there could be other issues in the oauth module when using spring security 3.1 (a single filter chain). I just started using the oauth module, specifically looking for an oauth 2.0 implementation, and would like to know if definitely using spring security 3.1 is impossible right now (I wouldn't mind creating a temporary branch where I replace AntUrlPathMatcher for 3.1's corresponding class). However, if there are other bigger framework level issues it wouldn't make sense. It would be also nice what are the plans about the oauth module upgrading to 3.1 sometime soon.

Thanks

[stoicflame]

Hi.

Sorry for the late reply. I can confirm that OAuth for Spring Security isn't yet compatible with 3.1. There are indeed issues with the PathMatcher and with a finding a filter chain. I'm still working with Luke et al to get these worked out.

[raziel]

Hey, no problem. I actually checked out the code and fixed the matched code, so it compiles with 3.1M1. However when I configured oauth2 as part of the spring security code it did not work entirely well. I don't know if it's because of some incompatibility with my other spring configuration, or the filter chain issue with 3.1. Could you explain a litle bit what the culprit of this problem with 3.1? Maybe I could help, somehow. Luke said something about 3.1 only supporting one single filter chain (which I thought was always the case).

Thanks!

[stoicflame]

Hi. Sorry for the late reply. Again.

Now that I've to 1.0.0.M2 released, compatibility with SS 3.1 is one of the top priorities.

I've created a branch called "sec31" that I've seeded with the changes that Luke made to support compatibility with 3.1. The sec31 branch compiles and all the tests pass, so that's a good thing. I've also walked through the basic flows for sparklr, tonr, sparklr2, tonr2 and didn't see any of the weirdness that you describe.

However, there are still some work that needs to be done on the sec31 branch before merging it into the master branch.

The first is that we need to verify backwards-compatibility with 3.0. In other words, if we compiled the ssoauth library against 3.1, does that break compatibility with 3.0? My guess is that the answer is 'yes' and so the next thing we would need to do would be to consider how to provide backwards-compatibility.

The second thing that needs to happen is that, according to Luke, 3.1 supports multiple filter chains in the namespace configuration whereas 3.0 supported only one. The reason that's a problem for oauthss is because the oauthss configuration login needs to somehow know which filter chain to attach it's filters to. Even if it's just exposing to the user the ability to configure it explicitly, that would be enough. But anyway, the issue needs to be addressed.

[raziel]

No problem.

It's great there's already work for 3.1 support, so I guess I can now drop my branch.

I do see backwards compatibility not being automatic (even in my app., when I migrated from sec 3.0 to 3.1 I had to refactor some code - the matchers specifically).

I couldn't pinpoint the issues when I configured oauth2 in my application, but it was a day before going on vacation so didn't get to do proper investigation. If I see something specific I'll bring it up.

[raziel]

I just checked out the sec31 branch, and when I try running (mvn jetty:run) either of the sample apps (sparkl2 and tonr2) I get the following error:

2011-01-19 13:57:08.299:WARN::Failed startup of context org.mortbay.jetty.plugin
.Jetty6PluginWebAppContext@1eb0cd0{/sparklr,C:\work\repository\oauth\razauth\sparklr2\ src\main\webapp}
org.springframework.beans.factory.parsing.BeanDefi nitionParsingException: Configuration problem: You cannot use a spring-security-2.0.xsd schema with Spring Security 3.0. Please update your schema declarations to the 3.0 schema.|Offending resource: ServletContext resource [/WEB-INF/applicationContext.xml] at org.springframework.beans.factory.parsing.FailFast ProblemReporter.fatal(FailFastProblemReporter.java :59) at org.springframework.beans.factory.parsing.ReaderCo ntext.fatal(ReaderContext.java:68) at org.springframework.beans.factory.parsing.ReaderCo ntext.fatal(ReaderContext.java:55) at org.springframework.security.config.SecurityNamesp aceHandler.parse(SecurityNamespaceHandler.java:42) at org.springframework.beans.factory.xml.BeanDefiniti onParserDelegate.parseCustomElement(BeanDefinition ParserDelegate.java:1335) at org.springframework.beans.factory.xml.BeanDefiniti onParserDelegate.parseCustomElement(BeanDefinition ParserDelegate.java:1325) at org.springframework.beans.factory.xml.DefaultBeanD efinitionDocumentReader.parseBeanDefinitions(Defau ltBeanDefinitionDocumentReader.java:135)

All schema definitions are pointing to spring-security-3.1.xsd; I don't know why it's even mentioning anything about a spring-security-2.0.xsd schema.

Any help will be very appreciated.

[stoicflame]

Huh. That's weird.

I wonder if there's some assumption I'm making about my own environment. Do you see any spring 2 jars when you do a "mvn dependency:list"?

[raziel]

Basically I just checkout the branch and tried to run the sample apps., but all throw that exception.

I looked for dependencies but I don;t see anything pointing to spring 2 jars (see attached sparklr2_dep.txt and top_dep.txt).

Also, I am able to run mvn install on the spring-security-oauth folder and generate the jar. However when I try that for a sample app., I get some failed tests and compilation errors (see attached sparklr2_ins.txt).

I am really not doing anything special: just downloaded the branch and ran the maven targets.

When I download the sample app's zip files from http://static.springsource.org/sprin.../tutorial.html they start without a problem, so I don't think it's a problem on my computer setup.

I haven't tried doing the same for the master branch though, but I really would like (aka need) to work on the sec31 branch.

Thanks