What happened. A custom authentication filter was added for one URL space, declared as
@Component and wired into a dedicated SecurityFilterChain with
securityMatcher("/api/**") and addFilterBefore(...). Spring Boot ALSO auto-registers
every bean of type Filter in the servlet container, on all requests. The filter then
rejected the login page too: it returned the API's 401 {"detail": ...} body instead of
the login form. The application was unreachable for humans.
What caught it. Only the Gate-3 browser walk. compileJava passed; Gate 2
(clean test) passed with 91 tests green, including tests that exercised the filter
directly and asserted its 401 behaviour — because they call the filter object, never the
servlet container. A @UiTest cannot see it either: it does not go through the container.
The fix:
@Bean
FilterRegistrationBean<MyAuthFilter> myAuthFilterRegistration(MyAuthFilter filter) {
FilterRegistrationBean<MyAuthFilter> registration = new FilterRegistrationBean<>(filter);
registration.setEnabled(false); // Spring Security still uses it; the container does not
return registration;
}
Why it matters. The failure mode is maximal — every screen of the application — and the
defect class is invisible to both mandatory gates. Any project adding a custom filter for a
REST or MCP endpoint hits it.
Suggested fix. Add one line to the mechanical floor in jmix-ide-static-analysis:
# a Filter bean is auto-registered on ALL requests unless a disabled FilterRegistrationBean exists
grep -rln "extends OncePerRequestFilter\|implements Filter" src/main/java --include='*.java'
Every hit must be paired with either a disabled FilterRegistrationBean or no bean
annotation at all. Worth a sentence in jmix-verify-bootrun too: this is a concrete example
of a defect that a green clean test cannot catch and Gate 3 catches immediately.
Found while building a real Jmix 2.8 application (document registry, Vaadin UI, PostgreSQL, deployed behind nginx).
What happened. A custom authentication filter was added for one URL space, declared as
@Componentand wired into a dedicatedSecurityFilterChainwithsecurityMatcher("/api/**")andaddFilterBefore(...). Spring Boot ALSO auto-registersevery bean of type
Filterin the servlet container, on all requests. The filter thenrejected the login page too: it returned the API's
401 {"detail": ...}body instead ofthe login form. The application was unreachable for humans.
What caught it. Only the Gate-3 browser walk.
compileJavapassed; Gate 2(
clean test) passed with 91 tests green, including tests that exercised the filterdirectly and asserted its 401 behaviour — because they call the filter object, never the
servlet container. A
@UiTestcannot see it either: it does not go through the container.The fix:
Why it matters. The failure mode is maximal — every screen of the application — and the
defect class is invisible to both mandatory gates. Any project adding a custom filter for a
REST or MCP endpoint hits it.
Suggested fix. Add one line to the mechanical floor in
jmix-ide-static-analysis:Every hit must be paired with either a disabled
FilterRegistrationBeanor no beanannotation at all. Worth a sentence in
jmix-verify-bootruntoo: this is a concrete exampleof a defect that a green
clean testcannot catch and Gate 3 catches immediately.Found while building a real Jmix 2.8 application (document registry, Vaadin UI, PostgreSQL, deployed behind nginx).