DelegatingMethodSecurityMetadataSource can not correctly resolve ConfigAttribute when Combined using annotation Secure JSR-250 and PrePost

this may cause security rule become invalid unintendedly .

Related codes ：

https://github.com/spring-projects/spring-security/blob/master/core/src/main/java/org/springframework/security/access/method/DelegatingMethodSecurityMetadataSource.java

for (MethodSecurityMetadataSource s : methodSecurityMetadataSources) { attributes = s.getAttributes(method, targetClass); if (attributes != null && !attributes.isEmpty()) { break; } }

Comment From: jzheaux

Thanks for the suggestion, @VikkeyJiang.

The JavaDoc for DelegatingMethodSecurityMetadataSource states (emphasis mine):

Automatically tries a series of method definition sources, relying on the first source of metadata that provides a non-null/non-empty response

Based on the JavaDoc, only considering the first match is precisely the intent of this class. I hesitate to change it to somehow collect and merge all attributes, as this would likely break passivity. Additionally, this class is already in line with other composite classes, like ProviderManager, which also stop at the first non-null result.

That said, you can do the work of combination yourself through a custom implementation, like so:

@EnableGlobalMethodSecurity
public class MergedConfigAttributes extends GlobalMethodSecurityConfiguration {
    protected MethodSecurityMetadataSource customMethodSecurityMetadataSource() {
        // ... return custom implementation that merges results
    }
}

Or, you might consider weighing in on https://github.com/spring-projects/spring-security/pull/6794 as it may have an impact on how you meet your application's requirements.

Comment From: VikkeyJiang

Hi @jzheaux As a new user of spring security , i receive most information from "spring security reference" ,not the javadoc , since this is default implementation, i suggest add some notice in "spring security reference"

Comment From: jzheaux

This is good feedback, @VikkeyJiang. Yes, it's easy to forget to check a class's JavaDocs when considering a change to it; I've done the same thing before myself.

While the reference docs are indeed authoritative, I don't think they should replace JavaDocs - each has its purpose. Indeed there are a number of places in the reference documentation that say something like "for more information on this, read the JavaDoc".

That said, the reference documentation is a good place for describing use cases (e.g. how do I XYZ?) - would you like to make a contribution to the reference along these lines? You might consider adding it here: https://docs.spring.io/spring-security/site/docs/current/reference/html5/#globalmethodsecurityconfiguration