Trying to upgrade an "old" Sprint Boot + Spring OAuth2 application in 1.3.x, to, hopefully, 2.1.5.RELEASE or whatever it's gonna be at the time.
I'm just trying to do it one step at a time. I got it from Spring Boot 1.3 to 1.4 and everything seems to work fine.
The problem is from 1.4 to 1.5. Basically, my web services protected by my Resource Server don't seem to get hit at all (it's falling back to WebSecurity/User workflow I believe, returning a 302 redirect to login page).
From the logs I can see that it's not even trying to match my request with the pattern I defined in my ResourceServerConfigurerAdapter.
[...].AntPathRequestMatcher::matches::::::Checking match of request : '/v1/private/user'; against '/oauth/token'
...(same as above against other paths)...
[...].OrRequestMatcher::matches::::::No matches found
In other words, none of those "against" is anything like I configured in configure( HttpSecurity http ) which is simply:
http
.authorizeRequests()
.antMatchers( "/v1/**" )
.permitAll()
.and().csrf().disable()
The same code in Sprint Boot 1.4 works fine and it does check the incoming request against that pattern /v1/** as expected.
I've read the release notes of Spring Boot 1.5, and I'm thinking it might be something related to this:
[...] using @EnableWebSecurity will switch off all auto-configuration of web security thereby allowing you to take complete control.
Remember, the application works fine in Spring Boot 1.3 and 1.4. It's when I'm upgrading to 1.5 that I'm having this issue.
Update 06/07: Autowired FilterChainProxy to see the filters involved and compare between the 2 Spring Boot versions. And if I understand correctly, that's the problem. In 1.4.x version, the order of filter chains inside FilterChainProxy is basically:
Now when using 1.5.x, somehow, #2 and #3 above are switched. Which explains why non of my web service requests are hitting my web service endpoints. Don't understand why the order got messed up (I do not use any @Order in my config). Time to look into @Order I guess...
Anyone else experienced that problem? How did you solve it?
Sure enough, the trick was to add the following to my extension of WebSecurity ConfigurerAdapter:
@Order(SecurityProperties.ACCESS_OVERRIDE_ORDER)
Found answer on SO here.