Update spring-boot version to 3.1.2

[DanielFran]

---

Please make sure the below checklist is followed for Pull Requests.

• All continuous integration tests are green
• Tests are added where necessary
• The JDL part is updated if necessary
• jhipster-online is updated if necessary
• Documentation is added/updated where necessary
• Coding Rules & Commit Guidelines as per our CONTRIBUTING.md document are followed

When you are still working on the PR, consider converting it to Draft (below reviewers) and adding skip-ci label, you can still see CI build result at your branch.

[DanielFran]

@mshima The root cause:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'filterChain' defined in class path resource [tech/jhipster/sample/config/SecurityConfiguration.class]: Failed to instantiate [org.springframework.security.web.SecurityFilterChain]: Factory method 'filterChain' threw exception with message: This method cannot decide whether these patterns are Spring MVC patterns or not. If this endpoint is a Spring MVC endpoint, please use requestMatchers(MvcRequestMatcher); otherwise, please use requestMatchers(AntPathRequestMatcher).

[mshima]

@DanielFran just posted spring-projects/spring-boot#36500

[mshima]

Caused by spring-projects/spring-security#13568

[mshima]

@DanielFran are you planning to finish the update soon?

[DanielFran]

@mshima No, I am away 2 weeks from my laptop :P

[mraible]

@mshima How can I help move this along?

[mshima]

The remaining error is:

2023-08-16T13:19:44.870Z ERROR 1 --- [or-http-epoll-3] io.netty.util.ResourceLeakDetector       : LEAK: ByteBuf.release() was not called before it's garbage-collected. See https://netty.io/wiki/reference-counted-objects.html for more information._Recent access records: _Created at:__io.netty.buffer.SimpleLeakAwareByteBuf.unwrappedDerived(SimpleLeakAwareByteBuf.java:144)__io.netty.buffer.SimpleLeakAwareByteBuf.readRetainedSlice(SimpleLeakAwareByteBuf.java:67)__org.mariadb.r2dbc.client.MariadbFrameDecoder.decode(MariadbFrameDecoder.java:92)__io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:529)__io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:468)__io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290)__io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)__io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)__io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)__io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)__io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440)__io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)__io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)__io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:800)__io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:499)__io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:397)__io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)__io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)__io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)__java.base/java.lang.Thread.run(Unknown Source) 

[mshima]

From https://github.com/jzheaux/cve-2023-34035-mitigations#mitigations.
We probably should match controllers urls using mvc matcher.
Don't know about /management and /v3/api-docs/.

[mraible]

@gmarziou @mshima I don't know if I agree that we should use Ant matchers in JHipster 8, even if it makes upgrading easier. Using MVC matchers is the recommended pattern from Spring Boot and I believe we should follow it.

[mshima]

@gmarziou @mshima I don't know if I agree that we should use Ant matchers in JHipster 8, even if it makes upgrading easier. Using MVC matchers is the recommended pattern from Spring Boot and I believe we should follow it.

I think this recommendation was before the security issue was found at the link I've passed:

This method cannot decide whether these patterns are Spring MVC patterns or not.
If this endpoint is a Spring MVC endpoint, please use `requestMatchers(MvcRequestMatcher)`;
otherwise, please use `requestMatchers(AntPathRequestMatcher)`.

My initial understanding is that every resource except /h2-console and /websocket are considered Spring MVC endpoint. I have doubts about the ResourceHandler and management

[mraible]

@mshima OK. Thanks for the clarification. That makes sense.

[mshima]

After going through the issue and mitigation process, my understanding is that everything that goes through a DispatcherServlet should use a mvc matcher. ResourceHandler, actuator endpoints and websocket uses the DispatcherServlet.

So we should use mvc matcher for every url except h2-console which is served by a custom servlet.

I will check if actuator uses a second DispatcherServlet instance.

[gmarziou]

What about images and other static resources? Aren't they served by an Undertow servlet?

I'm still in favor of backward compatibility and stability over time.
Migration to Spring Boot 3 is already in itself a pain for app developers due to JDK 17, Spring Security, jakarta package, Springfox to Spring Docs, ...

[mshima]

What about images and other static resources? Aren't they served by an Undertow servlet?

They are served through spring‘s ResourceHandler that is served using DispatcherServlet.
If you extract the jar/war you will see resources inside classes/static folder instead of root folder.
I’m not sure about websocket. After a quick search seems that stomp is served by socksHandler or something like it.

I'm still in favor of backward compatibility and stability over time.

In this case jhipster v7 using antMatcher are wrong. The best explanation I’ve found is spring-projects/spring-security#13568 (comment).

[gmarziou]

In this case jhipster v7 using antMatcher are wrong. The best explanation I’ve found is spring-projects/spring-security#13568 (comment).

Good explanation yes but later comments show that there are issues with other servlets like h2 console (probably also when using h2 db as a server) and devtools, I suspect others may appear for any kind of embedded servers (e.g. distributed caches?)

This CVE is still open so I guess there is no conclusive answer yet.

[mshima]

Good explanation yes but later comments show that there are issues with other servlets like h2 console

There are a other things been discussed in the issue not only the security issue and fixes.

• why it needs to be a breaking change in a patch release?
• why not deprecate requestMatcher(string)?

If you take a look at the first commit from this PR, most of runs succeed. That happens if only 1 servlet is registered.
The issue about h2-console is that it requires an additional servlet so requestMatcher(string) cannot be used.

I didn’t investigate the reason for each sample failure.

The current fix for the security issue is to use mvcMatcher for Spring MVC, and make sure an DispatcherServlet with context-path (additional or not) to use like MvcPatternBuilder.servletPath(context-path).pattern('/**').
And use antMatcher for non-spring servlets like h2-console.

[DanielFran]

@pascalgrimaud bounty claimed: https://opencollective.com/generator-jhipster/expenses/171152