-
Notifications
You must be signed in to change notification settings - Fork 5.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
@PreAuthorize should not apply method security to inherited concrete methods #15352
Comments
Hi @MartinHaeusler, thanks for the report. Are you sure that it used to work in Spring Security 6.2.x? I'm trying a sample with Spring Boot 3.2.4, therefore Spring Security 6.2.4 and I see the handler method not being invoked:
Are you able to provide a minimal, reproducible sample where I can just change versions to simulate the problem? |
I just checked against all the supported branches and that doesn't work in any of them. |
@marcusdacoregio I apologize for the delay, I've been on vacation for the last two weeks. There is one detail we had in our codebase which I didn't include in the example (because I thought it doesn't matter): We had our Also, the popular tutorial site Baeldung recommends the abstract base class approach. We've moved all our In general, I would question if it is a good idea to apply any method security rules to a method that is annotated as |
This bug maybe exist in all branches. When an exception occurs, the Here is the test code
|
For backward compatibility, this commit changes the annotation traversal logic to match what is found in PrePostAnnotationSecurityMetadataSource. This reverts gh-13783 which is a feature that unfortunately regressess pre-existing behavior like that found in gh-15352. As such, that functionality has been removed. Issue gh-15352
Describe the bug
I don't know the exact spring security patch version where this behavior changed, but in 6.2.4 I had a setup like this:
In Spring Security 6.2.4, if an request comes in that does not match the
@PreAuthorize
condition, then Spring Security creates anAccessDeniedException
, and hands it over to thehandleAccessDeniedException(...)
method. Everything was fine.In Spring Security 6.3.1 (and maybe earlier as well, not sure, this is the version I'm currently upgrading to), something else happens:
@PreAuthorize
expression is evaluated and failsAccessDeniedException
is createdhandleAccessDeniedException
...AccessDeniedException
AccessDeniedException
as a warning with"Failure in @ExceptionHandler handleAccessDeniedException"
Overall, this results in a HTTP 403 for the client, no matter what the
handleAccessDeniedException
method would have done, because it never gets called.The workaround is to move all
@ExceptionHandler
methods to an external@ControllerAdvice
class, as those are not subject to the method security imposed by the class-level@PreAuthorize
annotation. In Spring Security 6.2.4 this worked out of the box.I think this is a weird breaking change and a potential pitfall for developers. Nobody would think that spring would intercept itself, applying method security on an exception handler method.
The text was updated successfully, but these errors were encountered: