Spring Security — the clinic you didn't have

Multiple auth sources · method-level access control — no Java EE spec, no JAAS file

The recurring theme in the wrong options is mandatory external standards — Java EE Security, JAAS. Spring Security predates and deliberately sidesteps both; that independence is its whole design premise, the same "non-invasive" idea as the rest of Spring.

The permitAll() distractor is the one worth keeping: permitAll() runs the full filter chain and grants access; web.ignoring() is what skips the chain — and loses CSRF protection and security headers with it.

authentication · principal · UserDetails

The flow, five steps:

Authentication auth = SecurityContextHolder.getContext().getAuthentication();
UserDetails user = (UserDetails) auth.getPrincipal();

The one-word test: authentication = who are you; authorization = what may you do. Authentication always comes first, so "upon successful ___" is always authentication.

Two classes, two jobs — the distractors were each other's definitions

The chain again, with the job of each in one word:

Why two proxies rather than one: the Servlet container can only register plain Filters, and it knows nothing about Spring beans. DelegatingFilterProxy is a plain filter whose only job is to look up a Spring bean by name and hand off — that's the bridge. Everything after it is ordinary Spring.

Q30 accepted both real classes because both genuinely intercept requests — DelegatingFilterProxy at the container edge, FilterChainProxy immediately behind it.

Four of five true — it works with any return type, not just collections

The fact worth carrying: @PostAuthorize does not stop the method running — it runs, produces a result, and only then is the expression evaluated. So any side effects inside the method have already happened: rows written, emails sent, counters incremented. Only the return value is withheld.

That's why @PreAuthorize is preferred whenever the decision can be made from the parameters — it blocks the call before anything happens. Use @PostAuthorize only when the decision genuinely depends on what came back (typically ownership).

One more from that question: @EnableMethodSecurity belongs on a @Configuration class, not on the @Service where the snippet put it. It compiles either way, which is what makes it a nasty real-world bug.

Both presence and absence conditions exist — and there are two ordering tools

@ConditionalOnMissingBean is the important one — it's how every Boot auto-configuration backs off when you define your own bean.

And the two ordering tools, which the correct options covered:

That distinction — relative vs absolute — is exactly what the question tested, and it's the same pair you met on attempt #11's Q36.

Fine-grained scope rules work, and @EnableResourceServer is gone

EndpointRequest is the piece worth knowing — a matcher factory built for Actuator:

http.authorizeHttpRequests(auth -> auth
    .requestMatchers(EndpointRequest.to(HealthEndpoint.class)).permitAll()
    .requestMatchers(EndpointRequest.to(InfoEndpoint.class, MetricsEndpoint.class))
        .hasAuthority("SCOPE_actuator.read")
    .requestMatchers(EndpointRequest.toAnyEndpoint()).authenticated())
   .oauth2ResourceServer(oauth2 -> oauth2.jwt(Customizer.withDefaults()));

Why EndpointRequest rather than a path string: the base path is configurable (management.endpoints.web.base-path), so hardcoding /actuator/** breaks the moment someone changes it. EndpointRequest resolves the real paths at runtime.

On @EnableResourceServer: it belonged to the old, now-retired spring-security-oauth2 project. Since Security 5.2, resource-server support is built in and configured with .oauth2ResourceServer(...) — no separate annotation. Note the SCOPE_ prefix: JWT scopes become authorities named SCOPE_<scope> by default.