The following test works with 3.1, but fails with 401 UNAUTHORIZED with 3.2:

@SpringBootTest(
    webEnvironment = RANDOM_PORT,
    classes = [Application::class],
    properties = ["spring.main.allow-bean-definition-overriding=true"]
)
@TestConstructor(autowireMode = ALL)
@WithMockUser(authorities = [ROLE_USER])
class HandlerIntegrationTest(
    @MockkBean
    private val searcher: Searcher,
    private val client: WebTestClient,
) {
    @Test
    fun search() {
        val searchResponse = SearchResponse(
            result = listOf(),
            page = 1,
            pageSize = 20,
            total = 0,
            filterOptions = FilterOptions(setOf(), setOf()),
            sort = setOf(),
            descending = listOf(false),
        )
        coEvery { searcher.search(any()) } returns searchResponse
        client.get()
            .uri { it.path("$ENDPOINT/search").build() }
            .exchange()
            .expectStatus()
            .isOk
            .expectBody<SearchResponse>()
            .consumeWith {
                assertThat(it.responseBody).isEqualTo(searchResponse)
            }
    }
}

A custom MapReactiveUserDetailsService has been in place and it looks like this:

    @Bean
    @ConditionalOnProperty(value = ["spring.security.user.passwordGenerated"], matchIfMissing = true, havingValue = "false")
    fun userDetailsService(): MapReactiveUserDetailsService {
        val actuatorUser = User
            .withUsername(securityProperties.user.name)
            .password("{noop}${securityProperties.user.password}")
            .authorities(AUTHORITY_ACTUATOR, AUTHORITY_ACCESS_MONITORING, AUTHORITY_ACCESS_INTERNAL_API).build()

        val monitoringUser = User
            .withUsername(monitoringProperties.username)
            .password("{noop}${monitoringProperties.password}")
            .authorities(AUTHORITY_ACCESS_MONITORING)
            .build()

        return MapReactiveUserDetailsService(actuatorUser, monitoringUser)
    }

Comment From: wilkinsona

@WithMockUser is a Spring Security feature so, on first impressions, this is unlikely to be a Spring Boot bug and is more likely to belong in the Spring Security repository. To help us to check that, please provide a complete yet minimal sample that reproduces the problem. Unless Kotlin is required to reproduce the problem, such a sample should be written in Java. You can share it with us by pushing it to a separate repository on GitHub or by zipping it up and attaching it to this issue.

Comment From: andrashatvani

@wilkinsona Could you please move this issue to Spring Security? Perhaps they might instantly have an idea for the root cause even without the time-consuming creation of a sample project.

Comment From: wilkinsona

Unfortunately not. To be able to move an issue you have to have commit rights to both the source and target repository and no one on the Boot team is a Spring Security committer. You may, of course, close this issue and open a Spring Security issue if "moving" the issue is your preferred course of action.

Comment From: andrashatvani

Then I'll create a new one over there and keep this one open only as long as there isn't a solution.

Comment From: wilkinsona

We prefer not to have two open issues tracking the same problem as it may result in duplicate and wasted effort. I'll close this one in favor of https://github.com/spring-projects/spring-security/issues/14207 for now. If it turns out that a change is needed on the Spring Boot side, we can re-open this issue.