Announcing NGINX Plus R29 (Anuncio de NGINX Plus R29)

Nos complace anunciar la disponibilidad de NGINX Plus Release 29 (R29). Basado en NGINX de código abierto, NGINX Plus es el único servidor web de software todo en uno, balanceador de carga, proxy inverso, caché de contenido y puerta de enlace API.
Las características nuevas y mejoradas de NGINX Plus R29 incluyen:

• Compatibilidad con el protocolo MQTT : Message Queueing Telemetry Transport (MQTT) es un protocolo liviano que se utiliza para la comunicación entre dispositivos en la Internet de las cosas (IoT). NGINX Plus R29 admite el protocolo MQTT con módulos de prelectura y filtro que introducen múltiples directivas y variables nuevas para ayudar a administrar y proteger el tráfico MQTT.

• Compatibilidad con SAML para autenticación y autorización : Security Assertion Markup Language (SAML) es un protocolo bien establecido que proporciona inicio de sesión único (SSO) a aplicações web. NGINX Plus ahora se puede configurar como un proveedor de servicios SAML (SP) para autenticar usuarios contra un proveedor de identidad SAML (IdP).

• OpenTelemetry nativo : OpenTelemetry (OTel) es un marco que genera, recopila y exporta datos de telemetría (rastros, métricas y registros) de fuentes remotas de manera independiente del proveedor. El nuevo módulo dinámico NGINX OTel proporciona una implementación OTel de alto rendimiento para el rastreo de solicitudes HTTP NGINX Plus.

• Paquetes experimentales QUIC+HTTP/3 : ya están disponibles los paquetes de vista previa de NGINX Plus R29 con QUIC+HTTP/3. Los paquetes QUIC de NGINX Plus R29 brindan soporte para HttpContext y una variedad de nuevas directivas para administrar conexiones QUIC y tráfico HTTP/3.

Cambios importantes en el comportamiento

Nota : Si está actualizando desde una versión distinta a NGINX Plus R28, asegúrese de consultar la sección Cambios importantes en el comportamiento en los blogs de anuncios anteriores para todas las versiones entre su versión actual y esta.

Cambios en el repositorio de empaquetado

El antiguo repositorio de paquetes plus-pkgs.nginx.com se desmantela inmediatamente 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 el soporte de la plataforma

Nuevos sistemas operativos compatibles:

• Amazon Linux 2023

Sistemas operativos más 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 programados para su eliminación en NGINX Plus R30:

• Ubuntu 18.04, que llegará al fin 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 del ciclo de vida de ModSecurity

De acuerdo con el anuncio de EOL de ModSecurity , NGINX Plus R29 elimina el soporte de los paquetes de ModSecurity. Si es cliente de NGINX Plus y utiliza paquetes ModSecurity, pronto podrá optar por un programa de intercambio entre ModSecurity y NGINX App Protect . Los detalles sobre esto estarán disponibles pronto y puedes comunicarte con tu contacto en F5 para obtener más información.

Nuevas funciones en detalle

Compatibilidad con el protocolo MQTT

MQTT (Message Queuing Telemetry Transport) es un protocolo de mensajería de publicación-suscripción popular y liviano, ideal para conectar dispositivos y aplicações de IoT (clientes) a través de Internet. Permite a los clientes publicar mensajes sobre 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 fallas entre muchos dispositivos y servicios.

En el corazón de una arquitectura MQTT hay un bróker. Un broker es un servidor responsable de rastrear a los clientes y cualquier tema al que estén suscritos, procesar mensajes y enrutar esos mensajes a los sistemas apropiados. NGINX Plus R29 es compatible con MQTT 3.1.1 y MQTT 5.0 . Actúa como proxy entre clientes y corredores, lo que simplifica la arquitectura del sistema, descarga tareas y reduce costos.

El conjunto de características inicial de MQTT permite:

• Balanceo de carga del agente MQTT
• Persistencia de la sesión (reconectar clientes al mismo bróker)
• Terminación de TLS
• Autenticación de certificado de cliente
• Análisis y reescritura de mensajes CONNECT

El protocolo MQTT define varios tipos de mensajes, incluidos CONECTAR, PUBLICAR y SUSCRIBIRSE. NGINX Plus R29 puede analizar y reescribir activamente partes de mensajes MQTT CONNECT, lo que permite escenarios de configuración que antes solo eran posibles con scripts personalizados.

El análisis y la reescritura de mensajes MQTT deben definirse en el contexto Stream de un archivo de configuración NGINX y es posible con ngx_stream_mqtt_preread_module
y módulos ngx_stream_mqtt_filter_module .

Ejemplos de MQTT

Modificar el identificador de cliente predeterminado enviado por un dispositivo MQTT permite a NGINX ocultar información confidencial, como el número de serie de un dispositivo. En este primer ejemplo, el identificador se reescribe a 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.

flujo { mqtt activado;
 servidor { escuchar 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 simplemente en el nombre de host o la dirección IP de un dispositivo para establecer sesiones persistentes con agentes de equilibrio de carga. En este ejemplo, el identificador de cliente MQTT de un dispositivo actúa como una clave hash para persistir las conexiones a agentes MQTT individuales en un clúster con equilibrio de carga:

transmisión { mqtt_preread activado;
 corredores ascendentes{ zona tcp_mem 64k; hash $mqtt_preread_clientid consistente;
 servidor 10.0.0.7:1883; # agente mqtt 1 servidor 10.0.0.8:1883; # agente mqtt 2 servidor 10.0.0.9:1883; # agente mqtt 3 }
 servidor { escuchar 1883; proxy_pass brokers; proxy_connect_timeout 1s; } }

Próximos pasos

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

• Mecanismos adicionales de autenticación y control de acceso
• Proteger a los corredores limitando la tasa de clientes "conversadores"
• Telemetría de mensajes y métricas de conexión

Nos encantaría conocer tus comentarios sobre las características que más te interesan. Déjanos saber lo que piensas en los comentarios.

Compatibilidad con SAML para autenticación y autorización

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

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

Las principales razones por las que las empresas e instituciones gubernamentales deciden adoptar SAML incluyen:

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

 
SAML también ofrece varios beneficios:

• Mejor experiencia de usuario : Con su integración SSO y su único punto de verificación de autenticación en el IdP, SAML permite a los usuarios tener una autenticación que accede a todos los servicios conectados. Esto mejora la experiencia del usuario y ahorra tiempo porque los usuarios ya no necesitan recordar múltiples credenciales para varias aplicações.

• Mayor seguridad : Dependiendo de las políticas de seguridad y autenticación de su organización, los usuarios pueden iniciar sesión utilizando un esquema de autenticación SSO en la interfaz del SP (SSO iniciado por el SP) o directamente en la interfaz del IdP (SSO iniciado por el IdP). Esto reduce los riesgos de seguridad debido a contraseñas potencialmente débiles y/o repetidas.

• Costos administrativos reducidos : SAML ayuda a las organizaciones a descargar las responsabilidades de gestión de identidad a un IdP confiable, reduciendo así el costo de mantenimiento de la información de la cuenta y los gastos asociados.

• Protocolo estandarizado : Diseñado con el principio de hacer que la seguridad sea independiente de la lógica de la aplicação (tanto como sea posible), SAML es un protocolo estandarizado compatible con casi todos los IdP y sistemas de gestión de acceso . Abstrae el marco de seguridad de las arquitecturas de plataforma y las implementaciones de proveedores particulares, lo que permite una seguridad sólida y una integración confiable entre sistemas.

La implementación de referencia actual de SAML utiliza SAML 2.0 y está construida utilizando el marco NGINX JavaScript (njs). En esta implementación, NGINX Plus actúa como un SP SAML, lo que le permite participar en una configuración SSO con un IdP SAML. La implementación actual también depende del almacén de clave-valor , que es una característica existente de NGINX Plus y, como tal, no es adecuada para NGINX Open Source sin modificaciones adicionales.

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

OpenTelemetry nativo

OpenTelemetry (OTel) es una tecnología y un estándar que se puede utilizar para supervisar, rastrear, solucionar problemas y optimizar aplicações. OTel funciona recopilando datos de telemetría de varias fuentes, como servidores proxy, aplicações u otros servicios en una pila de aplicação implementada.

Como proxy inverso y equilibrador de carga que reconoce protocolos, NGINX está en una posición ideal para iniciar llamadas de telemetría para rastrear solicitudes y respuestas de aplicação . Si bien los módulos OTel de terceros han estado disponibles durante algún tiempo, nos complace anunciar soporte nativo para OTel en NGINX Plus con un nuevo módulo dinámico .

El nuevo módulo ngx_otel_module se puede instalar usando el paquete nginx-plus-module-otel y proporciona varias mejoras clave para los módulos de terceros, que incluyen:

• 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á habilitado. Nuestro nuevo módulo nativo limita este impacto a alrededor del 10-15%.
• Aprovisionamiento fácil : la instalación y configuración de la recopilación de telemetría se puede realizar directamente en los archivos de configuración de NGINX.
• Muestreo basado en variables totalmente dinámico : la capacidad de rastrear una sesión particular mediante una cookie o token y controlar el módulo dinámicamente a través de la API NGINX Plus y los módulos de almacenamiento clave-valor .

Más detalles sobre el módulo dinámico OTel están disponibles en la documentación de NGINX .

Ejemplos de rastreo de OTel

A continuación se muestra un ejemplo de seguimiento OTel básico de una aplicação servida directamente por NGINX:

módulo de carga módulos/ngx_otel_module.so;
 eventos {}
 http { hotel_exporter { punto final localhost:4317; }
 servidor { escuchar 127.0.0.1:8080;
 hotel_trace activado;        otel_span_name aplicación1;    } }

En el siguiente ejemplo, heredamos los contextos de seguimiento de las solicitudes entrantes y registramos los intervalos solo si se muestrea un intervalo principal. También propagamos contextos de seguimiento y decisiones de muestreo a servidores ascendentes.

módulo de carga módulos/ngx_otel_module.so;
 http { servidor { ubicación / { otel_trace $otel_parent_sampled; otel_trace_context propagate; proxy_pass http://backend; } } }

En este ejemplo basado en proporciones, el seguimiento se configura para un porcentaje del tráfico (en este caso, el 10 %):

http { # seguimiento del 10% de las solicitudes split_clients "$otel_trace_id" $ratio_sampler { 10% activado; * desactivado; }
 # o podemos rastrear el 10% de las sesiones de usuario
 split_clients "$cookie_sessionid" $session_sampler { 10% activado; * desactivado; }
 servidor { ubicación / { otel_trace $ratio_sampler; otel_trace_context inyectar;
 contraseña_proxy http://backend; } } }

En este ejemplo controlado por API, el seguimiento se habilita manipulando el almacén de clave-valor a través del punto final /api:

http { keyval "otel.trace" $trace_switch zona=nombre;
 servidor { ubicación / { otel_trace $trace_switch; otel_trace_context inyectar; proxy_pass http://backend; }
 ubicación /api { api write=on; } } }

Paquetes experimentales QUIC+HTTP/3

Tras nuestro anuncio de paquetes binarios de vista previa 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 lleva UDP y QUIC a la capa de transporte. QUIC es un protocolo de transporte encriptado diseñado para mejorar TCP al proporcionar multiplexación de conexión y resolver problemas como el bloqueo de cabecera de línea. Reimplementa y mejora una serie de capacidades TCP de HTTP/1.1 y HTTP/2, incluido el establecimiento de conexión, el control de la congestión y la entrega confiable. QUIC también incorpora TLS como un componente integral, a diferencia de HTTP/1.1 y HTTP/2 que tienen TLS como una capa separada. Esto significa que los mensajes HTTP/3 son inherentemente seguros ya que se envían a través de una conexión cifrada de forma predeterminada.

Normalmente, para una comunicación segura y una funcionalidad criptográfica, NGINX Plus se basa en OpenSSL , haciendo uso de las bibliotecas SSL/TLS que vienen con los sistemas operativos. Sin embargo, debido a que las interfaces TLS de QUIC no son compatibles con OpenSSL al momento de escribir este artículo, se necesitan bibliotecas de terceros para proporcionar la funcionalidad TLS faltante que requiere HTTP/3.

Para abordar esta inquietud, desarrollamos una capa de compatibilidad OpenSSL para QUIC, eliminando la necesidad de crear y enviar bibliotecas TLS de terceros como quictls, BoringSSL y LibreSSL. Esto ayuda a administrar la experiencia QUIC+HTTP/3 de extremo a extremo en NGINX sin la carga de una implementación TLS personalizada ni la dependencia de cronogramas y hojas de ruta de bibliotecas de terceros.

Nota : La capa de compatibilidad de OpenSSL está incluida en los paquetes experimentales NGINX Plus QUIC+HTTP/3 y requiere OpenSSL 1.1.1 o superior para proporcionar TLSv1.3 (que es requerido por el protocolo QUIC). Aún no implementa 0-RTT.

Configuración de muestra de QUIC+HTTP/3

Veamos una configuración de muestra de QUIC+HTTP/3 en NGINX Plus:

http { formato_de_registro rápido '$dirección_remota - $usuario_remoto [$tiempo_local]' '"$solicitud" $estado $bytes_del_cuerpo_enviados ' '"$http_referer" "$http_user_agent" "$http3"';
 access_log registros/access.log quic;
 servidor { # para una mejor compatibilidad se recomienda # usar el mismo puerto para quic y https listen 8443 quic reuseport; listen 8443 ssl;
 certificado_ssl certs/ejemplo.com.crt; clave_certificado_ssl certs/ejemplo.com.clave;
 ubicación / { # requerido para que los navegadores los dirijan al puerto rápido add_header Alt-Svc 'h3=":8443"; ma=86400'; } } }

De manera similar a nuestra implementación de HTTP/2 , cuando NGINX Plus actúa como proxy, las conexiones QUIC+HTTP/3 se realizan en el lado del cliente y se convierten a HTTP/1.1 cuando se conecta a servicios backend y upstream.

Los paquetes experimentales NGINX Plus QUIC+HTTP/3 están disponibles en un repositorio separado, accesible con certificados y claves NGINX Plus existentes. La instalación de los paquetes experimentales QUIC es similar a una instalación estándar de NGINX Plus . Asegúrese de utilizar el repositorio QUIC, como se destaca 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 nuevas directivas y variables, consulte la sección Configuración del archivo README de nginx-quic .

Próximos pasos

En un futuro cercano, planeamos fusionar el código QUIC+HTTP/3 en la rama principal de NGINX. La última versión de la línea principal de NGINX con soporte QUIC+HTTP/3 se fusionará en una próxima versión de NGINX Plus. Se espera un anuncio sobre la disponibilidad oficial del soporte QUIC+HTTP/3 en NGINX Plus a finales de este año.

Otras mejoras en NGINX Plus R29

Cambios en OpenID Connect

La compatibilidad con OpenID Connect (OIDC) se introdujo en NGINX Plus R15 y luego se mejoró significativamente en versiones posteriores. NGINX Plus R29 continúa 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 autentica y autoriza el acceso con éxito, y luego lo almacena en el almacén de clave-valor. NGINX Plus puede pasar ese token en el encabezado de autorización HTTP como un token portador para cada solicitud que se envía a la aplicação descendente.

Nota : NGINX Plus no verifica la validez del token de acceso en cada solicitud (como lo hace con el token de identificación) y no puede saber si el token de acceso ya ha expirado. Si la vida útil del token de acceso es menor que la del token de identificación, debe utilizar la directiva proxy_intercept_errors . Esto interceptará y redirigirá las respuestas 401 no autorizadas a NGINX y actualizará el token de acceso.

Para obtener más información sobre OpenID Connect y la validación de JSON Web Token (JWT) con NGINX Plus, consulte Autenticación de usuarios en aplicações existentes con OpenID Connect y NGINX Plus .

Argumentos añadidos en el punto final de autenticación de OIDC

Algunos proveedores de identidad, como Keycloak , permiten agregar argumentos de cadena de consulta adicionales a la solicitud de autenticación para habilitar capacidades adicionales. Por ejemplo, Keycloak permite especificar un IdP predeterminado agregando 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 punto final de autorización de OIDC.

Contadores SSL extendidos en el módulo Prometheus-njs

En NGINX Plus R28, agregamos soporte de contador SSL adicional para errores de protocolo de enlace y fallas de validación de certificados en los módulos HTTP y Stream para conexiones del lado del cliente y del lado 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 módulo internal_redirect permiten redirecciones internas después de verificar los límites de procesamiento de solicitudes , los límites de procesamiento de conexión y los límites de acceso .

A continuación se muestra un ejemplo de configuración de internal_redirect :

http { zona_de_solicitud_límite $jwt_claim_sub zona=jwt_sub:10m tasa=1r/s;
 servidor { ubicación / { auth_jwt "reino"; auth_jwt_key_file key.jwk;
 redirección interna @rate_limited; }
 ubicación @rate_limited { interno; límite_solicitud zona=jwt_sub ráfaga=10;
 contraseña_proxy http://backend ; } } }

En el ejemplo anterior, la autenticación JWT se realiza en el bloque de ubicación 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 tasa de solicitud basado en el valor del reclamo secundario. Esto sucede en el JWT antes de que la solicitud se pase al servicio ascendente.

Esta configuración particular 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 particular como subcampo. Esa avalancha de solicitudes no pasará la autenticación, pero se contabilizará para el límite de velocidad. Al autenticar el JWT antes de pasar la solicitud al controlador de contenido, se garantiza que solo las solicitudes válidas cuenten para el límite de velocidad.

Cambios heredados de NGINX de código abierto

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

Cambios

• El protocolo TLSv1.3 ahora está habilitado de forma predeterminada y es el valor predeterminado para estas directivas:
• protocolos_ssl ( HTTP , transmisión , correo )
• protocolos proxy_ssl ( HTTP , transmisión )
• protocolos grpc_ssl
• protocolos uwsgi_ssl
• protocolos_ssl_de_sincronización_de_zona
• NGINX ahora emite una advertencia si se redefinen los parámetros de protocolo de un socket de escucha.
• NGINX ahora cierra las conexiones persistentes si el cliente utilizó canalización.
• El nivel de registro de los datos es demasiado largo, demasiado corto, mala versión heredada, no hay algoritmos de firma compartida, mala longitud de resumen, falta de extensión sigalgs, longitud encriptada demasiado larga, mala longitud, mala actualización de clave, datos mixtos de protocolo de enlace y no protocolo de enlace, ccs recibidos temprano, datos entre ccs y finalizados, longitud de paquete demasiado larga, demasiadas alertas de advertencia, registro demasiado pequeño y se obtuvo una aleta antes de un ccs. Los errores SSL se han reducido de crítico a información.

Características

• Ahora se admiten rangos de bytes en ngx_http_gzip_static_module .

Corrección de errores

• Se corrigieron los rangos de puertos fijos en la directiva listen que no funcionaban.
• Se solucionó un problema que podía provocar que se eligiera una ubicación incorrecta para procesar una solicitud si se utilizaba una ubicación de prefijo con más de 255 caracteres en la configuración.
• Se corrigieron los caracteres no ASCII en los nombres de archivos en Windows, que no eran compatibles con ngx_http_autoindex_module , ngx_http_dav_module y la directiva include.
• Se solucionó una pérdida de socket que a veces ocurría al usar HTTP/2 y la directiva error_page para redirigir errores con código400 .
• Se corrigieron los mensajes sobre errores de registro en syslog , que no contenían información de que los errores ocurrieron al registrar en syslog .
• Se solucionó el manejo de eventos de lectura de clientes bloqueados en proxy -r.
• Se corrigió un error que a veces ocurría al leer el encabezado de la versión 2 del protocolo PROXY con una gran cantidad de TLV.
• Se corrigió un error de segmentación que a veces ocurría en un proceso de trabajo si se utilizaba SSI para procesar subsolicitudes creadas por otros módulos.
• Se solucionó que NGINX pudiera acaparar la CPU durante el proxy sin búfer si se utilizaban conexiones SSL a los backends.

Soluciones alternativas

• El filtro zip no pudo usar la memoria preasignada. Aparecieron alertas en los registros cuando se usó zlib-ng .
• Cuando un nombre de host utilizado en la directiva listen se resuelve en múltiples direcciones, NGINX ahora ignora los duplicados dentro de estas direcciones.

Para obtener la lista completa de nuevas características, cambios, correcciones de errores y soluciones alternativas heredadas de estas versiones, consulte el archivo CAMBIOS .

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 NGINX JavaScript (njs). Se agregaron varias características interesantes a njs, entre ellas:

• Compatibilidad extendida con la API de búsqueda
• API de criptografía web extendida
• Compatibilidad con documentos XML
• Análisis de documentos XML
• API de XMLNode para modificar documentos XML
• Soporte de compresión del módulo Zlib

Para obtener una lista completa de todas las características, cambios y correcciones de errores de la versión 0.7.9 a la 0.7.12 de njs, consulte el registro de cambios de njs .

Compatibilidad extendida con la API de búsqueda

Se agregan los constructores Headers() , Request() y Response() a la API Fetch, junto con otras mejoras:

función asíncrona 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 de criptografía web extendida

La API de Web Crypto se amplió para admitir el formato de clave web JSON (JWK) y importKey() ahora toma claves en formato JWK como entrada:

función asíncrona importSigningJWK(jwk) {    return await crypto.subtle.importKey('jwk', jwk,
                                            {nombre: "RSASSA-PKCS1-v1_5"},
                                                verdadero, ['signo']);
}

njs 0.7.10 también agregó los métodos generateKey() y exportKey() . El método generateKey() le permite generar una nueva clave para algoritmos simétricos o un par de claves para algoritmos de clave pública. El método exportKey() toma un objeto CryptoKey como entrada 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 detalles, consulte Web Crypto API .

Compatibilidad con documentos XML

El módulo XML se agregó en njs 0.7.10 para proporcionar soporte nativo para trabajar con documentos XML.

Análisis de documentos XML

Ahora puede analizar una cadena o un búfer para un documento XML, que luego 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.$texto) /* 'Tove' */
console.log(doc.note.to.$attr$b) /* 'bar' */
console.log(doc.note.$tags[1].$texto) /* 'Jani' */

API de XMLNode para modificar documentos XML

La API XMLNode se agregó 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');
eliminar 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))
/* '<nota><a>Tove</a><de>Jani2</de></nota>' */
   

  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></to>' */
   

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

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

Para obtener más detalles sobre todas las mejoras relacionadas con XML, consulte los documentos XML .

Soporte de compresión del módulo Zlib

El módulo zlib se agregó en njs 0.7.12 y proporciona funcionalidad de compresión utilizando los algoritmos de inflado y desinflado.

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

Para obtener más detalles sobre zlib, consulte los documentos de zlib .

Actualice o pruebe NGINX Plus

Si está utilizando NGINX Plus, le recomendamos encarecidamente que actualice a NGINX Plus R29 lo antes posible. Además de todas las nuevas y excelentes funciones, también obtendrá varias correcciones y mejoras adicionales, y estar actualizado ayudará a NGINX a ayudarlo si necesita generar un ticket de soporte.

Si aún no ha probado NGINX Plus, le recomendamos que lo haga por cuestiones de seguridad, equilibrio de carga y puerta de enlace de API, o como servidor web totalmente compatible con API de administración y monitoreo mejoradas. Comience hoy con una prueba gratuita de 30 días .