В Spring-boot, который будет выполняться первым среди HandlerInterceptor, пользовательских фильтров и фильтров Spring-Security?

Question

Я новичок в Spring Security и, изучая, я узнал, что Spring Security внутренне представляет собой группу фильтров. Здесь я немного запутался, что по умолчанию, в каком порядке запускаются HandlerInterceptor, пользовательские фильтры и фильтры безопасности?

Я пытался искать в Интернете, но все говорят о различиях между этими фильтрами.

Answer 1

Spring-Security-Filters, User-defined-Filters, HandlerInterceptor позвольте мне поставить эти 3 другими способами

Фильтры: Spring-Security-Filters и User-defined-Filters
Механизмпосле DispatherServlet: HandlerInterceptor
^{(как показано на рисунке ниже)}

Как HandlerInterceptor следует после DispatcherServlet, Поскольку фильтры всегда обрабатываются до достижения сервлета , я могу с уверенностью сказать, HandlerInterceptor идет последним .

Теперь порядок Spring-Security-Filters против User-defined-Filters
Если вы используете традиционную Spring-MVC (не Spring Boot), где вы можете использовать конфигурацию на основе XML или Java. Вы можете добиться любого заказа для определенного пользователем фильтра. Либо вы можете разместить после весенней защиты (springSecurityFilterChain), либо до того, как указано ниже.

<filter>
    <filter-name>sessionLastAccessTimeUpdateFilter</filter-name>
    <filter-class>com.pvn.mvctiles.configuration.SessionLastAccessTimeUpdateFilter</filter-class>
</filter>
<filter-mapping>
    <filter-name>sessionLastAccessTimeUpdateFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

<filter>
    <filter-name>springSecurityFilterChain</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
    <filter-name>springSecurityFilterChain</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

Здесь в приведенном выше примере порядок sessionLastAccessTimeUpdateFilter выполняется до того, как springSecurityFilterChain сессия sessionLastAccessTimeUpdateFilter будет выполнена первой. Вы можете изменить порядок, если вам нужно. Эквивалентная конфигурация Java приведена ниже.

public class AppInitializer extends AbstractAnnotationConfigDispatcherServletInitializer
{
    @Override
    public void onStartup(ServletContext servletContext) throws ServletException
    {
        super.onStartup(servletContext);

        servletContext.addFilter("sessionLastAccessTimeUpdateFilter", new SessionLastAccessTimeUpdateFilter())
        .addMappingForUrlPatterns(null, true, "/*");

        servletContext.addFilter("springSecurityFilterChain", new DelegatingFilterProxy("springSecurityFilterChain"))
        .addMappingForUrlPatterns(null, true, "/*");
    }
}

Но пружинная загрузка отличается и налагает много ограничений по сравнению с традиционным подходом пружины. Spring boot не будет поддерживать web.xml, и регистрация фильтров разрешена только через FilterRegistrationBean, но здесь зарегистрированные фильтры идут после FilterChainProxy.

Но защита Spring предоставила возможность добавить фильтр между фильтрами безопасности Spring через .addFilterBefore() и .addFilterAfter()

Обратите внимание, что у пружинной защиты есть много прокси-фильтров или бинов с пружинным управлением, эти фильтры имеют определенный порядок. Если вы реализуете фильтр путем создания подкласса для UsernamePasswordAuthenticationFilter, то этот заказной порядок фильтров будет таким же, как порядок, определенный для UsernamePasswordAuthenticationFilter

Наконец, механизм HandlerInterceptor будет последним, но пружинные фильтры безопасности и фильтры, определенные пользователем, могутприходят в любом порядке, и это зависит от вашей конфигурации.

Чтобы иметь общее представление о выполнении этих фильтров, вы можете сослаться мой ответ

Answer 2

Фильтры Spring Security (т. Е. FilterChainProxy) должны выполняться первыми, поскольку смысл его существования заключается в защите всего доступа к URL, поэтому имеет смысл, чтобы он выполнялся в первую очередь, чтобы у запроса было достаточно разрешений, прежде чем выполнять другие фильтры.

HandlerInterceptor - это не сервлет Filter, а одна из функций Spring MVC. Подумайте, что это просто некоторые коды внутри сервлета Spring MVC (то есть DispatcherServlet). Поскольку Filter выполняется до Servlet, это означает, что, если любой другой определенный пользователем фильтр определен (я предполагаю, что определяемый пользователем фильтр - это сервлет Filter, зарегистрированный нормальнов web.xml или что-то эквивалентное) , оно будет выполнено до HandlerInterceptor.

Подводя итог, они должны выполняться в следующих порядках:

1. Фильтры Spring Security
2. Пользовательские фильтры
3. HandlerInterceptor