How are method-security checks physically applied — how are the interceptors registered and ordered as advisors?

## The whole mechanism is Spring AOP `@EnableMethodSecurity` doesn't invent a special container feature; it plugs into the ordinary **Spring AOP advisor + auto-proxy** infrastructure. ### 1. Advisor beans are registered The imported configuration (`MethodSecuritySelector` → `PrePostMethodSecurityConfiguration` and friends) declares, for each enabled annotation family, an **`Advisor`** bean. An `Advisor` bundles: - a **`Pointcut`** — matches methods (or classes) annotated with the target annotation, and - an **advice** — here an `AuthorizationManager`-backed `MethodInterceptor`. The concrete interceptor/advisor types include: - **`AuthorizationManagerBeforeMethodInterceptor`** — used for `@PreAuthorize` (and the `@Secured` / JSR-250 variants are also *before* interceptors, built via factory methods like `AuthorizationManagerBeforeMethodInterceptor.secured(...)` / `.jsr250(...)`). Runs the `AuthorizationManager` *before* the method. - **`AuthorizationManagerAfterMethodInterceptor`** — used for `@PostAuthorize`; runs *after* and can see the return value. - **`PreFilterAuthorizationMethodInterceptor`** / **`PostFilterAuthorizationMethodInterceptor`** — mutate collection args/returns. Each is published as a bean annotated `@Role(BeanDefinition.ROLE_INFRASTRUCTURE)` (so it's treated as plumbing, not app config) and typically `static @Bean` (to avoid premature bean initialization / to work before the bean factory is fully configured). ### 2. Auto-proxying wires them in Because these are `Advisor` beans, the standard **`InfrastructureAdvisorAutoProxyCreator`** (a `BeanPostProcessor`) sees them and, for every application bean whose methods match any advisor's pointcut, creates a **proxy** (JDK dynamic proxy if the bean implements interfaces, else CGLIB subclass). The proxy holds the interceptor chain. ### 3. At call time An **external** call hits the proxy → the applicable interceptor(s) run → each builds/uses its `AuthorizationManager` to produce an `AuthorizationDecision`. A *before* interceptor that denies throws `AccessDeniedException` before the target runs; an *after* interceptor can deny based on the result; filter interceptors strip disallowed elements. If granted, the call proceeds to the real method. ### 4. Ordering — `AuthorizationInterceptorsOrder` Since several interceptors may apply to the same method, order matters. Spring Security defines the enum **`AuthorizationInterceptorsOrder`** giving each advisor an `Ordered` value, roughly: `FIRST → PRE_FILTER → PRE_AUTHORIZE → SECURED → JSR250 → (method body) → POST_AUTHORIZE → POST_FILTER → LAST`. So filtering of inputs happens before the pre-authorize gate, the method runs, then post-authorize/post-filter act on the output. You can insert a custom interceptor at a chosen slot by giving it an order relative to these constants. ## Why this design matters (principal lens) - **Extensibility**: you can register your own `Advisor` / `AuthorizationManager` and slot it into the order — no subclassing of a monolithic config. - **Uniformity**: the same `AuthorizationManager` abstraction backs both request and method authorization. - **Observability/testing**: because it's plain AOP, you can reason about proxy creation, and diagnose "annotation not firing" as a proxy/self-invocation problem. ## Gotchas - **Self-invocation** bypasses the proxy → no interceptor → no check. Split beans or use `AopContext.currentProxy()` (with `exposeProxy`). - **`final`/`private` methods** can't be advised by CGLIB/JDK proxies. - **`static @Bean` requirement**: declaring these interceptor beans non-static can trigger warnings or eager-init ordering issues. - Bean must be **container-managed**; annotations on `new`-ed objects do nothing. - Changing `proxyTargetClass`/`mode` on `@EnableMethodSecurity` alters proxy strategy and thus what can be advised.