CodeGym/Java Course/Modulo 3/Filtri del server web

Filtri del server web

Disponibile

Introduzione ai filtri

Ma non è tutto. Davvero non pensi che i servlet siano così semplici, vero?

Oltre ai servlet che abbiamo già analizzato, esistono anche i cosiddetti "servlet di utilità" - filtri . Sono molto simili ai servlet, ma il loro compito principale è aiutare i servlet a elaborare le richieste.

Un filtro è come un segretario e un servlet è come un regista. Prima che il documento raggiunga la scrivania del direttore, passerà per le mani del segretario. E dopo che il direttore lo firma, andrà di nuovo alla segretaria, già come corrispondenza in uscita, per esempio.

Tale segretaria può rifiutare alcune delle richieste al direttore (ad esempio, spam). Oppure dai risposte standard a domande a lui note ("il regista non è a posto"). E così via. Inoltre, possono esserci diverse segretarie di questo tipo: una può filtrare lo spam per tutti i direttori contemporaneamente, l'altra può trasferire richieste tra diversi direttori e simili.

I filtri funzionano allo stesso modo.

servlet di utilità"

Classi Filter, FilterChain, FilterConfig

I filtri sono molto simili ai servlet, ma con un paio di piccole differenze. Per scrivere il tuo filtro, devi ereditare dal file javax.servlet.Filter.

Il filtro ha anche metodi init()e destroy(). Invece di un metodo, service()un filtro ha un'estensione doFilter(). E ha anche la sua classe FilterConfig. Il filtro viene inoltre aggiunto al servlet nel file web.xml o tramite l'annotazione @WebFilter.

Elenco dei metodi:

Metodi Descrizione
1 init(FilterConfig config) inizializzazione del filtro
2 destroy() scarico del filtro
3 doFilter(ServletRequest , ServletResponse, FilterChain) elaborazione della richiesta (filtraggio)

Qual è la differenza tra un servlet e un filtro?

Possono essere presenti diversi filtri ed elaborano in sequenza la richiesta (e la risposta). Sono combinati in una cosiddetta catena - e c'è anche una classe speciale per loro FilterChain.

Dopo aver elaborato la richiesta nel metodo, doFilter()è necessario chiamare il metodo doFilter()del filtro successivo nella catena. Esempio:

public class MyFilter implements Filter {

  public void init(FilterConfig arg0) throws ServletException {
  }

  public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws Exception {

      PrintWriter out = resp.getWriter();
      out.print("Adding something before the body of the response");

      chain.doFilter(req, resp); // call the next filter in the chain

      out.print("Adding something after the body of the response");
    }

  public void destroy() {
  }
}

In realtà, non puoi aggiungere il corpo della risposta in questo modo . Formalmente, filtri e servlet sono indipendenti l'uno dall'altro e possono essere modificati indipendentemente. Possono essere scritti da diversi sviluppatori in momenti diversi. La funzione filtro è solo una funzione di servizio, ad esempio:

  • Registrazione di tutte le richieste in arrivo (e risposte)
  • Compressione dati
  • Crittografia (e decrittografia) dei dati
  • Richiedi la convalida dei dati
  • Aggiungi/rimuovi le intestazioni desiderate
  • Richieste di reindirizzamento
  • Controllo degli accessi (verificare se l'utente ha effettuato l'accesso)

Classe RequestDispatcher

doFilter() A volte può essere necessario chiamare un altro servlet mentre un filtro è in esecuzione all'interno di un metodo . Per fare questo, il contenitore ha un oggetto speciale RequestDispatcher.

Puoi ottenerlo in due modi:

  • All'oggettoHttpServletRequest
  • All'oggettoServletContext

Questo oggetto può essere utilizzato per reindirizzare una richiesta esistente a un altro servlet . Ad esempio, si è scoperto che l'utente non è autorizzato e vogliamo mostrargli una pagina con l'autorizzazione. Bene, o c'è stato un errore sul server e vogliamo mostrare una pagina di errore all'utente :)

public class HelloServlet extends HttpServlet {
    protected void doGet(HttpServletRequest request, HttpServletResponse response)  throws Exception {
           String path = "/error.html";
           ServletContext servletContext = this.getServletContext();
           RequestDispatcher requestDispatcher = servletContext.getRequestDispatcher(path);
           requestDispatcher.forward(request, response);
    }
}

Puoi anche chiamare RequestDispatcherda un filtro.

public class MyFilter implements Filter {

  public void init(FilterConfig arg0) throws ServletException {
  }

  public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws Exception {
           String path = "/error.html";
           ServletContext servletContext = req.getServletContext();
           RequestDispatcher requestDispatcher = servletContext.getRequestDispatcher(path);
           requestDispatcher.forward(req, resp);
    }

  public void destroy() {
  }
}

Si noti che la richiesta verrà gestita nel metodo forward()e non è necessario chiamare doFilter()dopo l'uso RequestDispatcher.

Confronto tra redirect e forward

E un altro punto importante. Se desideri reindirizzare l'utente a un altro URI nel tuo servlet, puoi farlo in due modi:

  • redirect
  • forward

Li abbiamo già analizzati, ma per comodità lo ripeto.

Quando si reindirizza tramite una chiamata response.sendRedirect("link"), il server invia al browser (client) una risposta 302e il collegamento specificato. E il browser, dopo aver analizzato la risposta del server, scarica il collegamento che hai passato. Cioè, il collegamento nel browser cambia in uno nuovo.

Se inoltri tramite a call requestDispatcher.forward(), viene effettuata una nuova richiesta all'interno del contenitore e il tuo servlet invia la sua risposta al browser (client) come risposta del tuo servlet. In questo caso, il browser riceve una risposta dal nuovo servlet, ma il collegamento nel browser non cambia.

Commenti
  • Popolari
  • Nuovi
  • Vecchi
Devi avere effettuato l'accesso per lasciare un commento
Questa pagina non ha ancora commenti