Introduce a mechanism to disable existing filters/servlets beans

[cemo]

It is quite possible to include a library which is exposing a Filter/Servlet bean. Please introduce a mechanism for exclusion.

Here is the relevant section of code:

org.springframework.boot.context.embedded.ServletContextInitializerBeans#addAdaptableBeans

    private void addAdaptableBeans(ListableBeanFactory beanFactory) {
        MultipartConfigElement multipartConfig = getMultipartConfig(beanFactory);
        addAsRegistrationBean(beanFactory, Servlet.class, new ServletRegistrationBeanAdapter(multipartConfig));
        addAsRegistrationBean(beanFactory, Filter.class, new FilterRegistrationBeanAdapter());
        for (Class<?> listenerType : ServletListenerRegistrationBean.getSupportedTypes()) {
            addAsRegistrationBean(beanFactory, EventListener.class, (Class<EventListener>) listenerType, new ServletListenerRegistrationBeanAdapter());
        }
    }

#2171 is also related to this issue.

[philwebb]

Do you have any specific examples of libraries that are adding Filters/Servlets?

[philwebb]

OK, ignore that last comment. I see #2171 is related.

[dsyer]

There is a mechanism for exclusion, if you have an immediate problem and just need the solution. You create a *RegistrationBean and set it to enabled=false.

[cemo]

@dsyer, Please correct me If I am wrong. You mean that I should add another FilterRegistrationBean with same filter name. This will cause skipping new created FilterRegistrationBean but not actual one. Right?

[dsyer]

That wasn't what I meant. Why not use the enabled flag (it's just a Boolean property in the FRB)?

[cemo]

Because it is not a FilterRegistrationBean. It is a plain Filter.

@Bean(name=AbstractSecurityWebApplicationInitializer.DEFAULT_FILTER_NAME)
    public Filter springSecurityFilterChain() throws Exception {
        boolean hasConfigurers = webSecurityConfigurers != null && !webSecurityConfigurers.isEmpty();
        if(!hasConfigurers) {
            throw new IllegalStateException("At least one non-null instance of "+ WebSecurityConfigurer.class.getSimpleName()+" must be exposed as a @Bean when using @EnableWebSecurity. Hint try extending "+ WebSecurityConfigurerAdapter.class.getSimpleName());
        }
        return webSecurity.build();
    }

Here is the relevant code which is causing trouble. This piece of code is from Spring Security. Spring Security is exposing a Filter for internal usage. However Spring Boot is catching it and trying to register as a Servlet Api Filter.

[dsyer]

It's not really "for internal use" though is it? It's for your application security. If you don't want it, why is Spring Security on the classpath?

[dsyer]

And there's nothing to stop you creating a FilterRegistrationBean and injecting that Filter if you need to change its behaviour. You know its type and bean id.

[cemo]

I have not noticed that you had already added seen beans check. This is disabling existing filters as I stated in issue description.

But there is still a problem. Spring's DelegatingFilterProxy is binding filter at init phase of filter. Your check is invalid for this situation. Maybe checking filter name is an option? (By the way Servlet Api is already checking filter names. In case a duplicated already configured same name filter, It is skipping it. )

[dsyer]

OK so we appear to have agreed that there is already a mechanism in place for disabling existing filters. Maybe we need more documentation?

I don't get the last point about the "init" phase (there is no "init" phase for a Filter in a spring boot app - just the normal spring lifecycle). If you have a specific problem you are trying to solve, maybe you can explain it better with a small sample project?

[cemo]

+1 for more documentation.

I meant org.springframework.web.filter.DelegatingFilterProxy#initFilterBean method.

I am migrating a legacy application, I have to use FilterRegistrationBean + DelegatingFilterProxy currently. In case of a direct usage of FilterRegistrationBean + Security Filter, I am having issues. This is probably related to our application but at least currently I do not have any problem.

I believe that disabling mechanism of a filter is not complete without DelegatingFilterProxy support. In order to support such kind of filters, checking filter name might be a good idea.

[wilkinsona]

Someone on Stack Overflow with the same problem