Open dyleph opened 5 months ago
Hi @dyleph, thanks for the report. Are you able to provide a minimal, reproducible sample that we can run on our side? Looks like your application has some customizations that will make it harder for us to reproduce the same behavior.
Hi, same problem for us
Do you know when it will be fixed and if it will be included in Spring Boot 3.3.1?
Hi folks, based on my tests I got a proper 403 returned. It would be great if you could provide a minimal sample that we can use to reproduce the problem on our side.
Hello I have the same problem when using a Custom ApplicationExceptionHandler extending ResponseEntityExceptionHandler. It seams that AccessDeniedException are automatically catched when using this type of handler but not AuthorizationDeniedException. It is possible to add a custom exception handler for AuthorizationDeniedException to bypass this problem but it should not be necessary.
import org.springframework.web.servlet.mvc.method.annotation.ResponseEntityExceptionHandler;
@ControllerAdvice
class ApplicationExceptionHandler extends ResponseEntityExceptionHandler {
@ExceptionHandler(AuthorizationDeniedException.class)
ResponseEntity<String> handleAuthorizationDeniedException(AuthorizationDeniedException exception) {
return ResponseEntity.status(HttpStatus.FORBIDDEN).body("Access denied");
}
}
Hey Folks,
We're using Spring Boot version 3.3.1 and managing authorization with the @PreAuthorize annotation. Here's our security filter chain bean definition, where we permit all on the /error path. Despite this, exceptions thrown by Spring Security aren't handled correctly.
@Bean
@ConditionalOnProperty(value = "security.enabled", havingValue = "true", matchIfMissing = true)
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
return http.cors(Customizer.withDefaults())
.csrf(AbstractHttpConfigurer::disable)
.sessionManagement(sessionManagement -> sessionManagement.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
.authorizeHttpRequests(authRequest -> authRequest
.requestMatchers("/", "/docs/api-docs/**", "/ui/swagger-ui/**", "/actuator/health/**").permitAll()
.requestMatchers("/error/**").permitAll()
.requestMatchers("/api/**").authenticated()
)
.oauth2ResourceServer(resourceServer -> resourceServer.jwt(jwt -> jwt.jwtAuthenticationConverter(new CustomAuthenticationConverter(configProperties.clientId()))))
.build();
}
When Spring Security returns a 403 status, we receive a 500 status code instead. We can handle this by catching the exception in our codebase, but I think Spring Security should handle it automatically.
I get exactly the same result, where it throws a 500 error, for some reason...
Thanks for the reports. Unfortunately, our samples all appear to be returning 403s as expected. This doesn't mean that there isn't a bug, but it does mean that a minimal sample would be helpful.
@dyleph, I can't run the code you provided as it refers to methods like prepareHeaders
and classes like AuthAssertionParameterResolver
and AuthAssertion
that I don't have. If you aren't able to create a sample from scratch, perhaps you can alter one of the Spring Security Samples in a branch and post that here.
I'm not yet seeing a common enough thread in the reports to suppose that they are all the same problem. If someone can provide a minimal GitHub sample, then I'll be happy to dig into the issue.
Describe the bug When upgrading Spring boot from 3.2.5 to Spring boot 3.3.0, which contains a new version of Spring security 6.3, I got some failing test cases that should return a 403 FORBIDDEN status code instead returns a 500 INTERNAL SERVER ERROR.
Spring Boot: 3.3.0 Spring Security: 6.3.0
To Reproduce Here is a
controller class
and
SecurityConfiguration.class
and here is an Integration test class:
The test is failing when trying to assert status code when the user does not have the required permissions (403)
Actual behavior
Expected behavior The endpoint should return a 403 FORBIDDEN status code when the user does not have the required permissions.
Regarding there is a related change in new Sping Security 6.3 (https://github.com/spring-projects/spring-security/pull/14712/files), I guess there is something that we could handle.
Best Regards, Dy