Test using @WithMockUser fails with 401 UNAUTHORIZED with 3.2 #14207
Comments
andrashatvani
added
status: waiting-for-triage
|
I have the same issue after upgrade to 3.2.0 from Spring-Boot 3.1.5 |
Same for me. |
marcusdacoregio
removed
the
status: waiting-for-triage
|
Hi @andrashatvani, thanks for the report. Is it possible to provide a minimal, reproducible sample? Or if @RomanKosovnenko and @frederikmartin1337 could provide one, it would be of great value. |
|
We are facing a similar issue with webflux and spring security. that we did not get in Spring Boot 3.1 I tried to create a minimal report but was not able to reproduce it. It seems like somewhere along the way it loses its security context. But here it is not populating the security context and the context mono is empty. After this it fails. In my minimal repo when it hits the |
marcusdacoregio
added
status: waiting-for-feedback
|
Hi, everyone. I've created a minimal sample but I had no success reproducing the problem. Can someone apply the needed changes to make the problem reproducible? |
marcusdacoregio
added
the
status: waiting-for-feedback
|
I had a similar problem running tests in my Spring Webflux application which stopped working after upgrading from @ConditionalOnMissingClass({ "org.springframework.security.oauth2.client.registration.ClientRegistrationRepository",
"org.springframework.security.oauth2.server.resource.introspection.ReactiveOpaqueTokenIntrospector" })In the application properties for my tests I DO configure an OAuth2 client registration repository purely for the purposes of establishing client connections to external APIs. As a workaround, I added the missing |
spring-projects-issues
added
status: feedback-provided
@alex-arana Is it different from how I defined my custom bean in the bug description? |
marcusdacoregio
added
status: waiting-for-feedback
|
@marcusdacoregio I've created another sample project since our basics are so different e.g. I use Maven. You can find it at https://github.com/andrashatvani/sb32sec . Hope it helps. |
spring-projects-issues
added
status: feedback-provided
|
Thanks for the sample @andrashatvani. It took me a while to make it minimal and runnable, but I found some clues about the problem. I changed my sample to reproduce the error. The error is only triggered when we do |
This happens to me too in one of my projects. I have also solve it like that. I'm also not sure if letting csrf with its default value is ok. |
|
Hi, folks. Unfortunately, I haven't found the root cause yet, however, I can provide a simple workaround so you can update your applications: http.addFilterAt(new TestWebFilter(), SecurityWebFiltersOrder.CSRF);
// workaround for https://github.com/spring-projects/spring-security/issues/14207
static class TestWebFilter implements WebFilter {
@Override
public Mono<Void> filter(ServerWebExchange exchange, WebFilterChain chain) {
return Mono.empty().switchIfEmpty(chain.filter(exchange)).then();
}
}Some newest finding points out that there is something related to the Reactor Core and I'll talk with someone from their team early next week. |
|
@marcusdacoregio Unfortunately the workaround is not feasible for us as in the project the security configuration needs to remain untouched even in the integration tests. |
chemicL
added a commit
to reactor/reactor-core
that referenced
this issue
Dec 20, 2023
Recent improvements in the automatic context propagation (#3549) resulted in a regression – some sites where the "last operator" hook was previously applied no longer saw that behaviour. This change restores it. Implementation wise, it's worth noting that the "last operator" functionality relies on executing the subscribe(Subscriber) method from the base reactive-streams Publisher instead of the overloads that come from CorePublisher. The implementations of the reactive-streams base method in reactor-core apply this hook and that is when something is considered a "last operator". The wrapping of the Publisher when a non-internal producer is encountered to restore ThreadLocal values has changed the compiler's inference of the signature to use the CoreSubscriber argument variant, breaking the behaviour. This commit does not bring any tests as the functionality was not extensively tested before. The issue was discovered in spring-security in spring-projects/spring-security#14207 and the change has been validated against the actual use case.
|
Hi, everyone. Thanks to the help of @chemicL we managed identify a regression that happened in reactor-core As soon as reactor core |
|
The issue is caused by a regression introduced in reactor-core 3.6.0 and the PR linked above should bring back the previous behaviour. In the PR I expressed an opinion that the The issue with The latest-and-greatest context propagation features are described in our documentation. |
chemicL
added a commit
to reactor/reactor-core
that referenced
this issue
Jan 2, 2024
Recent improvements in the automatic context propagation (#3549) resulted in a regression – some sites where the "last operator" hook was previously applied no longer saw that behaviour. This change restores it. Implementation wise, it's worth noting that the "last operator" functionality relies on executing the subscribe(Subscriber) method from the base reactive-streams Publisher instead of the overloads that come from CorePublisher. The implementations of the reactive-streams base method in reactor-core apply this hook and that is when something is considered a "last operator". The wrapping of the Publisher when a non-internal producer is encountered to restore ThreadLocal values has changed the compiler's inference of the signature to use the CoreSubscriber argument variant, breaking the behaviour. This commit does not bring any tests as the functionality was not extensively tested before. The issue was discovered in spring-security in spring-projects/spring-security#14207 and the change has been validated against the actual use case.
|
With reactor-core 3.6.2 all tests pass indeed. |
|
@andrashatvani thanks for checking it so quickly and letting us know :) |
|
Closed via reactor/reactor-core#3673 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
The following test works with 3.1, but fails with 401 UNAUTHORIZED with 3.2:
To Reproduce
@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) }Expected behavior
The test works
Sample
Currently we have tried in 3 different projects with different services always with this same result, thus this might not be an isolated case, but rather a major issue, thus hopefully you can easily identify the cause.
The text was updated successfully, but these errors were encountered: