Resolves #28268.

The WebSecurityCustomizer is a bit blunt. But for a development setup, a proper SecurityFilterChain seems overly ceremonial, in my opinion. 😄

Comment From: hpoettker

@snicoll @wilkinsona Thanks for the feedback!

I'll rewrite the PR to show how a dedicated SecurityFilterChain can be exposed for the console.

Comment From: wilkinsona

I'm not sure that we should go that far. The security for the console may need to be quite complex, and that'll depend on the user's security configuration which is an unknown to us. I think we should avoid prescribing a particular approach and just point out any common pitfalls such as the situation with CSRF protection.

Comment From: hpoettker

I removed the code snippet and added some explanations on what needs to be done together with a warning not to do it in production.

Comment From: wilkinsona

@hpoettker Your code snippet in https://github.com/spring-projects/spring-boot/pull/29932/commits/1573e32e0011dcf8dae0e5076a0a1e4029985c23 has changed my mind. I was concerned about providing something that users would copy and paste and try to use as-is. I think your snippet is informative without making that too much of a risk. Sorry to be a pain, but would you mind reinstating it?

Comment From: hpoettker

@wilkinsona I reverted the last commit. Quick thing and no pain at all. 😄

I fully agree that one needs to be careful with publishing code snippets in the reference documentation that have the potential to create security risks if used lightheartedly. The code snippet makes it pretty clear that it is not supposed to be used in production code. However, if just the bean method is copied verbatim and the comment asking for authorization to be configured is ignored, then the H2 console is again unprotected as in the first draft with the WebSecurityCustomizer. I realized that only after pushing, and then wrote the version without any code snippet.

Comment From: hpoettker

The code snippet that I came up with that is the most safe to be copied and pasted is

@Component
@Order(Ordered.HIGHEST_PRECEDENCE)
public class H2ConsoleFilterBean extends HeaderWriterFilter {

  private final RequestMatcher h2ConsoleRequestMatcher = PathRequest.toH2Console();

  public H2ConsoleFilterBean() {
    super(Arrays.asList(new XFrameOptionsHeaderWriter(XFrameOptionsMode.SAMEORIGIN)));
  }

  @Override
  protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)
      throws ServletException, IOException {
    CsrfFilter.skipRequest(request);
    super.doFilterInternal(request, response, filterChain);
  }

  @Override
  protected boolean shouldNotFilter(HttpServletRequest request) {
    return !h2ConsoleRequestMatcher.matches(request);
  }

}

But this code snippet is quite dense and may confuse more people than it helps.

Comment From: linghengqian

@hpoettker - It seems that Spring Security encourages the adoption of the Lambda DSL instead of and(), in your opinion, would the following be better?

@Bean
@Order(Ordered.HIGHEST_PRECEDENCE)
SecurityFilterChain h2ConsoleSecurityFilterChain(HttpSecurity http) throws Exception {
    return http.requestMatcher(PathRequest.toH2Console())
            .csrf(AbstractHttpConfigurer::disable)
            .headers(headers -> headers.frameOptions(HeadersConfigurer.FrameOptionsConfig::sameOrigin))
            .build();
}

Comment From: hpoettker

Hi @linghengqian, thanks for joining the discussion! Please note that your question could be perceived as off-topic here and that I won't answer it. As an unaffiliated contributor, I really have no authority to do so.

Comment From: wilkinsona

The Spring Security docs seem to use the lambda-style API, such as in their example for disabling CSRF. I think it makes sense to align with that. I've opened https://github.com/spring-projects/spring-boot/issues/30432.