Presentamos NGINX Plus R29

Prabhat Dixit

Michael Vernik

Nos complace anunciar la disponibilidad de NGINX Plus Release 29 (R29). Basado en NGINX Open Source, NGINX Plus es el único servidor web de software todo en uno que también funciona como equilibrador de carga, proxy inverso, caché de contenido y puerta de enlace de API.
Entre las funciones nuevas y mejoradas de NGINX Plus R29 se incluyen:

• Compatibilidad con el protocolo MQTT– Message Queuing Telemetry Transport (MQTT) es un protocolo ligero utilizado para la comunicación entre dispositivos del Internet de las cosas (IoT). NGINX Plus R29 es compatible con el protocolo MQTT mediante los módulos Preread y Filter, que incorporan varias directivas y variables nuevas para ayudar a gestionar y proteger el tráfico MQTT.
• Compatibilidad con SAML para la autenticación y la autorización – Security Assertion Markup Language (SAML) es un protocolo consolidado que proporciona inicio de sesión único (SSO) en aplicaciones web. Ahora, NGINX Plus se puede configurar como proveedor de servicios (SP) SAML para autenticar a los usuarios mediante un proveedor de identidades (IdP) SAML.
• OpenTelemetry nativo – OpenTelemetry (OTel) es un marco que genera, recopila y exporta datos de telemetría (trazas, métricas y registros) de fuentes remotas de forma independiente del proveedor. El nuevo módulo dinámico NGINX OTel proporciona una implementación de OTel de alto rendimiento para el seguimiento de solicitudes HTTP de NGINX Plus.
• Paquetes experimentales de QUIC+HTTP/3 – Ya están disponibles los paquetes preliminares de NGINX Plus R29 con QUIC+HTTP/3. Los paquetes QUIC de NGINX Plus R29 ofrecen compatibilidad con HttpContext y una serie de nuevas directivas para gestionar las conexiones QUIC y el tráfico HTTP/3.

Cambios importantes en el comportamiento

Nota: Si va a actualizar desde una versión distinta de NGINX Plus R28, asegúrese de consultar la sección «Cambios importantes de comportamiento» en los blogs de anuncios anteriores correspondientes a todas las versiones comprendidas entre la que utiliza actualmente y esta.

Cambios en el repositorio de paquetes

El antiguo repositorio de paquetes plus-pkgs.nginx.com queda fuera de servicio de forma inmediata con el lanzamiento de NGINX Plus R29. Este repositorio no se ha actualizado desde NGINX Plus R25 y se recomienda encarecidamente utilizar el repositorio de paquetes pkgs.nginx.com, que se introdujo en NGINX Plus R24.

Cambios en la compatibilidad con plataformas

Nuevos sistemas operativos compatibles:

• Amazon Linux 2023

Sistemas operativos antiguos eliminados:

• Alpine 3.13, que llegó al final de su vida útil (EOL) el 1 de noviembre de 2022

Sistemas operativos antiguos obsoletos y cuya eliminación está prevista en NGINX Plus R30:

• Ubuntu 18.04, que llegará al final de su vida útil en junio de 2023
• Alpine 3.14, que llegará al final de su vida útil en mayo de 2023

Adaptación al anuncio del fin de vida útil de ModSecurity

De acuerdo con el anuncio del fin de vida útil de ModSecurity, NGINX Plus R29 deja de ser compatible con los paquetes de ModSecurity. Si es cliente de NGINX Plus y utiliza paquetes de ModSecurity, pronto podrá optar por participar en un programa de canje entre ModSecurity y NGINX App Protect. Próximamente se ofrecerán más detalles al respecto. Para obtener más información, puede ponerse en contacto con su representante de F5.

Nuevas funciones en detalle

Compatibilidad con el protocolo MQTT

MQTT (Message Queuing Telemetry Transport) es un protocolo de mensajería ligero y popular basado en el modelo de publicación-suscripción, ideal para conectar dispositivos y aplicaciones (clientes) del IoT a través de Internet. Permite a los clientes publicar mensajes en un tema específico y suscribirse a otros temas. Los clientes suscritos reciben todos los mensajes publicados en ese tema, lo que permite un intercambio de datos eficiente y tolerante a fallos entre numerosos dispositivos y servicios.

En el núcleo de una arquitectura MQTT se encuentra un bróker. Un bróker es un servidor encargado de realizar un seguimiento de los clientes y de los temas a los que están suscritos, procesar los mensajes y dirigirlos a los sistemas adecuados. NGINX Plus R29 es compatible con MQTT 3.1.1 y MQTT 5.0. Actúa como proxy entre los clientes y los brókeres, lo que simplifica la arquitectura del sistema, descarga tareas y reduce los costes.

El conjunto inicial de funcionalidades de MQTT permite:

• Equilibrado de carga del bróker MQTT
• Persistencia de sesión (reconexión de los clientes al mismo bróker)
• Terminación TLS
• Autenticación mediante certificado de cliente
• Análisis y reescritura de mensajes CONNECT

El protocolo MQTT define varios tipos de mensajes, entre ellos CONNECT, PUBLISH y SUBSCRIBE. NGINX Plus R29 puede analizar y reescribir de forma activa partes de los mensajes CONNECT de MQTT, lo que permite implementar escenarios de configuración que antes solo eran posibles mediante scripts personalizados.

El análisis y la reescritura de mensajes MQTT deben definirse en el contexto Stream de un archivo de configuración de NGINX y son posibles gracias a los módulos ngx_stream_mqtt_preread_module
y ngx_stream_mqtt_filter_module.

Ejemplos de MQTT

Modificar el identificador de cliente predeterminado que envía un dispositivo MQTT permite a NGINX ocultar información confidencial, como el número de serie del dispositivo. En este primer ejemplo, el identificador se sustituye por la dirección IP del dispositivo.

Nota: No se recomienda utilizar la dirección IP de un dispositivo como identificador de cliente MQTT en un entorno de producción.

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

Dada la naturaleza efímera de los clientes MQTT, no se puede confiar únicamente en el nombre de host o la dirección IP de un dispositivo para establecer sesiones persistentes con brókeres con balanceo de carga. En este ejemplo, el identificador de cliente MQTT de un dispositivo actúa como clave hash para mantener las conexiones con brókeres MQTT concretos de un clúster con balanceo de carga:

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

Próximos pasos

Los futuros desarrollos de MQTT en NGINX Plus podrían incluir el análisis de otros tipos de mensajes MQTT, así como un análisis más exhaustivo del mensaje CONNECT para habilitar funciones como:

• Mecanismos adicionales de autenticación y control de acceso
• Protección de los brokers mediante la limitación de la tasa de los clientes «parlanchines»
• Telemetría de mensajes y métricas de conexión

Nos encantaría conocer tu opinión sobre las funciones que más te importan. Cuéntanos qué piensas en los comentarios.

Compatibilidad con SAML para la autenticación y la autorización

SAML (Security Assertion Markup Language) es un estándar abierto de federación que permite a un proveedor de identidades (IdP) autenticar a los usuarios para que accedan a un recurso (garantizando que el usuario final sea realmente quien dice ser) y transmitir esa información de autenticación, junto con los derechos de acceso del usuario a dicho recurso, a un proveedor de servicios (SP) para su autorización.

Con una larga trayectoria como medio seguro para intercambiar datos de identidad, SAML es un protocolo ampliamente adoptado para el intercambio de información de autenticación y autorización entre un IdP y un SP.

Entre los principales motivos por los que las empresas y las instituciones gubernamentales optan por adoptar SAML se incluyen:

• Gestión eficaz de un gran volumen de identidades
• Seguridad de identidad mejorada, coherente y unificada para clientes y empleados
• Mejora de la eficiencia operativa mediante la estandarización de los procesos de gestión de identidades
• Gestión eficiente del cumplimiento normativo

SAML también ofrece varias ventajas:

• Mejor experiencia de usuario: Gracias a su integración con el SSO y a un único punto de verificación de la autenticación en el IdP, SAML permite a los usuarios autenticarse una sola vez para acceder a todos los servicios conectados. Esto mejora la experiencia de usuario y ahorra tiempo, ya que los usuarios no tienen que recordar varias credenciales para distintas aplicaciones.
• Mayor seguridad: En función de las políticas de seguridad y autenticación de su organización, los usuarios pueden iniciar sesión mediante un sistema de autenticación SSO, ya sea desde la interfaz del SP (SSO iniciado por el SP) o directamente desde la interfaz del IdP (SSO iniciado por el IdP). Esto reduce los riesgos de seguridad derivados del uso de contraseñas potencialmente débiles o repetidas.
• Reducción de los costes administrativos: SAML permite a las organizaciones delegar las responsabilidades de gestión de identidades en un IdP de confianza, lo que reduce el coste de mantener la información de las cuentas y los gastos asociados.
• Protocolo estandarizado: Diseñado según el principio de hacer que la seguridad sea independiente de la lógica de la aplicación (en la medida de lo posible), SAML es un protocolo estandarizado compatible con casi todos los IdP y sistemas de gestión de acceso. Desvincula el marco de seguridad de las arquitecturas de plataforma y de las implementaciones específicas de cada proveedor, lo que permite una seguridad sólida y una integración fiable entre sistemas.

La implementación de referencia actual de SAML utiliza SAML 2.0 y se ha desarrollado con el framework NGINX JavaScript (njs). En esta implementación, NGINX Plus actúa como SP de SAML, lo que le permite participar en una configuración de SSO con un IdP de SAML. La implementación actual también depende del almacén de pares clave-valor, una funcionalidad existente de NGINX Plus que, como tal, no es apta para NGINX Open Source sin modificaciones adicionales.

La compatibilidad con SAML en NGINX Plus está disponible como implementación de referencia en GitHub. El repositorio de GitHub incluye una configuración de ejemplo con instrucciones para la instalación, la configuración y el ajuste preciso para casos de uso específicos.

OpenTelemetry nativo

OpenTelemetry (OTel) es una tecnología y un estándar que se pueden utilizar para supervisar, rastrear, solucionar problemas y optimizar aplicaciones. OTel funciona recopilando datos de telemetría de diversas fuentes, como proxies, aplicaciones u otros servicios de una pila de aplicaciones desplegada.

Como proxy inverso y equilibrador de carga compatible con distintos protocolos, NGINX se encuentra en una posición ideal para iniciar llamadas de telemetría que permitan rastrear las solicitudes y respuestas de las aplicaciones. Aunque los módulos de OTel de terceros están disponibles desde hace tiempo, nos complace anunciar la compatibilidad nativa con OTel en NGINX Plus mediante un nuevo módulo dinámico.

El nuevo módulo ngx_otel_module se puede instalar mediante el paquete nginx-plus-module-otel y ofrece varias mejoras importantes con respecto a los módulos de terceros, entre ellas:

• Mejor rendimiento – La mayoría de las implementaciones de OTel reducen el rendimiento del procesamiento de solicitudes hasta en un 50 % cuando el seguimiento está activado. Nuestro nuevo módulo nativo limita este impacto a aproximadamente un 10-15 %.
• Aprovisionamiento sencillo – La recopilación de telemetría se puede instalar y configurar directamente en los archivos de configuración de NGINX.
• Muestreo basado en variables totalmente dinámico – La capacidad de rastrear una sesión concreta mediante una cookie o un token y controlar el módulo dinámicamente a través de la API de NGINX Plus y los módulos de almacén de pares clave-valor.

Encontrará más información sobre el módulo dinámico de OTel en la documentación de NGINX.

Ejemplos de rastreo con OTel

Este es un ejemplo de trazado básico con OTel de una aplicación servida directamente por 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;
      }
  }

En el siguiente ejemplo, heredamos los contextos de traza de las solicitudes entrantes y registramos spans únicamente si se ha muestreado un span padre. También propagamos los contextos de traza y las decisiones de muestreo a los servidores ascendentes.

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

En este ejemplo basado en una proporción, el seguimiento se configura para un porcentaje del tráfico (en este caso, el 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;
          }
      }
  }

En este ejemplo controlado mediante la API, el seguimiento se habilita manipulando el almacén de pares clave-valor a través del endpoint /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;
          } 
      }
  }

Paquetes experimentales de QUIC+HTTP/3

Tras nuestro anuncio de paquetes binarios preliminares para NGINX Open Source, nos complace anunciar paquetes QUIC experimentales para NGINX Plus R29. Esto permite probar y evaluar HTTP/3 con NGINX Plus.

Con una nueva pila de protocolos subyacente, HTTP/3 incorpora UDP y QUIC a la capa de transporte. QUIC es un protocolo de transporte cifrado diseñado para mejorar TCP mediante la multiplexación de conexiones y la resolución de problemas como el bloqueo de cabecera de línea. Reimplementa y mejora varias funciones de TCP presentes en HTTP/1.1 y HTTP/2, como el establecimiento de conexiones, el control de congestión y la entrega fiable. QUIC también integra TLS como componente esencial, a diferencia de HTTP/1.1 y HTTP/2, donde TLS constituye una capa independiente. Esto significa que los mensajes HTTP/3 son intrínsecamente seguros, ya que se envían de forma predeterminada a través de una conexión cifrada.

Normalmente, para las comunicaciones seguras y las funciones criptográficas, NGINX Plus utiliza OpenSSL, aprovechando las bibliotecas SSL/TLS incluidas con los sistemas operativos. Sin embargo, dado que, en el momento de redactar este texto, OpenSSL no admite las interfaces TLS de QUIC, se necesitan bibliotecas de terceros que proporcionen la funcionalidad TLS necesaria para HTTP/3.

Para resolver este problema, desarrollamos una capa de compatibilidad con OpenSSL para QUIC, lo que elimina la necesidad de compilar y distribuir bibliotecas TLS de terceros como quictls, BoringSSL y LibreSSL. Esto permite gestionar la experiencia integral de QUIC+HTTP/3 en NGINX sin la carga que supone una implementación TLS personalizada ni la dependencia de los calendarios y las hojas de ruta de bibliotecas de terceros.

Nota: La capa de compatibilidad con OpenSSL se incluye en los paquetes experimentales de NGINX Plus para QUIC+HTTP/3 y requiere OpenSSL 1.1.1 o una versión posterior para proporcionar TLSv1.3 (que es necesario para el protocolo QUIC). Todavía no implementa 0-RTT.

Configuración de ejemplo de QUIC+HTTP/3

Veamos un ejemplo de configuración de QUIC+HTTP/3 en 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';
          }
      }
  }

Al igual que en nuestra implementación de HTTP/2, cuando NGINX Plus actúa como proxy, las conexiones QUIC+HTTP/3 se establecen en el lado del cliente y se convierten a HTTP/1.1 al conectarse a los servicios de backend y upstream.

Los paquetes experimentales de QUIC+HTTP/3 para NGINX Plus están disponibles en un repositorio independiente, al que se puede acceder con los certificados y claves existentes de NGINX Plus. La instalación de los paquetes experimentales de QUIC es similar a una instalación de NGINX Plus. Asegúrese de utilizar el repositorio de QUIC, tal como se indica en los pasos de instalación.

Puede consultar Configuración de NGINX para QUIC+HTTP/3 para obtener más información sobre cómo configurar NGINX para QUIC+HTTP/3. Para obtener información sobre todas las directivas y variables nuevas, consulte la sección Configuración del README de nginx-quic.

Próximos pasos

En un futuro próximo, tenemos previsto integrar el código de QUIC+HTTP/3 en la rama principal de NGINX. Posteriormente, la versión más reciente de la rama principal de NGINX compatible con QUIC+HTTP/3 se integrará en una próxima versión de NGINX Plus. A finales de este año se anunciará oficialmente la disponibilidad de la compatibilidad con QUIC+HTTP/3 en NGINX Plus.

Otras mejoras de NGINX Plus R29

Cambios en OpenID Connect

La compatibilidad con OpenID Connect (OIDC) se introdujo en NGINX Plus R15 y se mejoró considerablemente en versiones posteriores. NGINX Plus R29 sigue mejorando OIDC con las siguientes incorporaciones.

Compatibilidad con tokens de acceso

Los tokens de acceso se utilizan en la autenticación basada en tokens para permitir que un cliente OIDC acceda a un recurso protegido en nombre del usuario. NGINX Plus recibe un token de acceso después de que un usuario se autentique correctamente y autorice el acceso, y lo almacena en el almacén de clave-valor. NGINX Plus puede incluir ese token en la cabecera HTTP Authorization como un token de portador en cada solicitud que se envíe a la aplicación de backend.

Nota: NGINX Plus no verifica la validez del token de acceso en cada solicitud (como sí hace con el token de ID) y no puede saber si el token de acceso ya ha caducado. Si la duración del token de acceso es inferior a la del token de ID, debe activar la directiva proxy_intercept_errors. De este modo, se interceptarán y redirigirán las respuestas 401 Unauthorized a NGINX y se renovará el token de acceso.

Para obtener más información sobre OpenID Connect y la validación de tokens web JSON (JWT) con NGINX Plus, consulte Autenticación de usuarios en aplicaciones existentes con OpenID Connect y NGINX Plus.

Argumentos añadidos en el endpoint de autenticación OIDC

Algunos proveedores de identidad, como Keycloak, permiten añadir argumentos adicionales a la cadena de consulta de la solicitud de autenticación para habilitar funcionalidades adicionales. Por ejemplo, Keycloak permite especificar un IdP predeterminado añadiendo un parámetro kc_idp_hint a la solicitud de autenticación. Como parte de esta mejora, el usuario puede especificar argumentos adicionales para el endpoint de autorización de OIDC.

Contadores SSL ampliados en el módulo Prometheus-njs

En NGINX Plus R28, añadimos compatibilidad con contadores SSL adicionales para errores de negociación y fallos de validación de certificados en los módulos HTTP y Stream, tanto para conexiones del lado del cliente como del servidor. Nuestro módulo Prometheus-njs, que convierte las métricas de NGINX Plus a un formato compatible con Prometheus, ahora admite estos contadores.

Nueva directiva «internal_redirect»

La nueva directiva y el módulo internal_redirect permiten realizar redirecciones internas tras comprobar los límites de procesamiento de las solicitudes, los límites de procesamiento de las conexiones y los límites de acceso.

Este es un ejemplo de configuración 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;
          }
      }
  }

En el ejemplo anterior, la autenticación JWT se realiza en el bloque location y, si el token es válido, la solicitud se pasa al controlador de contenido interno @rate_limited, donde se aplica un límite de frecuencia de solicitudes basado en el valor de la declaración sub. Esto ocurre en el JWT antes de que la solicitud se pase al servicio ascendente.

Esta configuración concreta evita un ataque de denegación de servicio (DoS) en el que un atacante envía una avalancha de solicitudes que contienen JWT legibles, codificados con un usuario específico en el campo sub. Esa avalancha de solicitudes no superaría la autenticación, pero se contabilizaría para el límite de solicitudes. Al autenticar el JWT antes de pasar la solicitud al controlador de contenido, se garantiza que solo las solicitudes válidas se contabilicen para dicho límite.

Cambios heredados de NGINX Open Source

NGINX Plus R29 se basa en NGINX Open Source 1.23.4 y hereda los cambios funcionales y las correcciones de errores realizados desde el lanzamiento de NGINX Plus R28 (de NGINX 1.23.3 a 1.23.4).

Cambios

• El protocolo TLSv1.3 está ahora habilitado de forma predeterminada y es el valor predeterminado de estas directivas:
• ssl_protocols (HTTP, Flujo, Correo)
• proxy_ssl_protocols (HTTP, Stream)
• grpc_ssl_protocols
• uwsgi_ssl_protocols
• zone_sync_ssl_protocols
• NGINX ahora emite una advertencia si se redefinen los parámetros de protocolo de un socket de escucha.
• NGINX ahora cierra las conexiones de forma prolongada si el cliente ha utilizado pipelining.
• El nivel de registro de los errores 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 y got a fin before a ccs se ha reducido de crit a info.

Características

• Ahora se admiten rangos de bytes en el módulo «ngx_http_gzip_static_module».

Correcciones de errores

• Se han corregido los rangos de puertos de la directiva listen que no funcionaban.
• Se corrigió un problema por el que podía seleccionarse una ubicación incorrecta para procesar una solicitud si se utilizaba en la configuración una ubicación de prefijo de más de 255 caracteres.
• Se corrigió la compatibilidad con caracteres no ASCII en los nombres de archivo en Windows, que no eran compatibles con ngx_http_autoindex_module, ngx_http_dav_module ni con la directiva include.
• Se corrigió una fuga de sockets que se producía ocasionalmente al usar HTTP/2 y la directiva error_page para redirigir errores con el código 400.
• Se corrigieron los mensajes sobre errores al registrar en syslog, que no indicaban que los errores se habían producido durante el registro en syslog.
• Se ha corregido la gestión de los eventos de lectura bloqueados del cliente en proxy -r.
• Se ha corregido un error que se producía en ocasiones al leer la cabecera de la versión 2 del protocolo PROXY con un gran número de TLV.
• Se corrigió un fallo de segmentación que se producía ocasionalmente en un proceso de trabajo si se utilizaba SSI para procesar subsolicitudes creadas por otros módulos.
• Se ha corregido un problema por el que NGINX podía llegar a acaparar la CPU durante el proxy sin búfer si se utilizaban conexiones SSL con los servidores backend.

Soluciones alternativas

• el filtro zip no pudo utilizar la memoria preasignada aparecían alertas en los registros al utilizar zlib-ng.
• Cuando un nombre de host utilizado en la directiva listen se resuelve en varias direcciones, NGINX ahora ignora las direcciones duplicadas.

Para consultar la lista completa de nuevas funcionalidades, cambios, correcciones de errores y soluciones alternativas heredadas de estas versiones, consulte el archivo CHANGES.

Cambios en el módulo JavaScript de NGINX

NGINX Plus R29 incorpora cambios de las versiones 0.7.9 a 0.7.12 del módulo JavaScript de NGINX (njs). Se añadieron varias funciones interesantes a njs, entre ellas:

• Compatibilidad ampliada con la API Fetch
• API Web Crypto ampliada
• Compatibilidad con documentos XML
• Análisis de documentos XML
• API XMLNode para modificar documentos XML
• Compatibilidad con la compresión del módulo Zlib

Para consultar una lista completa de todas las funcionalidades, cambios y correcciones de errores desde la versión 0.7.9 hasta la 0.7.12 de njs, consulte el registro de cambios de njs.

Compatibilidad ampliada con la API Fetch

Headers(), Request(), y Response() se añaden constructores a la API Fetch, junto con otras mejoras:

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 ampliada

La API Web Crypto se amplió para admitir el formato JSON Web Key (JWK), y ahora importKey() acepta claves en formato JWK como entrada:

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

njs 0.7.10 también incorporó los métodos generateKey() y exportKey(). El método generateKey() permite generar una clave nueva para algoritmos simétricos o un par de claves para algoritmos de clave pública. El método exportKey() recibe como entrada un objeto CryptoKey y devuelve la clave en un formato externo y portátil. Admite el formato JWK para exportar la clave como un objeto JSON.

Para obtener más información, consulta la API Web Crypto.

Compatibilidad con documentos XML

El módulo XML se añadió en njs 0.7.10 para ofrecer compatibilidad nativa con el procesamiento de documentos XML.

Análisis de documentos XML

Ahora puede analizar una cadena o un búfer como un documento XML, lo que devuelve un objeto contenedor XMLDoc que representa el documento XML analizado:

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 para modificar documentos XML

La API XMLNode se añadió en njs 0.7.11 para modificar documentos 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>' */

Para obtener más información sobre todas las mejoras relacionadas con XML, consulta la documentación de XML.

Compatibilidad con la compresión del módulo Zlib

El módulo zlib se añadió en njs 0.7.12 y ofrece funciones de compresión mediante los algoritmos deflate e inflate.

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

Para obtener más información sobre zlib, consulta la documentación de zlib.

Actualiza o prueba NGINX Plus

Si utiliza NGINX Plus, le recomendamos encarecidamente que actualice a NGINX Plus R29 lo antes posible. Además de todas las fantásticas funciones nuevas, también obtendrá varias correcciones y mejoras adicionales. Asimismo, mantener el producto actualizado permitirá que NGINX pueda ayudarle mejor si necesita abrir una incidencia de soporte.

Si aún no ha probado NGINX Plus, le animamos a hacerlo, ya sea para seguridad, balanceo de carga y como puerta de enlace de API, o como servidor web con soporte completo y API mejoradas de supervisión y gestión. Empiece hoy mismo con una prueba gratuita de 30 días.

Sobre los autores

Prabhat Dixit

Más artículos de Prabhat Dixit

Michael Vernik

Más artículos de Michael Vernik