As a result of #8091 !?
Comment From: MikeN123
This seems to break startup of all our applications. That is something we need to investigate, but could the XSD maybe be fixed urgently in the meantime?
Comment From: MikeN123
Apparently this was already fixed in https://github.com/spring-projects/spring-security/pull/7623, so only Spring Security 5.2.0 and 5.2.1 are broken in this regard.
Comment From: tadamczak
I confirm that it breaks build of all our applications too.
Comment From: bclozel
I took the liberty to add that file back in our schemas (linking to the latest available schema) for now. I'll let the Spring Security team handle specifics for this issue. Thanks
Comment From: qeepcologne
we had the same problem with: http://www.springframework.org/schema/security/spring-security-oauth2-2.0.xsd and had to host the file on our own website as emergency hotfix - there is no https version, and i cannot find the file via directotry listing @ http://www.springframework.org/schema/ We use spring-security 5.3.0.RELEASE + spring-security-oauth2 2.4.0.RELEASE.
Comment From: jzheaux
My apologies for the hiccup - there's a step in our release process that's easy to miss. I'll leave this ticket open to investigate the possibility of simplifying that step.
@qeepcologne will you please confirm that you can reach the spring-security-oauth2-2.0.xsd now?
@FelixJongleur42, @tadamczak, and @MikeN123 are you able to reach spring-security.xsd?
Comment From: MikeN123
Yes, works for us now. Will also be upgrading to Spring Sec 5.2.2. soon to make sure it uses the XSD in the JAR.
Comment From: dc-oe
This issue has broken us because we rely on getting the xsd files from your Internet location. Whoever put it back after deleting it changed the definition of the password-encoder element. It is different than the xsd's for 5.2 and 5.3 that are in https://github.com/spring-projects/spring-security/blob/master/config/src/main/resources/org/springframework/security/config/spring-security-5.2.xsd. Where did this come from and is this they type of thing we can expect in the future?
Comment From: qeepcologne
thanks, the file (http://www.springframework.org/schema/security/spring-security-oauth2-2.0.xsd) is downloadable.
Comment From: dc-oe
Why was the password-encoder definition changed in http://www.springframework.org/schema/security/spring-security.xsd?
Comment From: dc-oe
This is the XML fragment that started failing after last night's schema fiasco.
<authentication-provider>
<password-encoder ref="sha256passwordEncoder">
<salt-source user-property="username" />
</password-encoder>
Any thoughts as to why? Have we been misusing it all this time?
Thanks
Comment From: FelixJongleur42
Just my two cents, but as an interim solution it may be better to put up an non versioned file that is more backwards compatible not to break any applications that depend on it during runtime? Probably even the 4.0? (Well, the one that was up two days ago)
Comment From: jzheaux
@dc-oe good questions, and sorry to hear about the trouble you are having.
The spring-security.xsd hosted at springframework.org was stale, being symlinked to a 4.x version. During the release, the symlink was removed, but it's now correctly pointing to the latest 5.x version of the XSD. Since it's a major version change, there may be some non-passive changes.
If you are pointing to the hosted version of spring-security.xsd, that's effectively stating that you are okay with getting the latest version of the XSD. It sounds like that's not actually what you are wanting.
If you are dependent on a specific hosted version of the XSD, e.g. spring-security-4.2.xsd, it would be best to specify that in your application.
Comment From: dc-oe
Thanks. Here is what happened. When we updated to 5.2, from 4.x, we went with the versionless schema. However, we used http: instead of https: and didn’t realize this was causing us to retrieve the schemas from the Internet. It also caused us to miss this change in our XML.
This just so happened on the day we were making our go/no go decision on releasing this version. Final testing in India noticed when the schemas went missing, and then we noticed when the updated schema went up. Due to this glitch, we caught something before our customers did, so it actually was a bit of luck that this happened.
Dave
From: Josh Cummings notifications@github.com Sent: Friday, March 13, 2020 8:04 PM To: spring-projects/spring-security spring-security@noreply.github.com Cc: David Cleary davec@progress.com; Mention mention@noreply.github.com Subject: Re: [spring-projects/spring-security] http://www.springframework.org/schema/security/spring-security.xsd is gone!? (#8104)
@dc-oehttps://github.com/dc-oe good questions, and sorry to hear about the trouble you are having.
The spring-security.xsd hosted at springframework.org was stale, being symlinked to a 4.x version. During the release, the symlink was removed, but it's now correctly pointing to the latest 5.x version of the XSD. Since it's a major version change, there may be some non-passive changes.
If you are pointing to the web version of spring-security.xsd, that's effectively stating that you are okay with getting the latest version of the XSD. It sounds like that's not actually what you are wanting.
If you are dependent on a specific version of the XSD, e.g. spring-security-4.2.xsd, it would be best to specify that in your application.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/spring-projects/spring-security/issues/8104#issuecomment-598978006, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AI473R7LMQT3LJ7LPW2ZDXDRHLCYJANCNFSM4LGGT33Q.
Comment From: jzheaux
@dc-oe Glad to hear that it worked out, and that you got the benefit of moving to https:// for it.
Comment From: jzheaux
I've created https://github.com/spring-gradle-plugins/spring-build-conventions/issues/81 so that Spring Security can ensure the spring-security-oauth schema files are in the correct place.