Spring Boot version: 1.3.0.M3 H2, Spring Security, and DevTools are all in the POM.

No special Spring Security config other than an in-memory auth provider.

When I go to /h2-console, I'm able to see the connection config screen. However, when fill in the info and click Test, I receive the error message:

There was an unexpected error (type=Forbidden, status=403). Invalid CSRF Token 'null' was found on the request parameter '_csrf' or header 'X-CSRF-TOKEN'.

If possible, the H2 console autoconfig should add a CSRF rule to Spring Security config for whatever servlet path it is configured to use (/h2-console or otherwise).

Comment From: wilkinsona

That should already happen. I wonder if you're being affected by #3726. Have you explicitly set spring.h2.console.enabled=true? Sadly, the auto-configuration won't kick in without it at the moment.

Comment From: alexhutnik

I have added that to the properties file and am still experiencing the issue. Using Google Chrome if that helps.

Comment From: wilkinsona

It works for me with Chrome (and Safari), both on OS X. I just double-checked using the Actuator sample. What does your auto-configuration report say (run with --debug). You should see the following listed in the positive matches:

   H2ConsoleAutoConfiguration
      - @ConditionalOnClass classes found: org.h2.server.web.WebServlet (OnClassCondition)
      - found web application StandardServletEnvironment (OnWebApplicationCondition)
      - matched (OnPropertyCondition)

   H2ConsoleAutoConfiguration.H2ConsoleSecurityConfiguration
      - @ConditionalOnClass classes found: org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter (OnClassCondition)
      - matched (OnPropertyCondition)
      - @ConditionalOnBean (types: org.springframework.security.config.annotation.ObjectPostProcessor; SearchStrategy: all) found the following [objectPostProcessor] (OnBeanCondition)

Perhaps you've switched of basic auth (set security.basic.enabled to false)? If so, you'll need to provide your own security configuration for the H2 console.

Comment From: alexhutnik

Yup the debug output looks like what I have here locally. I did notice this:

Skipped (empty) config file 'classpath:/application.properties' for profile default

So perhaps it is not reading the correct setting?

Comment From: wilkinsona

That log output is expected (although a little misleading), and I see the same when the console works.

There's clearly something different in your setup that you haven't described. If you'd like me to continue trying to help please provide a small sample that reproduces the problem.

Comment From: alexhutnik

Certainly. Thank you for your help. I have not yet ruled out something amiss with this workstation. I will try to recreate on a different machine with a simple app I can demonstrate the issue with.

Comment From: alexhutnik

I seem to have narrowed it down to happening when I use my own WebSecurityConfigurerAdapter (for the in-memory auth provider I mention above). Does setting up my own web security config override all other "out of the box" security auto-configuration?

Comment From: wilkinsona

Does setting up my own web security config override all other "out of the box" security auto-configuration?

That depends on two things: - The @Order of your WebSecurityConfigurerAdapter - The paths that you've applied your security configuration to

You need to either ensure that your WebSecurityConfigurerAdapter has a higher order (lower precedence) than H2ConsoleSecurityConfigurer (it uses SecurityProperties.BASIC_AUTH_ORDER - 10) or you need avoid applying any configuration to the console's path (/h2-console/** by default).

Comment From: wilkinsona

This discussion seems to have run its course. Closing.

Comment From: FyiurAmron

@wilkinsona FWIW, it happened to me today, with the workaround soluton being https://jessitron.com/2020/06/15/spring-security-for-h2-console/ (which, thankfully, helped, and is mirrored by other people noticing the exactly same problems on blogs , https://www.logicbig.com/tutorials/spring-framework/spring-boot/jdbc-security-with-h2-console.html , https://stackoverflow.com/questions/43794721/spring-boot-h2-console-throws-403-with-spring-security-1-5-2 , https://springframework.guru/using-the-h2-database-console-in-spring-boot-with-spring-security/ , etc.)

I got

2021-10-09 23:26:49.378 DEBUG 2572 --- [io-8080-exec-10] o.s.security.web.csrf.CsrfFilter         : Invalid CSRF token found for http://localhost:8080/h2-console/test.do?jsessionid=f9f5d5b7f296c6e65a3507c9b35dc890
2021-10-09 23:26:49.378 DEBUG 2572 --- [io-8080-exec-10] o.s.s.w.access.AccessDeniedHandlerImpl   : Responding with 403 status code

in my logs.

The setup was a clean Spring Boot 2.5.5 with Security and H2. No WebSecurityConfigurer in the project. I'm stumped. If saying "This discussion seems to have run its course." and closing this issue resolved anything, then I'm probably missing what and when.

Comment From: wilkinsona

This issue is six years old and was raised against Spring Boot 1.x where we had some auto-configured custom for the H2 console. This proved to be overly complicated and was removed in 2.0. In its place, PathRequest.toH2Console() was added to make it easier to secure the console in a way that meets your needs.

In short, if you want to use the H2 console in an environment where you also need security, then you'll now need to configure things yourself. If you're using configuration inspired by Jessica's blog post you may want to make a small refinement to use PathRequest.toH2Console(). I've opened https://github.com/spring-projects/spring-boot/issues/28268 so that we can improve the reference documentation in this area.

If saying "This discussion seems to have run its course." and closing this issue resolved anything, then I'm probably missing what and when.

I realise that you're probably frustrated, but sarcasm such as this isn't helpful. The issue was closed as we hadn't heard from the raiser in two months and we were unable to reproduce the problem that they described. Keeping track of open issues and prioritising them takes time. We choose to close issues that have become stale as it makes it easier for us to focus our attention and spend our time productively.

Comment From: FyiurAmron

@wilkinsona

I realise that you're probably frustrated, but sarcasm such as this isn't helpful.

If you did realise it, you probably wouldn't include that statement in your reply. Still, thank you for your prompt response and continued effort. Having a clear statement on this issue may someday help someone in situation like me to not spend time debugging things that simply aren't working due to design choices.