Migrate to latest Spring Security - Update matcher methods. Part 2

helpful!!

Hey, that's almost exactly what I had been looking for ;D
Maybe you could explain the details on why do we need that AntMatcher for the second path we want to open (in this case - "h2-console/**"). Why can't we just use the .requestMathers? Or ... also the .requestMathers(/*accept multiple parameters here*/); which I tried and it also didn't work, so what's the point of multiple parameters?...
Thanks for valuable info!

Found out migration from Spring Boot 2.* to 3.* the hard way just yesterday. I migrated a multi-project gradle project yesterday. It took me just a few minutes to migrate the EE stuff like javax.* to jakarta.* and leveling up spring boot 2.7.15 to 3.1.4. Everything was fine except Spring Security :( I was lucky because I already migrated the "old" extending WebSecurityConfigurerAdapter to the new @Bean version beforehand. The real hard point was authentication. We have an SPA with Spring as an API backend with persistent sessions (yes, we need it that way). I had to figure out how to migrate SecurityContextHolder.getContext().setAuthentication(authentication); to Spring Boot 3.* It turned out, that I had to provide a Bean for SecurityContextRepository and access it where we had the setAuthentication() part. And there, additionally, I had to inject the SecurityContextRepository and save the SecurityContext explicitly.

The second (and third) part was, that the SPA (Angular) provided the CSRF token (out-of-the-box with a pre-defined module) in raw format and not in Base64 format, as it is expected in Spring Security now. So I had to further specify the XorCsrfTokenRequestAttributeHandler in WebSecurityConfig (filterChain) csrfTokenRequestHandler(requestHandler::handle). We also required that for WebSocket connections, which is another part of Spring (WebSocket) Security.

That was quite hard but straight-through at the end, when I think of it in the past.

The "secret" behind Spring is having the know-how of how to do complex stuff. Then, the Framework will assist you with not requiring any boilerplate code or at least a minimum amount of it. And the real secret is how to not write code that could brake Spring stuff and read the docs really really carefully. But: Who really has the time to figure out _all_ the docs in a daily dev life during workdays?

So I talked about "the hard way" in the beginning. It was not as hard as it may be read here. I invested 1 full work day yesterday and I will have 1 work day more to invest for dev testing on Monday. ;) I had more complex migrations in the past.

But, and that's the point, Sergey, you point out things as straight and effective as human could do! Perfect! You should be standing in front of the camera as official Spring Boot migration, Spring Security and attacks-like-csrf-mitigating guy, directly sponsored by the Pivotal team! Perfect videos!!

Good video man!!!

I hope you will make more videos. waiting for it.