Annonce de NGINX Plus R29

Nous sommes heureux d’annoncer la disponibilité de NGINX Plus Release 29 (R29). Basé sur NGINX Open Source, NGINX Plus est le seul serveur Web logiciel tout-en-un, équilibreur de charge, proxy inverse, cache de contenu et passerelle API.
Les fonctionnalités nouvelles et améliorées de NGINX Plus R29 incluent :

• 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 avec des modules de prélecture et de filtrage qui introduisent plusieurs nouvelles directives et variables pour aider à gérer et sécuriser le trafic MQTT.

• Prise en charge SAML pour l’authentification et l’autorisation – Security Assertion Markup Language (SAML) est un protocole bien établi qui fournit une authentification unique (SSO) aux applications Web. NGINX Plus peut désormais être configuré en tant que fournisseur de services SAML (SP) pour authentifier les utilisateurs auprès d'un fournisseur d'identité SAML (IdP).

• Native OpenTelemetry – 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 de manière indépendante du fournisseur. Le nouveau module dynamique NGINX OTel fournit une implémentation OTel hautes performances pour le traçage des requêtes HTTP NGINX Plus.

• Paquets expérimentaux QUIC+HTTP/3 – Les paquets d’aperçu de NGINX Plus R29 avec QUIC+HTTP/3 sont désormais disponibles. Les packages NGINX Plus R29 QUIC prennent en charge HttpContext et une gamme de nouvelles directives pour gérer les connexions QUIC et le trafic HTTP/3.

Changements importants dans le comportement

Note : Si vous effectuez une mise à niveau à partir d'une version autre que NGINX Plus R28, assurez-vous de consulter la section Modifications importantes du comportement dans les blogs d'annonces précédents pour toutes les versions entre votre version actuelle et celle-ci.

Modifications apportées au référentiel de packaging

L'ancien référentiel de packages plus-pkgs.nginx.com est immédiatement mis hors service avec la sortie de NGINX Plus R29. Ce référentiel n'a pas été mis à jour depuis NGINX Plus R25 et il est fortement conseillé d'utiliser le référentiel de packages pkgs.nginx.com qui a été introduit dans NGINX Plus R24 .

Modifications apportées à la prise en charge de la plateforme

Nouveaux systèmes d’exploitation pris en charge :

• Amazon Linux 2023

Anciens systèmes d’exploitation supprimés :

• Alpine 3.13, qui a atteint la fin de vie (EOL) le 1er novembre 2022

Les anciens systèmes d'exploitation sont obsolètes et leur suppression est prévue dans NGINX Plus R30 :

• Ubuntu 18.04, qui atteindra sa 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 fin de vie de ModSecurity

Conformément à l' annonce EOL de ModSecurity , NGINX Plus R29 supprime la prise en charge des packages ModSecurity. Si vous êtes un client NGINX Plus utilisant les packages ModSecurity, vous pourrez bientôt opter pour un programme d'échange entre ModSecurity et NGINX App Protect . Les détails à ce sujet seront bientôt disponibles et vous pouvez contacter votre contact au F5 pour plus d'informations.

Nouvelles fonctionnalités en détail

Prise en charge du protocole MQTT

MQTT (Message Queuing Telemetry Transport) est un protocole de messagerie de publication-abonnement populaire et léger, idéal pour connecter des appareils et des applications IoT (clients) via Internet. Il permet aux clients de publier des messages sur un sujet spécifique et de s'abonner à d'autres sujets. Les clients abonnés reçoivent tous les messages publiés sur cette rubrique, permettant 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 courtier. Un courtier est un serveur chargé de suivre les clients et tous les sujets auxquels 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 agit comme un proxy entre les clients et les courtiers, ce qui simplifie l'architecture du système, décharge les tâches et réduit les coûts.

L'ensemble initial de fonctionnalités MQTT permet :

• Équilibrage de charge du courtier MQTT
• Persistance de session (reconnexion des clients au même courtier)
• 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 des parties des messages MQTT CONNECT, permettant 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 avec le module ngx_stream_mqtt_preread_module
et les modules ngx_stream_mqtt_filter_module .

Exemples MQTT

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

Note: L’utilisation de l’adresse IP d’un appareil comme identifiant client MQTT n’est pas recommandée dans un environnement de production.

flux { mqtt activé ;
 serveur { écouter 1883; proxy_pass 10.0.0.8:1883; mqtt_set_connect clientid '$remote_addr'; } }

Étant donné la nature éphémère des clients MQTT, vous ne pouvez pas simplement vous fier au nom d’hôte ou à l’adresse IP d’un appareil pour établir des sessions persistantes afin d’équilibrer la charge des courtiers. Dans cet exemple, l’identifiant client MQTT d’un appareil agit comme une clé de hachage pour conserver les connexions aux courtiers MQTT individuels dans un cluster à charge équilibrée :

flux { mqtt_preread activé ;
 courtiers en amont { zone tcp_mem 64k ; hachage $mqtt_preread_clientid cohérent ;
 serveur 10.0.0.7:1883; # courtier mqtt 1 serveur 10.0.0.8:1883; # courtier mqtt 2 serveur 10.0.0.9:1883; # courtier mqtt 3 }
 serveur { écouter 1883 ; proxy_pass courtiers ; proxy_connect_timeout 1s ; } }

Prochaines étapes

Les développements futurs de MQTT dans NGINX Plus peuvent inclure l'analyse d'autres types de messages MQTT, ainsi qu'une analyse plus approfondie du message CONNECT pour activer des fonctions telles que :

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

Nous aimerions 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 SAML pour l'authentification et l'autorisation

SAML (Security Assertion Markup Language) est une norme de fédération ouverte qui permet à un fournisseur d'identité (IdP) d'authentifier les utilisateurs pour l'accès à une ressource (en s'assurant que l'utilisateur final est bien celui qu'il prétend être) et de transmettre ces informations d'authentification, ainsi que les droits d'accès de l'utilisateur sur cette ressource, à un fournisseur de services (SP) pour autorisation.

Avec une longue expérience dans la fourniture d'un moyen sécurisé d'échange de données d'identité, SAML est un protocole largement adopté pour l'échange d'informations d'authentification et d'autorisation entre un IdP et un SP.

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

• Gestion efficace d'un grand volume d'identités
• Sécurité d'identité amélioré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 des conformités réglementaires

 
SAML offre également plusieurs avantages :

• Meilleure expérience utilisateur : Grâce à son intégration SSO et à son point unique de vérification d'authentification au niveau de l'IdP, SAML permet aux utilisateurs d'avoir une authentification unique qui accède à 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 informations d’identification pour différentes applications.

• Sécurité renforcée : En fonction des politiques de sécurité et d'authentification de votre organisation, les utilisateurs peuvent se connecter à l'aide d'un schéma d'authentification SSO soit sur l'interface SP (SSO initié par le SP), soit directement sur l'interface IdP (SSO initié par l'IdP). Cela réduit les risques de sécurité dus aux mots de passe potentiellement faibles et/ou répétitifs.

• Coûts administratifs réduits : SAML aide les organisations à décharger les responsabilités de gestion des identités sur un IdP de confiance, réduisant ainsi le coût de maintenance des informations de compte et les dépenses associées.

• Protocole standardisé : Conçu avec le principe de rendre la sécurité indépendante de la logique d'application (autant que possible), SAML est un protocole standardisé pris en charge par presque tous les IdP et systèmes de gestion d'accès. Il fait abstraction du cadre de sécurité des architectures de plateforme et des implémentations particulières des fournisseurs, ce qui permet 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 est construite à l'aide du framework NGINX JavaScript (njs). Dans cette implémentation, NGINX Plus agit comme un SP SAML, lui permettant de participer à une configuration SSO avec un IdP SAML. L'implémentation actuelle dépend également du magasin clé-valeur , qui est une fonctionnalité NGINX Plus existante et, en tant que telle, n'est pas adaptée à NGINX Open Source sans modifications supplémentaires.

La prise en charge SAML dans NGINX Plus est disponible en tant qu'implémentation de référence sur GitHub. Le référentiel GitHub inclut un exemple de configuration avec des instructions sur l'installation, la configuration et le réglage fin pour des cas d'utilisation spécifiques.

OpenTelemetry natif

OpenTelemetry (OTel) est une technologie et une norme qui peuvent être utilisées pour la surveillance, le traçage, le dépannage et l'optimisation des applications. OTel fonctionne en collectant des données de télémétrie à partir de diverses sources, telles que des proxys, des applications ou d'autres services dans une pile d'applications déployée.

En tant que proxy inverse et équilibreur de charge prenant en charge le protocole, NGINX est idéalement placé pour lancer des appels de télémétrie afin de tracer les demandes et les réponses des applications. Alors que les modules OTel tiers sont disponibles depuis un certain temps, nous sommes ravis d'annoncer la prise en charge native d'OTel dans NGINX Plus avec un nouveau module dynamique .

Le nouveau module ngx_otel_module peut être installé à l'aide du package nginx-plus-module-otel et apporte plusieurs améliorations clés aux modules tiers, notamment :

• Meilleures performances – La plupart des implémentations OTel réduisent les performances du traitement des demandes jusqu’à 50 % lorsque le traçage est activé. Notre nouveau module natif limite cet impact à environ 10-15 %.
• Provisionnement facile – La configuration et l’installation de la collecte de télémétrie peuvent être effectuées directement dans les fichiers de configuration NGINX.
• Échantillonnage entièrement dynamique basé sur des variables – La possibilité de suivre une session particulière par cookie/jeton et contrôler le module de manière dynamique via l' API NGINX Plus et les modules de stockage clé-valeur .

Plus de détails sur le module dynamique OTel sont disponibles 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 :

charger_module modules/ngx_otel_module.so;
 événements {}
 http { otel_exporter { point de terminaison localhost:4317; }
 serveur { écouter 127.0.0.1:8080;
 otel_trace activé ;        hôtel_span_name app1 ;    } }

Dans l’exemple suivant, nous héritons des contextes de trace des requêtes entrantes et enregistrons les étendues uniquement si une étendue parent est échantillonnée. Nous propageons également les contextes de trace et les décisions d’échantillonnage aux serveurs en amont.

charger_module modules/ngx_otel_module.so;
 http { serveur { emplacement / { otel_trace $otel_parent_sampled; otel_trace_context propager; proxy_pass http://backend; } } }

Dans cet exemple basé sur un ratio, le traçage est configuré pour un pourcentage de trafic (dans ce cas 10 %) :

http { # trace 10 % des requêtes split_clients "$otel_trace_id" $ratio_sampler { 10 % activé ; * désactivé ; }
 # ou nous pouvons tracer 10 % des sessions utilisateur
 split_clients "$cookie_sessionid" $session_sampler { 10 % activé ; * désactivé ; }
 serveur { emplacement / { 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=nom;
 serveur { emplacement / { otel_trace $trace_switch; otel_trace_context inject; proxy_pass http://backend; }
 emplacement /api { api write=on; } } }

Paquets expérimentaux QUIC+HTTP/3

Suite à notre annonce de packages binaires d'aperçu pour NGINX Open Source , nous sommes heureux d'annoncer des packages QUIC expérimentaux pour NGINX Plus R29. Cela permet de tester et d'évaluer HTTP/3 avec NGINX Plus.

Avec une nouvelle pile de protocoles sous-jacente, HTTP/3 apporte UDP et QUIC à la couche de transport. QUIC est un protocole de transport crypté conçu pour améliorer TCP en fournissant un multiplexage de connexion et en résolvant des problèmes tels que le blocage en tête de ligne. Il réimplémente et améliore un certain nombre de fonctionnalités TCP de HTTP/1.1 et HTTP/2, notamment l'établissement de connexion, le contrôle de la congestion et la livraison fiable. QUIC intègre également TLS en tant que composant intégral, contrairement à HTTP/1.1 et HTTP/2 qui ont TLS comme couche distincte. Cela signifie que les messages HTTP/3 sont intrinsèquement sécurisés car ils sont envoyés via une connexion cryptée par défaut.

En règle générale, pour une communication sécurisée et une fonctionnalité cryptographique, NGINX Plus s'appuie sur OpenSSL , en utilisant les bibliothèques SSL/TLS fournies avec les systèmes d'exploitation. Cependant, comme les interfaces TLS de QUIC ne sont pas prises en charge par OpenSSL au moment de la rédaction de cet article, des bibliothèques tierces sont nécessaires pour fournir la fonctionnalité TLS manquante requise par HTTP/3.

Pour répondre à cette préoccupation, nous avons développé une couche de compatibilité OpenSSL pour QUIC, supprimant ainsi le besoin de créer et de livrer 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 le fardeau d'une implémentation TLS personnalisée ni la dépendance aux calendriers et aux feuilles de route des bibliothèques tierces.

Note : La couche de compatibilité OpenSSL est incluse dans les packages expérimentaux NGINX Plus QUIC+HTTP/3 et nécessite OpenSSL 1.1.1 ou supérieur pour fournir TLSv1.3 (qui est requis par le protocole QUIC). Il n'implémente pas encore 0-RTT.

Exemple de configuration de QUIC+HTTP/3

Regardons 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 journaux/access.log rapide ;
 serveur { # pour une meilleure compatibilité, il est recommandé # d'utiliser le même port pour quic et https listen 8443 quic reuseport; listen 8443 ssl;
 certificat_ssl certs/exemple.com.crt; clé_certificat_ssl certs/exemple.com.key;
 emplacement / { # requis pour que les navigateurs les dirigent vers le port rapide add_header Alt-Svc 'h3=":8443"; ma=86400'; } } }

Similairement à notre implémentation de HTTP/2 , lorsque NGINX Plus agit comme un 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 NGINX Plus QUIC+HTTP/3 sont disponibles à partir d'un référentiel séparé, accessible avec les certificats et clés NGINX Plus existants. L'installation des packages expérimentaux QUIC est similaire à une installation NGINX Plus standard. Assurez-vous d'utiliser le référentiel QUIC, comme indiqué dans les étapes d'installation.

Vous pouvez vous référer à Configuration de NGINX pour QUIC+HTTP/3 pour plus d'informations sur la configuration de NGINX pour QUIC+HTTP/3. Pour plus d'informations sur toutes les nouvelles directives et variables, consultez la section Configuration du fichier README de nginx-quic .

Prochaines étapes

Dans un avenir proche, nous prévoyons de fusionner le code QUIC+HTTP/3 dans la branche principale NGINX. La dernière version de la ligne principale NGINX avec prise en charge de QUIC+HTTP/3 sera ensuite fusionnée dans une prochaine version de NGINX Plus. Attendez-vous à une annonce sur la disponibilité officielle du support QUIC+HTTP/3 dans NGINX Plus plus tard cette année.

Autres améliorations dans 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 ultérieures. NGINX Plus R29 continue d'améliorer 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 après qu'un utilisateur s'est authentifié et a autorisé l'accès avec succès, puis le stocke dans le magasin clé-valeur. NGINX Plus peut transmettre ce jeton sur l'en-tête d'autorisation HTTP en tant que jeton porteur pour chaque demande envoyée à l'application en aval.

Note : NGINX Plus ne vérifie pas la validité du jeton d'accès à chaque demande (comme il le fait avec le jeton d'identification) et ne peut 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'identification, vous devez utiliser la directive proxy_intercept_errors on. Cela interceptera et redirigera les réponses 401 non autorisées vers NGINX et actualisera le jeton d'accès.

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

Arguments ajoutés dans le point de terminaison d'authentification OIDC

Certains fournisseurs d'identité, comme Keycloak , permettent d'ajouter des arguments de chaîne de requête supplémentaires à la demande d'authentification pour activer des fonctionnalités supplémentaires. Par exemple, Keycloak permet de spécifier un IdP 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 arguments 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é une prise en charge supplémentaire du compteur SSL pour les erreurs de négociation et les échecs de validation de certificat dans les modules HTTP et Stream pour les connexions côté client et côté serveur. Notre module Prometheus-njs , qui convertit les métriques NGINX Plus dans un format compatible Prometheus, prend désormais en charge ces compteurs.

Nouvelle directive internal_redirect

La nouvelle directive et le nouveau module internal_redirect permettent 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 redirection interne :

http { limite_req_zone $jwt_claim_sub zone=jwt_sub:10m débit=1r/s;
 serveur { emplacement / { auth_jwt "royaume"; auth_jwt_key_file key.jwk;
 redirection interne @rate_limited; }
 emplacement @rate_limited { interne ; limit_req zone=jwt_sub burst=10 ;
 proxy_pass http://backend ; } } }

Dans l'exemple ci-dessus, l'authentification JWT est effectuée au niveau du bloc d'emplacement et, si le jeton est valide, la demande est transmise au gestionnaire de contenu interne @rate_limited, où une limite de taux de demande est appliquée en fonction de la valeur de la sous-revendication. Cela se produit dans le JWT avant que la demande ne soit transmise au service en amont.

Cette configuration particulière empêche une attaque par déni de service (DoS) où un attaquant envoie un flot de requêtes contenant des JWT lisibles, codés avec un utilisateur particulier comme sous-champ. Ce flot de requêtes ne passera pas l’authentification mais sera comptabilisé dans la limite de débit. En authentifiant le JWT avant de transmettre la demande au gestionnaire de contenu, vous garantissez que seules les demandes 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 hérite des modifications fonctionnelles et des corrections de bugs apportées depuis la sortie de NGINX Plus R28 (dans NGINX 1.23.3 à 1.23.4).

Changements

• Le protocole TLSv1.3 est désormais activé par défaut et constitue la valeur par défaut pour ces directives :
• ssl_protocols ( HTTP , Stream , Mail )
• proxy_ssl_protocols ( HTTP , Stream )
• protocoles grpc_ssl
• protocoles uwsgi_ssl
• protocoles zone_sync_ssl
• 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 persistantes si le pipeline a été utilisé par le client.
• Le niveau de journalisation de la longueur des données est trop long, la longueur est trop courte, la version héritée est incorrecte, aucun algorithme de signature partagé, la longueur du condensé est incorrecte, l'extension sigalgs est manquante, la longueur cryptée est trop longue, la longueur est incorrecte, la mise à jour de la clé est incorrecte, les données de négociation et de non-négociation sont mixtes, les ccs sont reçus tôt, les données entre les ccs et les données terminées, la longueur du paquet est trop longue, trop d'alertes d'avertissement, l'enregistrement est trop petit et une fin est obtenue avant qu'une erreur SSL ccs ne soit abaissée de crit à info.

Caractéristiques

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

Corrections de bugs

• Plages de ports fixes dans la directive d'écoute qui ne fonctionnaient pas.
• Correction d'un emplacement incorrect potentiellement choisi pour traiter une demande si un emplacement de préfixe de plus de 255 caractères était utilisé dans la configuration.
• Correction des caractères non ASCII dans les noms de fichiers sous Windows, qui n'étaient pas pris en charge 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 avec du code400 .
• Messages corrigés concernant la journalisation des erreurs dans Syslog , qui ne contenaient pas d'informations indiquant que les erreurs se produisaient lors de la journalisation dans Syslog .
• Gestion fixe des événements de lecture client bloqués dans le proxy -r.
• Correction d'une erreur qui se produisait parfois lors de la lecture de l'en-tête du protocole PROXY version 2 avec un grand nombre de TLV.
• Correction d'une erreur de segmentation qui se produisait parfois dans un processus de travail si SSI était utilisé pour traiter des sous-requêtes créées par d'autres modules.
• Correction du problème NGINX qui monopolisait potentiellement le processeur pendant le proxy sans tampon si des connexions SSL aux backends étaient utilisées.

Solutions de contournement

• le filtre zip n'a pas pu utiliser la mémoire pré-allouée. Des alertes sont apparues dans les journaux lors de l'utilisation de zlib-ng .
• Lorsqu'un nom d'hôte utilisé dans la directive d'écoute se résout en plusieurs adresses, NGINX ignore désormais les doublons dans ces adresses.

Pour 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 des versions 0.7.9 à 0.7.12 du module NGINX JavaScript (njs). 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 les documents XML
• Prise en charge de la compression des modules Zlib

Pour une liste complète de toutes les fonctionnalités, modifications et corrections de bogues de la version 0.7.9 à 0.7.12 de njs, consultez le journal des modifications de njs .

Prise en charge étendue de l'API Fetch

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

fonction asynchrone makeRequest(uri, en-têtes) {     let h = new Headers(headers);
    h.delete("bar");
    h.append("foo", "xxx");
    let r = new Request(uri, {headers: h});
    return wait 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() prend désormais les clés au format JWK en entrée :

fonction asynchrone importSigningJWK(jwk) {    retour wait crypto.subtle.importKey('jwk', jwk,
                                         {nom : "RSASSA-PKCS1-v1_5"},
                                            vrai, ['signe']);
}

njs 0.7.10 a également ajouté les méthodes generateKey() et exportKey() . La méthode generateKey() vous 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 un objet CryptoKey en entrée et renvoie la clé dans un format externe et portable. Il prend en charge le format JWK pour exporter la clé sous forme d'objet JSON.

Pour plus de détails, reportez-vous à l'API Web Crypto .

Prise en charge des documents XML

Le module XML a été ajouté dans njs 0.7.10 pour fournir un support natif pour travailler avec des documents XML.

Analyse de documents XML

Vous pouvez désormais analyser une chaîne ou un tampon pour un document XML, 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 les documents XML

L'API XMLNode a été ajoutée dans njs 0.7.11 pour modifier les 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');
supprimer 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><à>Tove</à><de>Jani2</de></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))
/* '<à><a></a><b></b><a></a></à>' */
   

  doc.$root.to.removeChildren('a');
   

  console.log(xml.serializeToString(doc.$root.to))
/* '<à><b></b></à>' */

Pour plus de détails sur toutes les améliorations liées à XML, reportez-vous aux documents XML .

Prise en charge de la compression des modules Zlib

Le module zlib a été ajouté dans njs 0.7.12 et fournit une fonctionnalité 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, reportez-vous aux documents zlib .

Mettre à niveau ou essayer NGINX Plus

Si vous utilisez NGINX Plus, nous vous encourageons vivement à effectuer une mise à niveau vers NGINX Plus R29 dès que possible. En plus de toutes ces nouvelles fonctionnalités intéressantes, vous bénéficierez également de plusieurs correctifs et améliorations supplémentaires, et le fait d'être à jour aidera NGINX à vous aider si vous devez ouvrir un ticket d'assistance.

Si vous n'avez pas essayé NGINX Plus, nous vous encourageons à l'essayer - pour la sécurité, l'équilibrage de charge et la passerelle API, ou en tant que serveur Web entièrement pris en charge avec des API de surveillance et de gestion améliorées. Commencez dès aujourd'hui avec un essai gratuit de 30 jours .