Spring-security-oauth2.xsd is not published to http://www.springframework.org/schema/security

[lukasondrak96]

Summary Spring-security-oauth2.xsd should be published under https://www.springframework.org/schema/security/ Or was this removal intentional? Because it crashes our application based on spring.

Actual Behavior Spring-security-oauth2.xsd is not available under https://www.springframework.org/schema/security/ causing XML schema validation failures in IDEs.

Expected Behavior Spring-security-oauth2.xsd should be available under https://www.springframework.org/schema/security/ to enable successful XML schema validation in IDEs

[lukasondrak96]

For anyone missing this file, temporal solution could be something like this: https://github.com/dhis2/dhis2-core/pull/5097/commits/c1a0f4798d11c6cb90e76a9b3777cf479817321c

Also worked for us to change url in WEB-INF/spring-oauth-security.xml to https://www.springframework.org/schema/security/spring-security-oauth2-2.0.xsd

[jgrandja]

@lukasondrak96 The Spring Security OAuth project has reached end-of-life. Please see announcement.

As part of the end-of-life process, there are a few cleanup tasks involving the removal of some content, archives, moving repository to attic, etc.

[bilaliqball]

@lukasondrak96 https://www.springframework.org/schema/security/spring-security-oauth2-2.0.xsd also returns 404 , page not found

[whaan]

in the spring.schemas file in the META-INF folder, all requests for https\://www.springframework.org/schema/security/spring-security-oauth2.xsd get redirected to org/springframework/security/oauth2/spring-security-oauth2-2.0.xsd

So the XSD doesn't have to looked up from the internet. As long as you use https, it will simply look it up from the classpath

[MikeN123]

Yes, and the problem is that previously http was used, other projects consistently added both http and https to the spring.schemas, but that was never fixed for spring-security-oauth. So that's why stuff all over the place is breaking now.

And yes, I could change the application to https:// which we already did a while ago, but not all legacy is gone yet and the complete breakage of the apps means I would now have to rebuild dozens of applications.

[MikeN123]

@jgrandja I just can't understand the decision to actively start breaking existing or legacy projects. What's next, removing the artifacts from Maven Central? The end-of-life announcement stated that the project would be opened up to the community, this goes 100% against that.

[jgrandja]

@MikeN123 There have been a few announcements communicating the end of life for Spring Security OAuth.

• MAY 07, 2020
• NOVEMBER 08, 2021
• JUNE 01, 2022

As well, all the classes have been marked @Deprecated for 2 years and the Project site and GitHub site stated the deprecation notice.

I just can't understand the decision to actively start breaking existing or legacy projects

The communication has been out there for 2 years and we feel this is a reasonable amount of time to let the community know to start preparing for this by either migrating to the new OAuth2 support in Spring Security and Spring Authorization Server or to fork the project and maintain it yourself.

The end-of-life announcement stated that the project would be opened up to the community, this goes 100% against that.

No one from the community stepped up to take ownership. However, this is never too late as anyone can fork the project and manage it under another GitHub repository.

[MikeN123]

@jgrandja The point is that I never expected XSD's to be deleted. The Spring Security 2.0 XSD's are still around as well, and that version is certainly end of life as well.

There is a large gap between 'end of life, no longer maintained' and 'we just instantly disable any and all applications that still use the app and have never switched the XSD to HTTPS as that was never asked'.

[jgrandja]

@MikeN123

@jgrandja The point is that I never expected XSD's to be deleted. The Spring Security 2.0 XSD's are still around as well, and that version is certainly end of life as well.

Point taken. We'll put back the XSD.

[MikeN123]

Thank you very much, saves me from a lot of overtime during the weekend (and yes, we do have a plan to get rid of the dependency and will certainly fix any issues ourselves in the meantime if necessary).

[jgrandja]

@MikeN123 I certainly don't want you working overtime. We're on it now. Stay tuned.

[jzheaux]

@MikeN123, @lukasondrak96 I've reuploaded the XSD and now https://www.springframework.org/schema/security/spring-security-oauth2.xsd and the HTTP equivalent both resolve for me.

Is there anything else needed to get you up and going again?

[MikeN123]

Many thanks, should be fine now :-)

[jgrandja]

Reopening as I think this issue is only temporarily resolved as it may become an issue again after the next Spring Security release. We need to investigate further.

cc/ @jzheaux @rwinch

[jzheaux]

@jgrandja I don't think this will be an issue. The schema upload is an additive process. That is, the next version's XSD is uploaded to the docs server on each release and added to (not replacing) the existing set of XSDs. Is there something else you'd like to see before closing this issue?

[pnk0807]

@jzheaux , @jgrandja I would like to inform that the issue occured again. Is it possible to make https://www.springframework.org/schema/security/spring-security-oauth2.xsd available again?

[anihovsk123]

@jzheaux , @jgrandja - hi guys, it would be great if you could upload the xsd back. I assume many applications around the world just cannot be started/restarted due to the issue. It is especially critical for applications in Production which cannot be restarted for maintenance. Thanks

[pnk0807]

@anihovsk or any affected devs You can change following line in xml configuration: from: http://www.springframework.org/schema/security/spring-security-oauth2-2.0.xsd to: https://www.springframework.org/schema/security/spring-security-oauth2-2.0.xsd So basically change http to https. Works the same as changing to classpath It will allow during build to use dependency locally stored in jar files.

[MatthewGreigPrecor]

@anihovsk or any affected devs You can change following line in xml configuration: from: http://www.springframework.org/schema/security/spring-security-oauth2-2.0.xsd to: https://www.springframework.org/schema/security/spring-security-oauth2-2.0.xsd So basically change http to https. Works the same as changing to classpath It will allow during build to use dependency locally stored in jar files.

Doesn't help, we still get the 404 and were already using https

[mirihernandez-wahbe]

The way it got fixed is by opening the jar (spring-security-oauth2-XXX) file with winzip then go to org\springframework\security you will find xsds name

now point to https://www.springframework.org/schema/security/XSDFileNameInsideJAR.xsd Hope it helps

[norman-knott]

The http to https trick worked for me. Just wondering if the removal of the XSD happened intentionally this time.

[sjohnr]

@norman-knott It was not intentional, but is unfortunately a gap in our release process (when combined with an automatic process on the backend to point to the latest of our deployed schemas). I've opened gh-12804 to address the specific issue and will be submitting a fix soon so that subsequent releases don't re-trigger the issue.

This issue has been addressed in the meantime with manual intervention, so I'm going to close this issue in favor of gh-12804.