Cosa sono i filtri (Filter)?

I filtri sono una funzionalità standard J2EE che consente di elaborare operazioni aggiuntive per tutte le richieste corrispondenti a un modello di URL prima o dopo che la richiesta venga inoltrata al servlet di dispatch (Dispatcher Servlet). In altre parole, i filtri vengono gestiti dal contenitore Web, come Tomcat, anziché dal contenitore Spring, quindi elaborano le richieste prima che queste raggiungano il servlet di dispatch.

Implementazione dei filtri (Filter)

Per aggiungere un filtro, è necessario implementare l'interfaccia Filter di javax.servlet. L'interfaccia ha tre metodi:

• Metodo init
  • Questo metodo viene utilizzato per inizializzare l'oggetto filtro e aggiungerlo al servizio. Il contenitore Web chiama una volta il metodo init per inizializzare l'oggetto filtro. Dopo l'inizializzazione, le richieste successive verranno elaborate tramite il metodo doFilter().
• Metodo doFilter
  • Questo metodo viene eseguito dal contenitore Web prima che tutte le richieste HTTP corrispondenti al modello di URL vengano inoltrate al servlet di dispatch e prima che il servlet di dispatch invii una risposta HTTP al client.
    Il metodo doFilter() accetta come parametro FilterChain. Tramite doFilter() di FilterChain, la richiesta viene inoltrata alla destinazione successiva. È possibile eseguire il processo desiderato inserendo il processo desiderato prima e dopo chain.doFilter().
• Metodo destory
  • Questo metodo viene utilizzato per rimuovere l'oggetto filtro dal servizio e restituire le risorse utilizzate. Viene chiamato una volta dal contenitore Web. Dopo di che, l'oggetto filtro non verrà più elaborato tramite doFilter().

Codice di esempio - Specifica Servlet

@WebFilter("/*")
public class dolphagoFilter implements Filter {

    @Override
      public void init(FilterConfig filterConfig) throws ServletException {}

    @Override
      public void doFilter(ServletRequest request, ServletResponse response, 
FilterChain filterChain) throws IOException, ServletException {
        //Pre-processing
        request.setCharacterEncoding("UTF-8");
        System.out.println("Prima di doFilter()....");

        filterChain.doFilter(request, response);

        //Post-processing
        System.out.println("Dopo doFilter()....");
      }

    @Override
      public void destroy() {    }

Codice di esempio - @Component

@Order(1)
@Component
public class CustomFilter implements Filter {

    @Override
    public void init(FilterConfig filterConfig) throws ServletException { }

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
        throws IOException, ServletException {
        chain.doFilter(request, response);
    }

    @Override
    public void destroy() { }

• @Component: consente di registrare il filtro come bean Spring.
• @Order: consente di ordinare i filtri se ne sono presenti più di uno.
• Se registri un filtro corrispondente alla specifica del servlet come bean Spring, puoi utilizzare altri bean corrispondenti alla specifica Spring.

Codice di esempio - @Configuration

@Configuration
public class CustomRegistrationBean {

    @Bean
    public FilterRegistrationBean customFilterBean() {
        FilterRegistrationBean registration = new FilterRegistrationBean<>();
        registration.setFilter(new CustomFilter());
        registration.setOrder(1);
        registration.addUrlPatterns("/api/*");
        return registration;
    }

Se vuoi che un filtro funzioni solo per un determinato URI, puoi utilizzare FilterRegistrationBean per registrare il filtro come bean Spring.

Scopo dei filtri (Filter)

I filtri vengono principalmente utilizzati per la convalida e l'elaborazione dei parametri della richiesta stessa.

• Operazioni comuni relative alla sicurezza
  • Poiché i filtri vengono eseguiti nel contenitore Web, possono essere utilizzati per eseguire controlli di sicurezza (ad esempio, protezione da XSS, CSRF) e bloccare le richieste non valide. Ciò può aumentare la sicurezza, impedendo che le richieste raggiungano il contenitore Spring.
• Registrazione di tutte le richieste
• Compressione di immagini/dati e codifica delle stringhe
  • I filtri sono stati implementati per funzionalità utilizzate in modo globale nelle applicazioni Web, come la compressione di immagini o dati e la codifica delle stringhe.
• Personalizzazione di ServletRequest
  • HttpServletRequest consente di leggere il contenuto del corpo una sola volta. Pertanto, né i filtri né gli interceptor possono leggere il corpo. È possibile creare un ServletRequest personalizzato per registrare il corpo.

Interceptor (Interceptor)

Cosa sono gli interceptor (Interceptor)?

A differenza dei filtri (Filter), che sono una specifica standard J2EE, gli interceptor (Interceptor) sono una tecnologia fornita da Spring. Consentono di fare riferimento o modificare le richieste e le risposte prima o dopo che il servlet di dispatch chiami il controller. In altre parole, a differenza dei filtri, che vengono eseguiti nel contenitore Web, gli interceptor vengono eseguiti nel contesto Spring.

Il servlet di dispatch richiede la mappatura dell'handler per trovare il controller appropriato. Di conseguenza, restituisce una catena di esecuzione (HandlerExecutionChain). Quindi, se questa catena di esecuzione contiene uno o più interceptor registrati, gli interceptor vengono attraversati sequenzialmente prima che venga eseguito il controller. Se non ci sono interceptor, il controller viene eseguito direttamente.

Implementazione degli interceptor (Interceptor)

Per aggiungere un interceptor, è necessario implementare l'interfaccia org.springframework.web.servlet.HandlerInterceptor. L'interfaccia ha tre metodi:

• Metodo preHandle
  • Il metodo preHandle viene eseguito prima che venga chiamato il controller. Pertanto, può essere utilizzato per elaborare le operazioni di pre-elaborazione che devono essere eseguite prima del controller, modificare le informazioni della richiesta o aggiungerle.
  • Il parametro handler, che è il terzo parametro del metodo preHandle, è un oggetto che astrattizza le informazioni del metodo contrassegnato da @RequestMapping.
  • Il tipo di ritorno del metodo preHandle è boolean. Se il valore restituito è true, si passa al passaggio successivo. Se è false, il lavoro viene interrotto e le operazioni successive (il prossimo interceptor o il controller) non vengono eseguite.
• Metodo postHandle
  • Il metodo postHandle viene eseguito dopo che il controller è stato chiamato. Pertanto, può essere utilizzato per elaborare le operazioni di post-elaborazione che devono essere eseguite dopo il controller.
• Metodo afterCompletion
  • Come suggerisce il nome, il metodo afterCompletion viene eseguito dopo che tutte le operazioni sono state completate, incluso il completamento della creazione del risultato finale da parte di tutte le visualizzazioni.

Codice di esempio

@Component
public class CustomInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
        throws Exception {
        return true;
    }

    @Override
    public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler,
        ModelAndView modelAndView) throws Exception {
    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex)
        throws Exception {
    }
}

@Configuration
public class WebMvcConfiguration implements WebMvcConfigurer {

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new CustomInterceptor());
        registry.addInterceptor(new LoggingInterceptor());
    }

• Registra l'interceptor creato come bean.
• Registra l'interceptor creato nel metodo addInterceptors() dell'interfaccia WebMvcConfigurer.
• Gli interceptor vengono eseguiti nell'ordine in cui sono registrati in InterceptorRegistry.

Scopo degli interceptor (Interceptor)

Gli interceptor vengono principalmente utilizzati per l'elaborazione della coerenza delle informazioni della richiesta utilizzando la logica del servizio.

• Operazioni comuni come l'autenticazione e l'autorizzazione
  • Ad esempio, le operazioni che coinvolgono la richiesta del client, come l'autenticazione o l'autorizzazione, possono essere verificate prima che la richiesta venga inoltrata al controller.
• Registrazione delle chiamate API
  • È possibile registrare le informazioni del client tramite gli oggetti HttpServletRequest e HttpServletResponse ricevuti.
• Elaborazione dei dati che vengono inoltrati a Controller
  • È possibile elaborare gli oggetti HttpServletRequest e HttpServletResponse ricevuti e inoltrarli a Controller.
• Emulazione di AOP
  • È possibile identificare informazioni aggiuntive, come la firma del metodo che verrà eseguito, tramite il terzo parametro HandlerMethod del metodo preHandle(), e determinare se eseguire la logica.

Filter (Filter) vs. Interceptor (Interceptor)

• I filtri vengono eseguiti nel contesto Web, mentre gli interceptor vengono eseguiti nel contesto Spring, quindi il momento dell'esecuzione è diverso.
• I filtri possono gestire prima e dopo il servlet di dispatch, mentre gli interceptor possono gestire prima e dopo il controller.
• I filtri sono ideali per l'elaborazione di operazioni che devono essere eseguite a livello globale, indipendentemente da Spring, o per la convalida dei parametri di input stessi o per l'utilizzo di ServletRequest invece di HttpServletRequest.
• Gli interceptor sono ideali per l'elaborazione di operazioni che devono essere eseguite a livello globale in base alla richiesta del client che è stata inoltrata all'unità Spring o quando è necessario mescolare la logica del servizio.
• Gli interceptor possono utilizzare @ControllerAdvice e @ExceptionHandler per la gestione delle eccezioni, mentre i filtri non lo possono fare.
  • I filtri generalmente gestiscono le eccezioni che si verificano in quel momento racchiudendo il metodo doFilter() in un blocco try-catch.

Risolvitore di argomenti (Argument Resolver)

Cosa sono i risolutori di argomenti (Argument Resolver)?

I risolutori di argomenti possono indirettamente creare l'oggetto desiderato dai valori ricevuti in una richiesta quando la richiesta viene inoltrata al controller.

Scopo dei risolutori di argomenti (Argument Resolver)

Ad esempio, supponiamo che una richiesta arrivi con un token JWT. Abbiamo bisogno di convalidare se il token è valido e quindi estrarre l'ID archiviato nel token per creare un oggetto utente connesso.

In questo caso, se non utilizziamo un Argument Resolver, dobbiamo implementare il processo di convalida del token e di conversione in un oggetto utente connesso in ogni controller. Ciò comporterà la duplicazione del codice nei controller che richiedono la convalida dell'utente e aumenterà la responsabilità dei controller. Gli Argument Resolver possono risolvere questo problema.

Implementazione dei risolutori di argomenti (Argument Resolver)

Gli Argument Resolver possono essere utilizzati implementando HandlerMethodArgumentResolver. Questa interfaccia specifica che devono essere implementati i seguenti due metodi:

boolean supportsParameter(MethodParameter parameter);

@Nullable

• Metodo supportsParameter
  • Crea e applica una particolare annotazione al parametro per cui desideri che venga eseguito Argument Resolver. Il metodo supportsParameter() verifica se il parametro del metodo richiesto è contrassegnato con l'annotazione desiderata e restituisce true se lo è.
• Metodo resolveArgument
  • Se supportsParameter restituisce true, ovvero se esiste un metodo con una particolare annotazione, questo metodo lega il parametro alla forma desiderata e restituisce le informazioni.

L'implementazione del controller quando si utilizza Argument Resolver è la seguente:

@GetMapping("/me")
public ResponseEntity findMemberOfMine(@AuthenticationPrincipal LoginMember loginMember) {
    MemberResponse memberResponse = memberService.findMember(loginMember.getId());
    return ResponseEntity.ok().body(memberResponse);

Differenza tra i risolutori di argomenti (Argument Resolver) e gli interceptor (Interceptor)

• Gli Argument Resolver vengono eseguiti dopo gli interceptor e restituiscono l'oggetto desiderato dai valori ricevuti nella richiesta quando la richiesta viene inoltrata al controller.
• Al contrario, gli interceptor intercettano la richiesta prima che il controller venga effettivamente eseguito e non possono restituire un oggetto specifico. Esistono solo i tipi di ritorno booleano o void.

Fonti

• https://mangkyu.tistory.com/173
• https://junhyunny.github.io/spring-boot/filter-interceptor-and-aop/
• https://supawer0728.github.io/2018/04/04/spring-filter-interceptor/
• https://tecoble.techcourse.co.kr/post/2021-05-24-spring-interceptor/
• https://baeldung-cn.com/spring-mvc-handlerinterceptor-vs-filter
• https://www.baeldung.com/spring-boot-add-filter

Domande e risposte attese per il colloquio

Cosa sono i filtri?

I filtri consentono di elaborare operazioni aggiuntive per tutte le richieste corrispondenti a un modello di URL prima o dopo che la richiesta venga inoltrata al servlet di dispatch. Funzionano a livello del contenitore del servlet.

Quando vengono utilizzati i filtri?

I filtri possono essere utilizzati per l'elaborazione di operazioni che devono essere eseguite a livello globale, indipendentemente da Spring. Oppure, possono essere utilizzati per la convalida dei parametri di input stessi.

Esempi tipici di attività elaborate dai filtri includono operazioni comuni relative alla sicurezza, la registrazione di tutte le richieste, la compressione di immagini/dati e la codifica delle stringhe e la personalizzazione di ServletRequest.

Cosa sono gli interceptor?

Gli interceptor consentono di fare riferimento o modificare le richieste e le risposte prima o dopo che il servlet di dispatch chiami il controller. In altre parole, a differenza dei filtri, che vengono eseguiti nel contenitore Web, gli interceptor vengono eseguiti nel contesto Spring.

Quando vengono utilizzati gli interceptor?

Gli interceptor possono essere utilizzati per l'elaborazione di operazioni che devono essere eseguite a livello globale in base alla richiesta del client che è stata inoltrata all'unità Spring o quando è necessario mescolare la logica del servizio.

Esempi tipici di attività elaborate dagli interceptor includono operazioni comuni come l'autenticazione e l'autorizzazione, la registrazione delle chiamate API e l'elaborazione dei dati che vengono inoltrati a Controller.

Quali sono le differenze tra i filtri e gli interceptor?

I filtri vengono eseguiti a livello del contenitore del servlet, mentre gli interceptor vengono eseguiti a livello del contenitore Spring.

I filtri possono gestire prima e dopo il servlet di dispatch, mentre gli interceptor possono gestire prima e dopo il controller.

Pertanto, i filtri sono ideali per l'elaborazione di operazioni che devono essere eseguite a livello globale, indipendentemente da Spring, mentre gli interceptor sono ideali per l'elaborazione di operazioni che devono essere eseguite a livello globale in base alla richiesta del client che è stata inoltrata all'unità Spring.

Cosa sono i risolutori di argomenti?

I risolutori di argomenti possono indirettamente creare l'oggetto desiderato dai valori ricevuti in una richiesta quando la richiesta viene inoltrata al controller.

Quando vengono utilizzati i risolutori di argomenti?

Ad esempio, quando una richiesta arriva con un token JWT, puoi utilizzare un Argument Resolver per convalidare se il token è valido ed estrarre l'ID archiviato nel token per creare un oggetto LoginMember.

Quali sono le differenze tra gli interceptor e i risolutori di argomenti?

I risolutori di argomenti restituiscono l'oggetto desiderato dai valori ricevuti nella richiesta quando la richiesta viene inoltrata al controller. Al contrario, gli interceptor non possono restituire un oggetto specifico. Gli interceptor vengono eseguiti prima dei risolutori di argomenti.