Spring Security Fix for 8223 breaks existing applications.

Summary

Fix for https://github.com/spring-projects/spring-security/issues/8223 forces POST requests, breaking existing applications using GET. The original reporting issues https://github.com/spring-projects/spring-security/issues/4183 notes this should be configurable, which I believe is the correct path here.

According to Spring documentation:

4.1. Release Numbering

Spring Security versions are formatted as MAJOR.MINOR.PATCH such that:

    MAJOR versions may contain breaking changes. Typically, these are done to provide improved security to match modern security practices.

    MINOR versions contain enhancements but are considered passive updates

    PATCH level should be perfectly compatible, forwards and backwards, with the possible exception of changes that fix bugs.

Therefore this change would not be applicable for a patch level release.

Actual Behavior

Requests to the SwitchUserFilter using GET method are rejected.

Expected Behavior

Requests to the SwitchUserFilter using GET method are accepted.

Configuration

We have a class that extends SwitchUserFilter , and uses securely encrypted tokens to verify the method parameters are unmodified and originate from a trusted source.

Version

Version 5.2.3 is first breaking version in the 5.2 series.

Comment From: jzheaux

Hi, @koan00, sorry that this is causing you some heartburn.

On rare occasions, like in cases where there are security implications, we will break semantic versioning guidelines. In this case, we made the proactive choice to make the change on a patch release.

I'm going to close this issue as answered, but please feel free to continue the conversation if the configuration listed in #4183 fails to restore your application to the original behavior.

Comment From: jzheaux

Note that this release documentation is supposed to list tickets that break passivity, but it currently is not. I am looking into correcting this.

Comment From: koan00

Thanks @jzheaux the work around does indeed work, although it's a little less convenient than just calling setSwitchUserUrl and setExitUserUrl. I suppose the only concern left would be how discoverable this methodology would be to other users running into the same issue.

Thanks again.

Comment From: jzheaux

The release notes for 5.2.3 are now showing that issue as a breaking change.