Spring Security PreAuthorizeExpressionAttributeRegistry#resolveAttribute can't find annotation on class when method is declared on superclass

Describe the bug Using @PreAuthorize annotation on Class is not found when method is declared on superclass.

To Reproduce

Tips: I'm using in reactive;

Create a class and define methods like:

class SomeApi {
    @XXXMapping("/hello")
    public Response hello(Request request) {
         return ...;
    }
}

Create a controller:

@RestController
@PreAuthorize("hasAnyRole('xxx')")
class Controller extands(implement) SomeApi {
// nothing here
}

Comment From: honhimW

Well, I was wondering if there are any updates on this? Basically, i personally solve this problem as follow

/**
 * @see org.springframework.security.authorization.method.PostAuthorizeExpressionAttributeRegistry#findPostAuthorizeAnnotation
 */
private PostAuthorize findPostAuthorizeAnnotation(Method method) {
    PostAuthorize postAuthorize = AuthorizationAnnotationUtils.findUniqueAnnotation(method, PostAuthorize.class);
    // org.springframework.security.authorization.method.PostAuthorizeExpressionAttributeRegistry#resolveAttribute
    // Use `targetClass`(from calling method argument) instead of `method.getDeclaringClass()`.
    return (postAuthorize != null) ? postAuthorize
        : AuthorizationAnnotationUtils.findUniqueAnnotation(targetClass, PostAuthorize.class); 
}

Comment From: kse-music

@jzheaux As you said in #15014 comment. In general, annotations declared lower in the hierarchy do not affect methods higher in the hierarchy. So now whether Spring Security still needs to support this scene?

Comment From: honhimW

@jzheaux @kse-music Hello guys, 👋

I noticed the discussions regarding this feature, but I am a bit confused about whether the discussion is about deciding to remove this feature? Personally, I hope to keep this feature as I really need it. From my perspective, it is logical for a security annotation on a subclass to also affect to its superclass.

If the decision is to remove it, could you make this behavior configurable? There is a lot of nested code involved here, and most of it is protected. If I need to modify it in my project, I would have to override a lot of code to implement this behavior for the class declared with the method or the class where the bean is located.

Comment From: quaff

FYI, I created #16295 to request restoring this feature, I don't think reverting is a good resolution for #15352.