Annonce de NGINX Plus R29

Prabhat Dixit

Michael Vernik

Nous sommes heureux d’annoncer la disponibilité de NGINX Plus Release 29 (R29). Basé sur NGINX Open Source, NGINX Plus est la seule solution logicielle tout-en-un faisant office de serveur web, d’équilibreur de charge, de proxy inverse, de cache de contenu et de passerelle API.
Parmi les fonctionnalités nouvelles et améliorées de NGINX Plus R29 figurent :

• Prise en charge du protocole MQTT– Message Queuing Telemetry Transport (MQTT) est un protocole léger utilisé pour la communication entre les appareils de l’Internet des objets (IoT). NGINX Plus R29 prend en charge le protocole MQTT grâce aux modules « Preread » et « Filter », qui introduisent plusieurs nouvelles directives et variables pour faciliter la gestion et la sécurisation du trafic MQTT.
• Prise en charge de SAML pour l’authentification et l’autorisation – Security Assertion Markup Language (SAML) est un protocole éprouvé qui permet l’authentification unique (SSO) aux applications web. NGINX Plus peut désormais être configuré en tant que fournisseur de services (SP) SAML afin d’authentifier les utilisateurs auprès d’un fournisseur d’identité (IdP) SAML.
• OpenTelemetry natif – OpenTelemetry (OTel) est un framework qui génère, collecte et exporte des données de télémétrie (traces, métriques et journaux) à partir de sources distantes, indépendamment des fournisseurs. Le nouveau module dynamique NGINX OTel fournit une implémentation OTel hautes performances pour le traçage des requêtes HTTP de NGINX Plus.
• Packages QUIC+HTTP/3 expérimentaux – Des packages de préversion de NGINX Plus R29 avec QUIC+HTTP/3 sont désormais disponibles. Les packages QUIC de NGINX Plus R29 prennent en charge HttpContext ainsi qu’un ensemble de nouvelles directives permettant de gérer les connexions QUIC et le trafic HTTP/3.

Modifications importantes du comportement

Remarque: si vous effectuez une mise à niveau depuis une version autre que NGINX Plus R28, veillez à consulter la section « Modifications importantes du comportement » dans les précédents billets d’annonce pour toutes les versions comprises entre votre version actuelle et celle-ci.

Modifications apportées au dépôt de paquets

L’ancien dépôt de paquets « plus-pkgs.nginx.com » est mis hors service dès la sortie de NGINX Plus R29. Ce dépôt n’a pas été mis à jour depuis NGINX Plus R25 et il vous est vivement recommandé d’utiliser le dépôt de paquets « pkgs.nginx.com », qui a été introduit dans NGINX Plus R24.

Modifications de la prise en charge des plateformes

Nouveaux systèmes d’exploitation pris en charge :

• Amazon Linux 2023

Anciens systèmes d’exploitation supprimés :

• Alpine 3.13, dont la fin de vie (EOL) a été atteinte le 1er novembre 2022

Anciens systèmes d’exploitation obsolètes et dont la suppression est prévue dans NGINX Plus R30 :

• Ubuntu 18.04, qui arrivera en fin de vie en juin 2023
• Alpine 3.14, dont la fin de vie est prévue en mai 2023

S’adapter à l’annonce de la fin de vie de ModSecurity

Conformément à l’annonce de fin de vie de ModSecurity, NGINX Plus R29 ne prend plus en charge les packages ModSecurity. Si vous êtes client de NGINX Plus et utilisez des packages ModSecurity, vous pourrez bientôt choisir de participer à un programme de reprise entre ModSecurity et NGINX App Protect. De plus amples informations seront bientôt disponibles. Vous pouvez également contacter votre interlocuteur chez F5 pour en savoir plus.

Présentation détaillée des nouvelles fonctionnalités

Prise en charge du protocole MQTT

MQTT (Message Queuing Telemetry Transport) est un protocole de messagerie léger et répandu, basé sur le modèle publication-abonnement. Il est idéal pour connecter des appareils IoT et des applications (clients) via Internet. Il permet aux clients de publier des messages dans une rubrique spécifique et de s’abonner à d’autres rubriques. Les clients abonnés reçoivent tous les messages publiés dans la rubrique concernée, ce qui permet un échange de données efficace et tolérant aux pannes entre de nombreux appareils et services.

Au cœur d’une architecture MQTT se trouve un broker. Un broker est un serveur chargé de suivre les clients et les rubriques auxquelles ils sont abonnés, de traiter les messages et de les acheminer vers les systèmes appropriés. NGINX Plus R29 prend en charge MQTT 3.1.1 et MQTT 5.0. Il fait office de proxy entre les clients et les brokers, ce qui simplifie l’architecture du système, décharge certaines tâches et réduit les coûts.

L’ensemble initial de fonctionnalités MQTT permet :

• Répartition de charge des brokers MQTT
• Persistance de session (reconnexion des clients au même broker)
• Terminaison TLS
• Authentification par certificat client
• Analyse et réécriture des messages CONNECT

Le protocole MQTT définit plusieurs types de messages, notamment CONNECT, PUBLISH et SUBSCRIBE. NGINX Plus R29 peut analyser et réécrire activement certaines parties des messages MQTT CONNECT, ce qui permet de mettre en œuvre des scénarios de configuration auparavant uniquement possibles avec des scripts personnalisés.

L’analyse et la réécriture des messages MQTT doivent être définies dans le contexte Stream d’un fichier de configuration NGINX et sont rendues possibles par les modules ngx_stream_mqtt_preread_module
et ngx_stream_mqtt_filter_module.

Exemples MQTT

La modification de l’identifiant client par défaut envoyé par un appareil MQTT permet à NGINX de masquer des informations sensibles, telles que le numéro de série de l’appareil. Dans ce premier exemple, l’identifiant est remplacé par l’adresse IP de l’appareil.

Remarque : Il est déconseillé d’utiliser l’adresse IP d’un appareil comme identifiant client MQTT dans un environnement de production.

stream {      mqtt on;
      server {
          listen 1883;
          proxy_pass 10.0.0.8:1883;
          mqtt_set_connect clientid '$remote_addr';
      }
  }

Compte tenu de la nature éphémère des clients MQTT, vous ne pouvez pas vous fier uniquement au nom d’hôte ou à l’adresse IP d’un appareil pour établir des sessions persistantes avec des brokers répartis par équilibrage de charge. Dans cet exemple, l’identifiant du client MQTT d’un appareil sert de clé de hachage afin de maintenir les connexions avec des brokers MQTT individuels au sein d’un cluster à charge équilibrée :

stream {      mqtt_preread on;
      upstream brokers{
          zone tcp_mem 64k;
          hash $mqtt_preread_clientid consistent;
          server 10.0.0.7:1883; # mqtt broker 1
          server 10.0.0.8:1883; # mqtt broker 2
          server 10.0.0.9:1883; # mqtt broker 3
      }
      server {
          listen 1883;
          proxy_pass brokers;
          proxy_connect_timeout 1s;
      }
  }

Prochaines étapes

Les futures évolutions de MQTT dans NGINX Plus pourraient inclure l’analyse d’autres types de messages MQTT, ainsi qu’une analyse plus approfondie du message CONNECT afin de permettre des fonctionnalités telles que :

• Mécanismes supplémentaires d’authentification et de contrôle d’accès
• Protéger les brokers en limitant le débit des clients « bavards »
• Télémétrie des messages et métriques de connexion

Nous aimerions beaucoup connaître votre avis sur les fonctionnalités qui comptent le plus pour vous. Dites-nous ce que vous en pensez dans les commentaires.

Prise en charge de SAML pour l’authentification et l’autorisation

SAML (Security Assertion Markup Language) est une norme ouverte de fédération qui permet à un fournisseur d’identité (IdP) d’authentifier les utilisateurs souhaitant accéder à une ressource (afin de s’assurer que l’utilisateur final est bien la personne qu’il prétend être) et de transmettre ces informations d’authentification, ainsi que les droits d’accès de l’utilisateur à cette ressource, à un fournisseur de services (SP) à des fins d’autorisation.

Fort de sa longue expérience en matière d’échange sécurisé de données d’identité, SAML est un protocole largement adopté pour échanger des informations d’authentification et d’autorisation entre un fournisseur d’identité (IdP) et un fournisseur de services (SP).

Parmi les principales raisons pour lesquelles les entreprises et les institutions gouvernementales choisissent d’adopter SAML figurent les suivantes :

• Gestion efficace d’un grand nombre d’identités
• Une sécurité des identités renforcée, cohérente et unifiée pour les clients et les employés
• Amélioration de l’efficacité opérationnelle grâce à la standardisation des processus de gestion des identités
• Gestion efficace de la conformité réglementaire

SAML offre également plusieurs avantages :

• Meilleure expérience utilisateur: grâce à son intégration de l’authentification unique (SSO) et à la centralisation de la vérification de l’authentification au niveau du fournisseur d’identité (IdP), SAML permet aux utilisateurs de s’authentifier une seule fois pour accéder à tous les services connectés. Cela améliore l’expérience utilisateur et fait gagner du temps, car les utilisateurs n’ont plus besoin de mémoriser plusieurs identifiants pour différentes applications.
• Sécurité renforcée: selon les politiques de sécurité et d’authentification de votre organisation, les utilisateurs peuvent se connecter à l’aide d’un mécanisme d’authentification SSO, soit depuis l’interface du SP (SSO initié par le SP), soit directement depuis l’interface de l’IdP (SSO initié par l’IdP). Cela réduit les risques de sécurité liés à l’utilisation de mots de passe potentiellement faibles et/ou réutilisés.
• Réduction des coûts administratifs: SAML permet aux organisations de confier les responsabilités liées à la gestion des identités à un IdP de confiance, réduisant ainsi les coûts de gestion des informations de compte et les dépenses associées.
• Protocole standardisé: Conçu selon le principe visant à rendre la sécurité indépendante de la logique applicative (autant que possible), SAML est un protocole standardisé pris en charge par la quasi-totalité des fournisseurs d’identité (IdP) et des systèmes de gestion des accès. Il dissocie le cadre de sécurité des architectures de plateforme et des implémentations propres à chaque fournisseur, ce qui garantit une sécurité robuste et une intégration fiable entre les systèmes.

L’implémentation de référence actuelle de SAML utilise SAML 2.0 et repose sur le framework NGINX JavaScript (njs). Dans cette implémentation, NGINX Plus fait office de fournisseur de services (SP) SAML, ce qui lui permet de participer à une configuration d’authentification unique (SSO) avec un fournisseur d’identité (IdP) SAML. L’implémentation actuelle dépend également du magasin clé-valeur, une fonctionnalité existante de NGINX Plus qui, à ce titre, ne convient pas à NGINX Open Source sans modifications supplémentaires.

La prise en charge de SAML dans NGINX Plus est disponible sous la forme d’une implémentation de référence sur GitHub. Le dépôt GitHub comprend un exemple de configuration accompagné d’instructions pour l’installation, la configuration et l’ajustement précis en fonction de cas d’utilisation spécifiques.

OpenTelemetry natif

OpenTelemetry (OTel) est une technologie et une norme qui peuvent être utilisées pour surveiller, tracer, dépanner et optimiser les applications. OTel fonctionne en collectant des données de télémétrie provenant de diverses sources, telles que des proxys, des applications ou d’autres services au sein d’une pile applicative déployée.

En tant que proxy inverse et équilibreur de charge prenant en charge les protocoles, NGINX est idéalement placé pour lancer des appels de télémétrie afin de tracer les requêtes et les réponses des applications. Bien que des modules OTel tiers soient disponibles depuis un certain temps, nous sommes ravis d’annoncer la prise en charge native d’OTel dans NGINX Plus grâce à un nouveau module dynamique.

Le nouveau module ngx_otel_module peut être installé à l’aide du paquet nginx-plus-module-otel et apporte plusieurs améliorations majeures par rapport aux modules tiers, notamment :

• Meilleures performances – La plupart des implémentations d’OTel réduisent jusqu’à 50 % les performances de traitement des requêtes lorsque le traçage est activé. Notre nouveau module natif limite cet impact à environ 10 à 15 %.
• Déploiement facile – La collecte des données de télémétrie peut être installée et configurée directement dans les fichiers de configuration NGINX.
• Échantillonnage entièrement dynamique basé sur des variables – La possibilité de tracer une session particulière à l’aide d’un cookie/jeton et de contrôler dynamiquement le module via l’API NGINX Plus et les modules de stockage clé-valeur.

Vous trouverez plus d’informations sur le module dynamique OTel dans la documentation NGINX.

Exemples de traçage OTel

Voici un exemple de traçage OTel de base d’une application servie directement par NGINX :

load_module modules/ngx_otel_module.so;  events {}
  http {
      otel_exporter {
          endpoint localhost:4317;
      }
   
      server {
          listen 127.0.0.1:8080;
          
          otel_trace on;
          otel_span_name app1;
      }
  }

Dans l’exemple suivant, nous héritons des contextes de traçage des requêtes entrantes et n’enregistrons les segments que si un segment parent est échantillonné. Nous transmettons également les contextes de traçage et les décisions d’échantillonnage aux serveurs en amont.

load_module modules/ngx_otel_module.so;  http {
      server {
          location / {
              otel_trace $otel_parent_sampled;
              otel_trace_context propagate;
              proxy_pass http://backend;
          }
      }
  }

Dans cet exemple basé sur un ratio, le traçage est configuré pour un certain pourcentage du trafic (ici, 10 %) :

http {      # trace 10% of requests
      split_clients "$otel_trace_id" $ratio_sampler {
          10%     on;
          *       off;
      }
      # or we can trace 10% of user sessions
      split_clients "$cookie_sessionid" $session_sampler {
          10%     on;
          *       off;
      }
      server {
          location / {
              otel_trace $ratio_sampler;
              otel_trace_context inject;
              proxy_pass http://backend;
          }
      }
  }

Dans cet exemple contrôlé par l’API, le traçage est activé en manipulant le magasin clé-valeur via le point de terminaison /api :

http {      keyval "otel.trace" $trace_switch zone=name;
      server {
          location / {
              otel_trace $trace_switch;
              otel_trace_context inject;
              proxy_pass http://backend;
          }
          location /api {
              api write=on;
          } 
      }
  }

Paquets expérimentaux QUIC+HTTP/3

À la suite de notre annonce concernant les paquets binaires en préversion pour NGINX Open Source, nous avons le plaisir d’annoncer la disponibilité de paquets QUIC expérimentaux pour NGINX Plus R29. Il est ainsi possible de tester et d’évaluer HTTP/3 avec NGINX Plus.

Grâce à une nouvelle pile de protocoles sous-jacente, HTTP/3 introduit UDP et QUIC dans la couche de transport. QUIC est un protocole de transport chiffré conçu pour améliorer TCP en permettant le multiplexage des connexions et en résolvant des problèmes tels que le blocage en tête de ligne. Il réimplémente et améliore plusieurs fonctionnalités de TCP utilisées par HTTP/1.1 et HTTP/2, notamment l’établissement des connexions, le contrôle de congestion et la fiabilité de la transmission. QUIC intègre également TLS en tant que composant à part entière, contrairement à HTTP/1.1 et HTTP/2, pour lesquels TLS constitue une couche distincte. Les messages HTTP/3 sont donc intrinsèquement sécurisés, car ils sont transmis par défaut via une connexion chiffrée.

En règle générale, pour assurer la sécurité des communications et les fonctions cryptographiques, NGINX Plus s’appuie sur OpenSSL, en utilisant les bibliothèques SSL/TLS fournies avec les systèmes d’exploitation. Toutefois, à l’heure où nous écrivons ces lignes, les interfaces TLS de QUIC ne sont pas prises en charge par OpenSSL. Des bibliothèques tierces sont donc nécessaires pour fournir les fonctions TLS manquantes requises par HTTP/3.

Pour répondre à cette problématique, nous avons développé une couche de compatibilité OpenSSL pour QUIC, éliminant ainsi la nécessité de compiler et de distribuer des bibliothèques TLS tierces telles que quictls, BoringSSL et LibreSSL. Cela permet de gérer l’expérience QUIC+HTTP/3 de bout en bout dans NGINX, sans la contrainte d’une implémentation TLS personnalisée ni la dépendance vis-à-vis des calendriers et feuilles de route de bibliothèques tierces.

Remarque: la couche de compatibilité OpenSSL est incluse dans les paquets expérimentaux NGINX Plus QUIC+HTTP/3 et nécessite OpenSSL 1.1.1 ou une version ultérieure pour fournir TLSv1.3 (requis par le protocole QUIC). Elle ne prend pas encore en charge le 0-RTT.

Exemple de configuration QUIC+HTTP/3

Examinons un exemple de configuration de QUIC+HTTP/3 dans NGINX Plus :

http {      log_format quic '$remote_addr - $remote_user [$time_local]'
      '"$request" $status $body_bytes_sent '
      '"$http_referer" "$http_user_agent" "$http3"';
      access_log logs/access.log quic;
      server {
          # for better compatibility it's recommended
          # to use the same port for quic and https
          listen 8443 quic reuseport;
          listen 8443 ssl;
          ssl_certificate     certs/example.com.crt;
          ssl_certificate_key certs/example.com.key;
          location / {
              # required for browsers to direct them into quic port
              add_header Alt-Svc 'h3=":8443"; ma=86400';
          }
      }
  }

Comme pour notre implémentation de HTTP/2, lorsque NGINX Plus agit comme proxy, les connexions QUIC+HTTP/3 sont établies côté client et converties en HTTP/1.1 lors de la connexion aux services backend et en amont.

Les packages expérimentaux QUIC+HTTP/3 de NGINX Plus sont disponibles dans un dépôt distinct, accessible à l’aide des certificats et clés NGINX Plus existants. L’installation des packages QUIC expérimentaux est similaire à une installation de NGINX Plus standard. Veillez à utiliser le dépôt QUIC, comme indiqué dans les étapes d’installation.

Vous pouvez consulter Configuration de NGINX pour QUIC+HTTP/3 pour en savoir plus sur la configuration de NGINX pour QUIC+HTTP/3. Pour plus d’informations sur l’ensemble des nouvelles directives et variables, consultez la section Configuration du README de nginx-quic.

Étapes suivantes

Dans un avenir proche, nous prévoyons d’intégrer le code QUIC+HTTP/3 à la branche principale de NGINX. La dernière version de la branche principale de NGINX prenant en charge QUIC+HTTP/3 sera ensuite intégrée à une prochaine version de NGINX Plus. Une annonce concernant la disponibilité officielle de la prise en charge de QUIC+HTTP/3 dans NGINX Plus est prévue plus tard cette année.

Autres améliorations de NGINX Plus R29

Modifications apportées à OpenID Connect

La prise en charge d’OpenID Connect (OIDC) a été introduite dans NGINX Plus R15, puis considérablement améliorée dans les versions suivantes. NGINX Plus R29 continue d’enrichir la prise en charge d’OIDC avec les ajouts suivants.

Prise en charge des jetons d’accès

Les jetons d’accès sont utilisés dans l’authentification basée sur des jetons pour permettre à un client OIDC d’accéder à une ressource protégée au nom de l’utilisateur. NGINX Plus reçoit un jeton d’accès une fois que l’utilisateur s’est authentifié et a autorisé l’accès, puis le stocke dans le magasin clé-valeur. NGINX Plus peut transmettre ce jeton dans l’en-tête HTTP Authorization sous la forme d’un jeton Bearer pour chaque requête envoyée à l’application en aval.

Remarque: NGINX Plus ne vérifie pas la validité du jeton d’accès à chaque requête (contrairement au jeton d’ID) et ne peut donc pas savoir si le jeton d’accès a déjà expiré. Si la durée de vie du jeton d’accès est inférieure à celle du jeton d’ID, vous devez activer la directive « proxy_intercept_errors ». Celle-ci intercepte et redirige vers NGINX les réponses « 401 Unauthorized » afin d’actualiser le jeton d’accès.

Pour plus d’informations sur OpenID Connect et la validation des jetons Web JSON (JWT) avec NGINX Plus, consultez Authentification des utilisateurs auprès d’applications existantes avec OpenID Connect et NGINX Plus.

Arguments ajoutés au point de terminaison d’authentification OIDC

Certains fournisseurs d’identité, comme Keycloak, permettent d’ajouter des paramètres supplémentaires à la chaîne de requête de la demande d’authentification afin d’activer des fonctionnalités supplémentaires. Par exemple, Keycloak permet de spécifier un fournisseur d’identité par défaut en ajoutant un paramètre kc_idp_hint à la demande d’authentification. Dans le cadre de cette amélioration, l’utilisateur peut spécifier des paramètres supplémentaires pour le point de terminaison d’autorisation OIDC.

Compteurs SSL étendus dans le module Prometheus-njs

Dans NGINX Plus R28, nous avons ajouté la prise en charge de compteurs SSL supplémentaires pour les erreurs de négociation et les échecs de validation des certificats dans les modules HTTP et Stream, pour les connexions côté client comme côté serveur. Notre module Prometheus-njs, qui convertit les métriques NGINX Plus dans un format compatible avec Prometheus, prend désormais en charge ces compteurs.

Nouvelle directive « internal_redirect »

La nouvelle directive internal_redirect et le module associé permettent d’effectuer des redirections internes après vérification des limites de traitement des requêtes, des limites de traitement des connexions et des limites d’accès.

Voici un exemple de configuration de « internal_redirect » :

http {      limit_req_zone $jwt_claim_sub zone=jwt_sub:10m rate=1r/s; 
       server {
          location / {
              auth_jwt "realm";
              auth_jwt_key_file key.jwk;
               internal_redirect @rate_limited;
          }
           location @rate_limited {
              internal;
              limit_req zone=jwt_sub burst=10;
              proxy_pass http://backend;
          }
      }
  }

Dans l’exemple ci-dessus, l’authentification JWT est effectuée dans le bloc location et, si le jeton est valide, la requête est transmise au gestionnaire de contenu interne @rate_limited, où une limite de débit des requêtes est appliquée en fonction de la valeur de la revendication sub. Cette opération s’effectue dans le JWT avant que la requête ne soit transmise au service en amont.

Cette configuration particulière empêche une attaque par déni de service (DoS) dans laquelle un attaquant envoie un grand nombre de requêtes contenant des JWT lisibles, encodés avec un utilisateur donné dans le champ sub. Ces requêtes n’aboutiraient pas à une authentification, mais seraient tout de même comptabilisées dans la limite de débit. En authentifiant le JWT avant de transmettre la requête au gestionnaire de contenu, vous vous assurez que seules les requêtes valides sont prises en compte dans la limite de débit.

Modifications héritées de NGINX Open Source

NGINX Plus R29 est basé sur NGINX Open Source 1.23.4 et bénéficie des évolutions fonctionnelles et des corrections de bogues apportées depuis la sortie de NGINX Plus R28 (de NGINX 1.23.3 à 1.23.4).

Modifications

• Le protocole « TLSv1.3 » est désormais activé par défaut et constitue la valeur par défaut des directives suivantes :
• ssl_protocols (HTTP, Flux, Courrier)
• proxy_ssl_protocols (HTTP, Stream)
• grpc_ssl_protocols
• uwsgi_ssl_protocols
• zone_sync_ssl_protocols
• NGINX émet désormais un avertissement si les paramètres de protocole d’un socket d’écoute sont redéfinis.
• NGINX ferme désormais les connexions de manière différée si le client a utilisé le pipelining.
• Le niveau de journalisation des erreurs SSL data length too long, length too short, bad legacy version, no shared signature algorithms, bad digest length, missing sigalgs extension, encrypted length too long, bad length, bad key update, mixed handshake and non-handshake data, ccs received early, data between ccs and finished, packet length too long, too many warn alerts, record too small et got a fin before a ccs a été abaissé de crit à info.

Fonctionnalités

• Les plages d’octets sont désormais prises en charge dans le module « ngx_http_gzip_static_module ».

Corrections de bugs

• Correction des plages de ports qui ne fonctionnaient pas dans la directive listen.
• Correction d’un problème pouvant entraîner la sélection d’un emplacement incorrect pour traiter une requête lorsqu’un emplacement de préfixe de plus de 255 caractères était utilisé dans la configuration.
• Correction de la prise en charge des caractères non-ASCII dans les noms de fichiers sous Windows, qui n’étaient pas reconnus par ngx_http_autoindex_module, ngx_http_dav_module et la directive include.
• Correction d’une fuite de socket qui se produisait parfois lors de l’utilisation de HTTP/2 et de la directive error_page pour rediriger les erreurs portant le code 400.
• Correction des messages relatifs aux erreurs de journalisation dans syslog, qui n’indiquaient pas que les erreurs s’étaient produites lors de la journalisation dans syslog.
• Correction de la gestion des événements de lecture bloqués côté client dans proxy -r.
• Correction d’une erreur qui se produisait parfois lors de la lecture de l’en-tête de la version 2 du protocole PROXY contenant un grand nombre de TLV.
• Correction d’une erreur de segmentation qui se produisait parfois dans un processus de travail lorsque SSI était utilisé pour traiter des sous-requêtes créées par d’autres modules.
• Correction d’un problème susceptible d’entraîner une utilisation excessive du processeur par NGINX lors d’un proxy sans mise en mémoire tampon si des connexions SSL aux serveurs backend étaient utilisées.

Solutions de contournement

• échec du filtre zip lors de l’utilisation de la mémoire préallouée : des alertes apparaissaient dans les journaux lors de l’utilisation de zlib-ng.
• Lorsqu’un nom d’hôte utilisé dans la directive « listen » est résolu en plusieurs adresses, NGINX ignore désormais les doublons parmi celles-ci.

Pour obtenir la liste complète des nouvelles fonctionnalités, modifications, corrections de bogues et solutions de contournement héritées de ces versions, consultez le fichier « CHANGES ».

Modifications apportées au module JavaScript NGINX

NGINX Plus R29 intègre les modifications apportées au module JavaScript NGINX (njs) des versions 0.7.9 à 0.7.12. Plusieurs fonctionnalités intéressantes ont été ajoutées à njs, notamment :

• Prise en charge étendue de l’API Fetch
• API Web Crypto étendue
• Prise en charge des documents XML
• Analyse de documents XML
• API XMLNode pour modifier des documents XML
• Prise en charge de la compression avec le module Zlib

Pour obtenir la liste complète des fonctionnalités, modifications et corrections de bugs apportées entre les versions 0.7.9 et 0.7.12 de njs, consultez le journal des modifications de njs.

Prise en charge étendue de l’API Fetch

Headers(), Request(), et Response() sont ajoutés à l’API Fetch, ainsi que d’autres améliorations :

async function makeRequest(uri, headers) {      let h = new Headers(headers);
      h.delete("bar");
      h.append("foo", "xxx");
      let r = new Request(uri, {headers: h});
      return await ngx.fetch(r);
  }

API Web Crypto étendue

L’API Web Crypto a été étendue pour prendre en charge le format JSON Web Key (JWK), et importKey() accepte désormais en entrée des clés au format JWK :

async function importSigningJWK(jwk) {     return await crypto.subtle.importKey('jwk', jwk,
                                          {name: "RSASSA-PKCS1-v1_5"},
                                          true, ['sign']);
  }

njs 0.7.10 a également ajouté les méthodes « generateKey() » et « exportKey() ». La méthode « generateKey() » permet de générer une nouvelle clé pour les algorithmes symétriques ou une paire de clés pour les algorithmes à clé publique. La méthode « exportKey() » prend en entrée un objet « CryptoKey » et renvoie la clé dans un format externe et portable. Elle prend en charge le format JWK pour exporter la clé sous forme d’objet JSON.

Pour plus de détails, consultez l’API Web Crypto.

Prise en charge des documents XML

Le module XML a été ajouté dans njs 0.7.10 afin de fournir une prise en charge native de la manipulation des documents XML.

Analyse de documents XML

Vous pouvez désormais analyser une chaîne ou un tampon contenant un document XML, ce qui renvoie ensuite un objet wrapper XMLDoc représentant le document XML analysé :

const xml = require("xml");  let data = `<note><to b="bar" a= "foo">Tove</to><from>Jani</from></note>`;
  let doc = xml.parse(data);
   
  console.log(doc.note.to.$text) /* 'Tove' */
  console.log(doc.note.to.$attr$b) /* 'bar' */
  console.log(doc.note.$tags[1].$text) /* 'Jani' */

API XMLNode pour modifier des documents XML

L’API XMLNode a été ajoutée dans njs 0.7.11 pour permettre de modifier des documents XML :

Const xml = require("xml");  let data = `<note><to b="bar" a="foo">Tove</to><from>Jani</from></note>`;
  let doc = xml.parse(data);
   
  doc.$root.to.$attr$b = 'bar2';
  doc.$root.to.setAttribute('c', 'baz');
  delete doc.$root.to.$attr$a;
   
  console.log(xml.serializeToString(doc.$root.to))
  /* '<to b="bar2" c="baz">Tove</to>' */
   
  doc.$root.to.removeAllAttributes();
  doc.$root.from.$text = 'Jani2';
   
  console.log(xml.serializeToString(doc))
  /* '<note><to>Tove</to><from>Jani2</from></note>' */
   
  doc.$root.to.$tags = [xml.parse(`<a/>`), xml.parse(`<b/>`)];
  doc.$root.to.addChild(xml.parse(`<a/>`));
  console.log(xml.serializeToString(doc.$root.to))
  /* '<to><a></a><b></b><a></a></to>' */
   
  doc.$root.to.removeChildren('a');
   
  console.log(xml.serializeToString(doc.$root.to))
  /* '<to><b></b></to>' */

Pour plus de détails sur toutes les améliorations liées à XML, consultez la documentation XML.

Prise en charge de la compression par le module Zlib

Le module zlib a été ajouté dans njs 0.7.12 et fournit des fonctionnalités de compression à l’aide des algorithmes deflate et inflate.

Const zlib = require('zlib');  zlib.deflateRawSync('αβγ').toString('base64')
  /* "O7fx3KzzmwE=" */
   
  zlib.inflateRawSync(Buffer.from('O7fx3KzzmwE=', 'base64')).toString()
  /* "αβγ" */

Pour plus de détails sur zlib, consultez la documentation de zlib.

Mettez à niveau ou essayez NGINX Plus

Si vous utilisez NGINX Plus, nous vous recommandons vivement de passer à NGINX Plus R29 dès que possible. Outre toutes les nouvelles fonctionnalités remarquables, vous bénéficierez également de plusieurs correctifs et améliorations supplémentaires. En restant à jour, vous permettrez à NGINX de mieux vous aider si vous devez ouvrir un ticket auprès du support.

Si vous n’avez pas encore essayé NGINX Plus, nous vous invitons à le découvrir, que ce soit pour la sécurité, l’équilibrage de charge et la passerelle d’API, ou comme serveur web entièrement pris en charge, doté d’API avancées de surveillance et de gestion. Commencez dès aujourd’hui avec un essai gratuit de 30 jours.

À propos des auteurs

Prabhat Dixit

Autres articles de Prabhat Dixit

Michael Vernik

Autres articles de Michael Vernik