FilterRegistrationBean<CustomFilter> Does Not Apply With HttpGraphQlTester

[danielshiplett]

I've recently been asked to improve some security and testing of another team's application. They provide both a WebMVC and Spring for GraphQL API. As part of our security improvements, we layer another OncePerRequestFilter into WebMVC. This filter just creates some additional ThreadLocal context information (built upon Spring Security Jwt authentication) that helps our applications abstract away some of the complexity of an always changing security landscape that we face.

For our other applications, it has been easy to write tests that use MockMvc and Spring AddOns OAuth2 Test Support's @WithJwt test annotation. We have standardized personas that provide the minimal JWT we need to test our production Spring Security and custom abstractions.

As part of the process of updating this application, I have a test that makes use of the @AutoConfigureMockMvc to call a WebMVC endpoint. This simulates a user uploading new content to the application. Spring Security and our filter work fine. Here's a snippet of code followed by the logs that are generated:

    // plan ingest
    val importRequest = MockMvcRequestBuilders.multipart("/plans/import")
      .file(planFile)
      .contentType(MediaType.APPLICATION_JSON)
      .with(SecurityMockMvcRequestPostProcessors.csrf())

    val result = mockMvc.perform(importRequest).andExpect(MockMvcResultMatchers.status().isCreated).andReturn()

    2025-07-17T14:04:01.713-04:00 TRACE 24832 --- [APP] [    Test worker] w.c.CustomContextHolderFilter : doFilterInternal: /plans/import
    2025-07-17T14:04:01.738-04:00 TRACE 24832 --- [APP] [    Test worker] w.c.CustomContextHolderFilter : kradosUserProfileContext: app.security.context.OAuth2ResourceServerCustomContext@384e51f5
    2025-07-17T14:04:01.746-04:00  INFO 24832 --- [APP] [    Test worker] a.filter.RequestLoggingFilter    : Before request [POST /plans/import, client=127.0.0.1, user=local-user]
    2025-07-17T14:04:05.893-04:00  WARN 24832 --- [APP] [    Test worker] a.s.c.plan.PlanController          : plan upload time: PT4.113483S

The next step of the test is to then make a GraphQL query to return some information about the new content. Here's the test code snippet and the logs:

    // graphql all queries for the plan slug
    val client = MockMvcWebTestClient.bindToApplicationContext(context)
      .apply(SecurityMockMvcConfigurers.springSecurity())
      .defaultRequest(MockMvcRequestBuilders.post("/graphql").with(SecurityMockMvcRequestPostProcessors.csrf()))
      .configureClient()
      .baseUrl("/graphql")
      .build()

    val graphQlTester = HttpGraphQlTester.create(client);

    val importResultData: PartialImportResultData = jacksonObjectMapper().readValue(result.response.contentAsString)
    val slug = importResultData.slug
    val graphQlResponse = graphQlTester
      .documentName("planDetails")
      .variable("planSlug", slug)
      .execute()

    2025-07-17T14:04:06.101-04:00  WARN 24832 --- [APP] [    Test worker] a.CustomContextAccessor : >>>>****  getValue: app.security.context.EmptyCustomContext@a1ce033
    2025-07-17T14:04:06.332-04:00  WARN 24832 --- [APP] [    Test worker] a.CustomContextAccessor : >>>>****  setValue: app.security.context.EmptyCustomContext@a1ce033

In this case, in the logs, I can see my ThreadLocalAssessor implementation running to indicate that the GraphQL engine is asynchronously loading data from the DataFetcher. However, the EmptyCustomContext is indicative that my CustomContextHolder was never set. This means that the CustomContextHolderFilter was never executed. Which we can see is missing from the logs.

I'm guessing this has something to do with the fact that the application is WebMVC and not WebFlux, as I tried to @AutoConfigureWebTestClient and couldn't get any of the Spring Security test processors like csrf() or springSecurity() to apply to it. It was because of NULL httpHandlerBuilder and similar. That is also why I cannot use the MockMvcWebTestClient.bindTo(mockMvc).

The other possibility is that the GraphQL endpoint is in a different application context? And therefore, my filters aren't being applied to it at all?

I'd appreciate any guidance you can provide on this problem. Unfortunately, I cannot provide access to the actual code. And, unless really necessary, would like to avoid writing up a smaller example project, as it will probably still take significant time.

[rstoyanchev]

Spring Security does not support MockMvcWebTestClient, see spring-projects/spring-security#11334 and spring-projects/spring-security#9257, including workaround suggestion by @rwinch.

There is also a suggestion by a user in this comment that looks similar to what you've done. I haven't verified it but it seems like it should work. WebTestClient calls MockMvc through the MockMvcHttpConnector is adapted onto a call to MockMvc and that should create the request with the default request building as usual.

Could you clarify what configures your custom Filter in both test scenarios? I would expect to be added on the MockMvc builder, but there is no such thing in the above samples.

[danielshiplett]

The comment by the other user that you mentioned is exactly what I stumbled upon and tried. It was enough to get the CSRF injection working. Which got me to the point where I discovered that my own filters weren't executing and thus, @PreAuthorize statements on the GraphQL controllers were not passing.

We have several internal libraries that inject filters for us. One that I am responsible for and one that another team maintains that does things like creating a custom request logging filter that created the log in the successful MockMvc call:

a.filter.RequestLoggingFilter    : Before request [POST /plans/import, client=127.0.0.1, user=local-user]

The fact that my filter wasn't getting call lead me to investigate the other team's code and they too inject their filter with a FilterRegistrationBean. An example is:

  @Bean(name = "asyncCustomContextHolderFilterRegistration")
  public FilterRegistrationBean<CustomContextHolderFilter> asyncCustomContextHolderFilterRegistration(
      final ApplicationContext applicationContext) {
    LOG.info("Registering Async CustomContextHolderFilter");
    final FilterRegistrationBean<CustomContextHolderFilter> filterRegistrationBean =
        new FilterRegistrationBean<>();
    filterRegistrationBean.setEnabled(true);
    filterRegistrationBean
        .setFilter(new CustomContextHolderFilter(applicationContext));
    filterRegistrationBean
        .setDispatcherTypes(EnumSet.of(DispatcherType.REQUEST, DispatcherType.ASYNC));
    return filterRegistrationBean;
  }

I tried with the default DispatcherType.REQUEST and the two values you see above in case it was related to the async processing engine of the Spring for GraphQL. Neither option worked.

I will take a look at @rwinch's example in a little bit and get back to you. I also want to investigate this application in production and see if the RequestLoggingFilter is working there. If it isn't, this may not be related to testing and more related to how the Spring GraphQL context is loaded. Is there anything I should be aware of with FilterRegistrationBean and how it interacts with loaded contexts like Spring GraphQL?

[rstoyanchev]

Is there anything I should be aware of with FilterRegistrationBean and how it interacts with loaded contexts like Spring GraphQL?

No it has nothing to do with Spring GraphQL. I presume in the first example MockMvc is created by Boot auto-config, which detects and adds filters to it. In the second example you create MockMvc in your code with the call to MockMvcWebTestClient#bindToApplicationContext, and while the filter beans are in the context, there is nothing to detect and add them to MockMvc. That's Boot level support and you need Boot auto-config involved.

I suggest letting Boot create MockMvc, inject it into the setup of the test class, and call MockMvcWebTestClient#bindTo(MockMvc). I expect that should work.

[danielshiplett]

Alright, I had a chance to validate that the filters are running in production. And I had a chance to test out some of @rwinch's example code.

Switching to binding off the Auto-Configured MockMvc allowed the filters to execute in the test path.

    val client = MockMvcWebTestClient.bindTo(mockMvc)
      .baseUrl("/graphql")
      .defaultHeaders(csrf)
      .build()

    val graphQlTester = HttpGraphQlTester.create(client);

    val graphQlResponse = graphQlTester
      .documentName("planDetails")
      .variable("planSlug", slug)
      .execute()

And the injection of the authentication wasn't needed since the @WithJwt annotation is handling that just fine as well.

However, I wasn't able to get the mocked CSRF working. I created a mock bean (sorry this is Kotlin, so a little different from the example:

    @MockkBean
    lateinit var csrfTokenRepository: CsrfTokenRepository

  val defaultCsrf: DefaultCsrfToken = DefaultCsrfToken("X-CSRF-TOKEN", "_csrf", "123")
  val deferredCsrfToken = object: DeferredCsrfToken {
    override fun get(): CsrfToken {
      return defaultCsrf
    }

    override fun isGenerated(): Boolean {
      return true
    }
  }

  @BeforeEach
	fun setupCsrf() {
    every { csrfTokenRepository.generateToken(any())}.returns(defaultCsrf)
    every { csrfTokenRepository.loadToken(any())}.returns(defaultCsrf)
    every { csrfTokenRepository.saveToken(any(), any(), any())} returns Unit
    every { csrfTokenRepository.loadDeferredToken(any(), any()) }.returns(deferredCsrfToken)
	}

  val csrf: (HttpHeaders) -> Unit = { headers -> headers.set(defaultCsrf.getHeaderName(), defaultCsrf.getToken()) }

And I saw the note about having to explicitly use the mocked bean in the main security DSL:

http.csrf(csrf -> csrf.csrfTokenRepository(csrfTokenRepository));

I know for sure that the mock bean was being invoked across all call because I had to add the three additional mocked methods due to hitting errors with missing stubs. But I just couldn't get it to work. In the end, I gave up and converted the test to just disable CSRF while using the rest of my production security configuration. I have enough other tests using the full production security configuration that I trust CSRF is setup correctly.

I guess I am good to go for now. Thank you for all the guidance.