Filtres de serveur Web

Présentation des filtres

Mais ce n'est pas tout. Vous ne pensez vraiment pas que les servlets soient si simples, n'est-ce pas ?

En plus des servlets que nous avons déjà analysés, il existe également des filtres dits « servlets utilitaires » . Ils sont très similaires aux servlets, mais leur tâche principale est d'aider les servlets à traiter les requêtes.

Un filtre est comme une secrétaire et une servlet est comme un directeur. Avant que le document n'atteigne le bureau du directeur, il passera entre les mains du secrétaire. Et après que le directeur l'aura signé, il ira à nouveau au secrétaire, déjà sous forme de correspondance sortante, par exemple.

Une telle secrétaire peut rejeter certaines des demandes adressées au directeur (par exemple, les spams). Ou donner des réponses types à des questions connues de lui ("le réalisateur n'est pas en place"). Et ainsi de suite. De plus, il peut y avoir plusieurs secrétaires de ce type : l'une peut filtrer les spams pour tous les administrateurs à la fois, l'autre peut transférer les demandes entre différents administrateurs, etc.

Les filtres fonctionnent de la même manière.

Classes Filtre, FilterChain, FilterConfig

Les filtres sont très similaires aux servlets, mais avec quelques petites différences. Pour écrire votre propre filtre, vous devez hériter du javax.servlet.Filter.

Le filtre a également des méthodes init()et destroy(). Au lieu d'une méthode, service()un filtre a un doFilter(). Et a même sa propre classe FilterConfig. Le filtre est également ajouté au servlet dans le fichier web.xml ou via l'annotation @WebFilter.

Liste des méthodes :

Quelle est la différence entre une servlet et un filtre ?

Il peut y avoir plusieurs filtres, et ils traitent séquentiellement la demande (et la réponse). Ils sont combinés dans une soi-disant chaîne - et il existe même une classe spéciale pour eux FilterChain.

Après avoir traité la requête dans la méthode, doFilter()vous devez appeler la méthode doFilter()du filtre suivant dans la chaîne. Exemple:

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() {
  }
}

En fait, vous ne pouvez pas ajouter le corps de la réponse comme ça . Formellement, les filtres et les servlets sont indépendants les uns des autres et peuvent être modifiés indépendamment. Ils peuvent être écrits par différents développeurs à différents moments. La fonction de filtrage n'est qu'une fonction de service, par exemple :

• Enregistrement de toutes les demandes entrantes (et réponses)
• Compression des données
• Chiffrement (et déchiffrement) des données
• Demander la validation des données
• Ajouter/supprimer les en-têtes souhaités
• Rediriger les demandes
• Contrôle d'accès (vérifier si l'utilisateur est connecté)

Classe RequestDispatcherRequestDispatcher class

doFilter() Parfois, il peut être nécessaire d'appeler un autre servlet pendant qu'un filtre s'exécute dans une méthode . Pour ce faire, le conteneur a un objet spécial RequestDispatcher.

Vous pouvez l'obtenir de deux manières :

• A l'objetHttpServletRequest
• A l'objetServletContext

Cet objet peut être utilisé pour rediriger une requête existante vers une autre servlet . Par exemple, il s'est avéré que l'utilisateur n'est pas autorisé et nous voulons lui montrer une page avec autorisation. Bon, ou il y a eu une erreur sur le serveur et on veut afficher une page d'erreur à l'utilisateur :)

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);
    }
}

Vous pouvez également appeler RequestDispatcherà partir d'un filtre.

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() {
  }
}

Notez que la requête sera traitée dans la méthode forward()et qu'il n'est pas nécessaire d'appeler doFilter()après utilisation RequestDispatcher.

Comparaison de la redirection et du transfert

Et encore un point important. Si vous souhaitez rediriger l'utilisateur vers un autre URI dans votre servlet, vous pouvez le faire de deux manières :

• redirect
• forward

Nous les avons déjà analysés, mais pour plus de commodité, je le répète.

Lorsque vous redirigez via un appel response.sendRedirect("link"), le serveur renvoie au navigateur (client) une réponse 302et le lien que vous avez spécifié. Et le navigateur, après avoir analysé la réponse du serveur, télécharge le lien que vous avez passé. C'est-à-dire que le lien dans le navigateur est remplacé par un nouveau.

Si vous transférez via un call requestDispatcher.forward(), une nouvelle requête est effectuée à l'intérieur du conteneur et votre servlet envoie sa réponse au navigateur (client) en tant que réponse de votre servlet. Dans ce cas, le navigateur reçoit une réponse de la nouvelle servlet, mais le lien dans le navigateur ne change pas.