Каждое приложение сервлета может иметь несколько исполняемых реализаций Filter, прежде чем достигнет фактического Servlet. А общая картина примерно такая:
Spring предоставляет реализацию фильтра с именем DelegatingFilterProxy, который позволяет навести мост между жизненным циклом контейнера сервлетов и Spring ApplicationContext. Контейнер Servlet позволяет регистрировать фильтры, используя свои собственные стандарты, но он не знает о компонентах, определенных Spring. DelegatingFilterProxy можно зарегистрировать с помощью стандартных механизмов контейнера сервлетов, но делегировать всю работу Spring Bean, который реализует фильтр.
Имея в виду эту картину, мы можем сказать, что DelegatingFilterProxy — это подход, который Spring MVC использует для использования своих собственных стандартов при регистрации фильтров.
Когда вы предоставляете Spring Bean, который реализует Filter, он будет зарегистрирован внутри DelegatingFilterProxy.
FilterChainProxy — это специальный Filter, предоставляемый Spring Security, который позволяет делегировать множество экземпляров Filter через SecurityFilterChain. Поскольку FilterChainProxy — это Bean, он обычно упаковывается в файл DelegatingFilterProxy.
Вы можете видеть, что на этом гипотетическом изображении выше есть FilterChainProxy в качестве второго фильтра в цепочке фильтров (пунктирная рамка). Как только FilterChainProxy завершит обработку своих SecurityFilterChain фильтров, он вызовет originalChain (пунктирная рамка), чтобы возобновить обработку оставшихся фильтров, в приведенном выше сценарии — Filter2.
Также есть отличное объяснение в Spring Security ссылка, где я взял большую часть ресурсов, присутствующих в этом тексте.
Если вы хотите предотвратить регистрацию Filter в Spring, вы можете обратиться к этому вопрос о StackOverflow.
30.06.2021
