Anunciando o NGINX Plus R29

Temos o prazer de anunciar a disponibilidade do NGINX Plus Release 29 (R29). Baseado no NGINX Open Source, o NGINX Plus é o único servidor web de software completo, balanceador de carga, proxy reverso, cache de conteúdo e gateway de API.
Os recursos novos e aprimorados do NGINX Plus R29 incluem:

• Suporte ao protocolo MQTT – Message Queuing Telemetry Transport (MQTT) é um protocolo leve usado para comunicação entre dispositivos na Internet das Coisas (IoT). O NGINX Plus R29 oferece suporte ao protocolo MQTT com módulos de pré-leitura e filtro que introduzem diversas novas diretivas e variáveis para ajudar a gerenciar e proteger o tráfego MQTT.

• Suporte SAML para autenticação e autorização – Security Assertion Markup Language (SAML) é um protocolo bem estabelecido que fornece logon único (SSO) para aplicativos da web. O NGINX Plus agora pode ser configurado como um provedor de serviços SAML (SP) para autenticar usuários em um provedor de identidade SAML (IdP).

• Native OpenTelemetry – OpenTelemetry (OTel) é uma estrutura que gera, coleta e exporta dados de telemetria (rastros, métricas e logs) de fontes remotas de forma independente do fornecedor. O novo módulo dinâmico NGINX OTel fornece uma implementação OTel de alto desempenho para rastreamento de solicitações HTTP do NGINX Plus.

• Pacotes experimentais QUIC+HTTP/3 – Pacotes de visualização do NGINX Plus R29 com QUIC+HTTP/3 já estão disponíveis. Os pacotes QUIC do NGINX Plus R29 fornecem suporte para HttpContext e uma variedade de novas diretivas para gerenciar conexões QUIC e tráfego HTTP/3.

Mudanças importantes no comportamento

Observação : Se você estiver atualizando de uma versão diferente do NGINX Plus R28, não deixe de conferir a seção Alterações importantes no comportamento em blogs de anúncios anteriores para todas as versões entre sua versão atual e esta.

Alterações no Repositório de Empacotamento

O antigo repositório de pacotes plus-pkgs.nginx.com será imediatamente desativado com o lançamento do NGINX Plus R29. Este repositório não foi atualizado desde o NGINX Plus R25 e é altamente recomendável que você use o repositório de pacotes pkgs.nginx.com que foi introduzido no NGINX Plus R24 .

Mudanças no suporte da plataforma

Novos sistemas operacionais suportados:

• Amazon Linux 2023

Sistemas operacionais mais antigos removidos:

• Alpine 3.13, que atingiu o fim de vida útil (EOL) em 1º de novembro de 2022

Sistemas operacionais mais antigos foram descontinuados e programados para remoção no NGINX Plus R30:

• Ubuntu 18.04, que chegará ao fim da vida útil em junho de 2023
• Alpine 3.14, que chegará ao fim de vida útil em maio de 2023

Adaptação ao anúncio de fim de vida do ModSecurity

Em linha com o anúncio de fim de vida útil do ModSecurity , o NGINX Plus R29 remove o suporte aos pacotes ModSecurity. Se você for um cliente NGINX Plus que usa pacotes ModSecurity, em breve poderá optar por um programa de troca entre o ModSecurity e o NGINX App Protect . Detalhes sobre isso estarão disponíveis em breve e você pode entrar em contato com seu contato na F5 para obter mais informações.

Novos recursos em detalhes

Suporte para Protocolo MQTT

MQTT (Message Queuing Telemetry Transport) é um protocolo de mensagens de publicação e assinatura popular e leve, ideal para conectar dispositivos e aplicativos de IoT (clientes) pela Internet. Ele permite que os clientes publiquem mensagens sobre um tópico específico e assinem outros tópicos. Os clientes inscritos recebem todas as mensagens publicadas naquele tópico, permitindo uma troca de dados eficiente e tolerante a falhas entre muitos dispositivos e serviços.

No coração de uma arquitetura MQTT está um corretor. Um broker é um servidor responsável por rastrear clientes e quaisquer tópicos nos quais eles estejam inscritos, processar mensagens e encaminhá-las para os sistemas apropriados. O NGINX Plus R29 suporta MQTT 3.1.1 e MQTT 5.0 . Ele atua como um proxy entre clientes e corretores, o que simplifica a arquitetura do sistema, alivia tarefas e reduz custos.

O conjunto inicial de recursos do MQTT permite:

• Balanceamento de carga do broker MQTT
• Persistência de sessão (reconectando clientes ao mesmo corretor)
• Término TLS
• Autenticação de certificado de cliente
• Análise e reescrita de mensagens CONNECT

O protocolo MQTT define vários tipos de mensagens, incluindo CONNECT, PUBLISH e SUBSCRIBE. O NGINX Plus R29 pode analisar e reescrever ativamente partes de mensagens MQTT CONNECT, permitindo cenários de configuração antes possíveis apenas com scripts personalizados.

A análise e reescrita de mensagens MQTT deve ser definida no contexto Stream de um arquivo de configuração NGINX e é possível com o ngx_stream_mqtt_preread_module
e módulos ngx_stream_mqtt_filter_module .

Exemplos de MQTT

Modificar o identificador de cliente padrão enviado por um dispositivo MQTT permite que o NGINX oculte informações confidenciais, como o número de série de um dispositivo. Neste primeiro exemplo, o identificador é reescrito no endereço IP do dispositivo.

Observação:  Não é recomendado usar o endereço IP de um dispositivo como identificador de cliente MQTT em um ambiente de produção.

fluxo { mqtt em;
 servidor { ouvir 1883; proxy_pass 10.0.0.8:1883; mqtt_set_connect clientid '$remote_addr'; } }

Dada a natureza efêmera dos clientes MQTT, você não pode simplesmente confiar no nome do host ou endereço IP de um dispositivo para estabelecer sessões persistentes para balancear a carga dos corretores. Neste exemplo, o identificador de cliente MQTT de um dispositivo atua como uma chave hash para persistir conexões com corretores MQTT individuais em um cluster com balanceamento de carga:

fluxo { mqtt_preread em;
 corretores upstream {zona tcp_mem 64k; hash $mqtt_preread_clientid consistente;
 servidor 10.0.0.7:1883; # corretor mqtt 1 servidor 10.0.0.8:1883; # corretor mqtt 2 servidor 10.0.0.9:1883; # corretor mqtt 3 }
 servidor { ouvir 1883; proxy_pass corretores; proxy_connect_timeout 1s; } }

PRÓXIMOS PASSOS

Desenvolvimentos futuros do MQTT no NGINX Plus podem incluir a análise de outros tipos de mensagens MQTT, bem como uma análise mais profunda da mensagem CONNECT para habilitar funções como:

• Mecanismos adicionais de autenticação e controle de acesso
• Protegendo corretores limitando a taxa de clientes “tagarelas”
• Telemetria de mensagens e métricas de conexão

Gostaríamos de ouvir sua opinião sobre os recursos mais importantes para você. Deixe-nos saber o que você pensa nos comentários.

Suporte SAML para autenticação e autorização

SAML (Security Assertion Markup Language) é um padrão de federação aberto que permite que um provedor de identidade (IdP) autentique usuários para acesso a um recurso (garantindo que o usuário final seja, de fato, quem ele afirma ser) e passe essas informações de autenticação, juntamente com os direitos de acesso do usuário naquele recurso, para um provedor de serviços (SP) para autorização.

Com um longo histórico de fornecimento de meios seguros para troca de dados de identidade, o SAML é um protocolo amplamente adotado para troca de informações de autenticação e autorização entre um IdP e um SP.

Os principais motivos pelos quais empresas e instituições governamentais optam por adotar o SAML incluem:

• Gestão eficaz de um grande volume de identidades
• Segurança de identidade aprimorada, consistente e unificada para clientes e funcionários
• Melhoria da eficiência operacional por meio da padronização dos processos de gerenciamento de identidade
• Tratamento eficiente de conformidades regulatórias

 
O SAML também oferece vários benefícios:

• Melhor experiência do usuário : Com sua integração SSO e verificação de ponto único de autenticação no IdP, o SAML permite que os usuários tenham uma autenticação que acessa todos os serviços conectados. Isso melhora a experiência do usuário e economiza tempo porque os usuários não precisam mais lembrar de várias credenciais para vários aplicativos.

• Segurança aumentada : Dependendo das políticas de segurança e autenticação da sua organização, os usuários podem efetuar login usando um esquema de autenticação SSO na interface SP (SSO iniciado pelo SP) ou diretamente na interface IdP (SSO iniciado pelo IdP). Isso reduz os riscos de segurança devido a senhas potencialmente fracas e/ou repetidas.

• Custos administrativos reduzidos : O SAML ajuda as organizações a transferir as responsabilidades de gerenciamento de identidade para um IdP confiável, reduzindo assim o custo de manutenção de informações de conta e as despesas associadas.

• Protocolo Padronizado : Projetado com o princípio de tornar a segurança independente da lógica do aplicativo (tanto quanto possível), o SAML é um protocolo padronizado que é suportado por quase todos os IdPs e sistemas de gerenciamento de acesso. Ele abstrai a estrutura de segurança das arquiteturas de plataforma e implementações específicas de fornecedores, o que permite segurança robusta e integração confiável entre sistemas.

A implementação de referência atual do SAML usa o SAML 2.0 e é criada usando a estrutura NGINX JavaScript (njs). Nesta implementação, o NGINX Plus atua como um SP SAML, permitindo que ele participe de uma configuração de SSO com um IdP SAML. A implementação atual também depende do armazenamento de chave-valor , que é um recurso existente do NGINX Plus e, como tal, não é adequado para o NGINX Open Source sem modificações adicionais.

O suporte SAML no NGINX Plus está disponível como uma implementação de referência no GitHub. O repositório do GitHub inclui uma configuração de exemplo com instruções sobre instalação, configuração e ajuste fino para casos de uso específicos.

OpenTelemetry nativo

OpenTelemetry (OTel) é uma tecnologia e padrão que pode ser usado para monitorar, rastrear, solucionar problemas e otimizar aplicativos. O OTel funciona coletando dados de telemetria de várias fontes, como proxies, aplicativos ou outros serviços em uma pilha de aplicativos implantados.

Como um proxy reverso e balanceador de carga com reconhecimento de protocolo, o NGINX está idealmente posicionado para iniciar chamadas de telemetria para rastrear solicitações e respostas de aplicativos. Embora os módulos OTel de terceiros estejam disponíveis há algum tempo, temos o prazer de anunciar o suporte nativo para OTel no NGINX Plus com um novo módulo dinâmico .

O novo módulo ngx_otel_module pode ser instalado usando o pacote nginx-plus-module-otel e fornece diversas melhorias importantes para módulos de terceiros, incluindo:

• Melhor desempenho – A maioria das implementações OTel reduz o desempenho do processamento de solicitações em até 50% quando o rastreamento está habilitado. Nosso novo módulo nativo limita esse impacto a cerca de 10-15%.
• Provisionamento fácil – A configuração e a configuração da coleta de telemetria podem ser feitas diretamente nos arquivos de configuração do NGINX.
• Amostragem baseada em variáveis totalmente dinâmicas – A capacidade de rastrear uma sessão específica por cookie/token e controlar o módulo dinamicamente por meio da API NGINX Plus e dos módulos de armazenamento de chave-valor .

Mais detalhes sobre o módulo dinâmico OTel estão disponíveis na documentação do NGINX .

Exemplos de rastreamento OTel

Aqui está um exemplo de rastreamento OTel básico de um aplicativo atendido diretamente pelo NGINX:

load_module módulos/ngx_otel_module.so;
 eventos {}
 http { otel_exporter { ponto final localhost:4317; }
 servidor { ouvir 127.0.0.1:8080;
 otel_trace ativado;        otel_span_name app1;    } }

No próximo exemplo, herdamos contextos de rastreamento de solicitações recebidas e registramos intervalos somente se um intervalo pai for amostrado. Também propagamos contextos de rastreamento e decisões de amostragem para servidores upstream.

load_module módulos/ngx_otel_module.so;
 http { servidor { localização / { otel_trace $otel_parent_sampled; otel_trace_context propagar; proxy_pass http://backend; } } }

Neste exemplo baseado em proporção, o rastreamento é configurado para uma porcentagem de tráfego (neste caso, 10%):

http { # rastrear 10% das solicitações split_clients "$otel_trace_id" $ratio_sampler { 10% ativado; * desativado; }
 # ou podemos rastrear 10% das sessões do usuário
 split_clients "$cookie_sessionid" $session_sampler { 10% ativado; * desativado; }
 servidor { localização / { otel_trace $ratio_sampler; otel_trace_context inject;
 proxy_pass http://backend; } } }

Neste exemplo controlado por API, o rastreamento é habilitado pela manipulação do armazenamento de chave-valor por meio do ponto de extremidade /api:

http { keyval "otel.trace" $trace_switch zona=nome;
 servidor { localização / { otel_trace $trace_switch; otel_trace_context inject; proxy_pass http://backend; }
 localização /api { api write=on; } } }

Pacotes experimentais QUIC+HTTP/3

Após nosso anúncio de pacotes binários de pré-visualização para o NGINX Open Source , temos o prazer de anunciar pacotes QUIC experimentais para o NGINX Plus R29. Isso torna possível testar e avaliar o HTTP/3 com o NGINX Plus.

Com uma nova pilha de protocolos subjacente, o HTTP/3 traz UDP e QUIC para a camada de transporte. QUIC é um protocolo de transporte criptografado projetado para melhorar o TCP ao fornecer multiplexação de conexão e resolver problemas como bloqueio de cabeçalho de linha. Ele reimplementa e aprimora uma série de recursos TCP do HTTP/1.1 e HTTP/2, incluindo estabelecimento de conexão, controle de congestionamento e entrega confiável. O QUIC também incorpora o TLS como um componente integral, diferentemente do HTTP/1.1 e do HTTP/2, que têm o TLS como uma camada separada. Isso significa que as mensagens HTTP/3 são inerentemente seguras, pois são enviadas por meio de uma conexão criptografada por padrão.

Normalmente, para comunicação segura e funcionalidade criptográfica, o NGINX Plus depende do OpenSSL , fazendo uso das bibliotecas SSL/TLS fornecidas com os sistemas operacionais. Entretanto, como as interfaces TLS do QUIC não são suportadas pelo OpenSSL no momento em que este artigo foi escrito, bibliotecas de terceiros são necessárias para fornecer a funcionalidade TLS ausente exigida pelo HTTP/3.

Para resolver essa preocupação, desenvolvemos uma Camada de Compatibilidade OpenSSL para QUIC, eliminando a necessidade de criar e enviar bibliotecas TLS de terceiros, como quictls, BoringSSL e LibreSSL. Isso ajuda a gerenciar a experiência QUIC+HTTP/3 de ponta a ponta no NGINX sem o fardo de uma implementação TLS personalizada nem a dependência de cronogramas e roteiros de bibliotecas de terceiros.

Observação : A Camada de Compatibilidade OpenSSL está incluída nos pacotes experimentais NGINX Plus QUIC+HTTP/3 e requer OpenSSL 1.1.1 ou superior para fornecer TLSv1.3 (que é exigido pelo protocolo QUIC). Ainda não implementa o 0-RTT.

Configuração de exemplo QUIC+HTTP/3

Vejamos uma configuração de exemplo de QUIC+HTTP/3 no 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 rápido;
 servidor { # para melhor compatibilidade é recomendado # usar a mesma porta para quic e https listen 8443 quic reuseport; listen 8443 ssl;
 certificado_ssl certs/exemplo.com.crt; chave_certificado_ssl certs/exemplo.com.chave;
 localização / { # necessário para que os navegadores os direcionem para a porta rápida add_header Alt-Svc 'h3=":8443"; ma=86400'; } } }

Semelhante à nossa implementação do HTTP/2 , quando o NGINX Plus atua como um proxy, as conexões QUIC+HTTP/3 são feitas no lado do cliente e convertidas para HTTP/1.1 ao conectar-se a serviços de backend e upstream.

Os pacotes experimentais NGINX Plus QUIC+HTTP/3 estão disponíveis em um repositório separado, acessível com certificados e chaves NGINX Plus existentes. A instalação dos pacotes QUIC experimentais é semelhante a uma instalação padrão do NGINX Plus . Certifique-se de usar o repositório QUIC, conforme destacado nas etapas de instalação.

Você pode consultar Configurando o NGINX para QUIC+HTTP/3 para obter mais informações sobre como configurar o NGINX para QUIC+HTTP/3. Para obter informações sobre todas as novas diretivas e variáveis, consulte a seção Configuração do README do nginx-quic .

PRÓXIMOS PASSOS

Em um futuro próximo, planejamos mesclar o código QUIC+HTTP/3 na ramificação principal do NGINX. A versão mais recente do NGINX mainline com suporte a QUIC+HTTP/3 será então mesclada em uma versão posterior do NGINX Plus. Aguarde um anúncio sobre a disponibilidade oficial do suporte QUIC+HTTP/3 no NGINX Plus ainda este ano.

Outras melhorias no NGINX Plus R29

Alterações no OpenID Connect

O suporte ao OpenID Connect (OIDC) foi introduzido no NGINX Plus R15 e significativamente aprimorado nas versões subsequentes. O NGINX Plus R29 continua aprimorando o OIDC, com as seguintes adições.

Suporte para tokens de acesso

Tokens de acesso são usados na autenticação baseada em tokens para permitir que um cliente OIDC acesse um recurso protegido em nome do usuário. O NGINX Plus recebe um token de acesso depois que um usuário autentica e autoriza o acesso com sucesso e, em seguida, o armazena no repositório de chave-valor. O NGINX Plus pode passar esse token no cabeçalho de autorização HTTP como um Bearer Token para cada solicitação enviada ao aplicativo downstream.

Observação : O NGINX Plus não verifica a validade do token de acesso em cada solicitação (como faz com o token de ID) e não pode saber se o token de acesso já expirou. Se o tempo de vida do token de acesso for menor que o do token de ID, você deverá usar a diretiva proxy_intercept_errors on. Isso interceptará e redirecionará respostas 401 não autorizadas para o NGINX e atualizará o token de acesso.

Para obter mais informações sobre a validação do OpenID Connect e do JSON Web Token (JWT) com o NGINX Plus, consulte Autenticação de usuários em aplicativos existentes com o OpenID Connect e o NGINX Plus .

Argumentos adicionados no ponto de extremidade de autenticação OIDC

Alguns provedores de identidade, como o Keycloak , permitem adicionar argumentos extras de string de consulta à solicitação de autenticação para habilitar recursos adicionais. Por exemplo, o Keycloak permite que um IdP padrão seja especificado adicionando um parâmetro kc_idp_hint à solicitação de autenticação. Como parte desse aprimoramento, o usuário pode especificar argumentos adicionais para o ponto de extremidade de autorização do OIDC.

Contadores SSL estendidos no módulo Prometheus-njs

No NGINX Plus R28, adicionamos suporte adicional ao contador SSL para erros de handshake e falhas de validação de certificado nos módulos HTTP e Stream para conexões do lado do cliente e do lado do servidor. Nosso módulo Prometheus-njs , que converte métricas do NGINX Plus para um formato compatível com o Prometheus, agora oferece suporte a esses contadores.

Nova diretiva internal_redirect

A nova diretiva e módulo internal_redirect permitem redirecionamentos internos após verificar os limites de processamento de solicitações , limites de processamento de conexões e limites de acesso .

Aqui está um exemplo de configuração internal_redirect :

http { limit_req_zone $jwt_claim_sub zona=jwt_sub:10m taxa=1r/s;
 servidor { localização / { auth_jwt "reino"; auth_jwt_key_file key.jwk;
 redirecionamento_interno @taxa_limitada; }
 localização @rate_limited { interno; limite_req zona=jwt_sub burst=10;
 proxy_pass http://backend ; } } }

No exemplo acima, a autenticação JWT é realizada no bloco de localização e – se o token for válido – a solicitação é passada para o manipulador de conteúdo interno @rate_limited, onde um limite de taxa de solicitação é aplicado com base no valor da subdeclaração. Isso acontece no JWT antes que a solicitação seja passada para o serviço upstream.

Essa configuração específica evita um ataque de negação de serviço (DoS), em que um invasor envia uma enxurrada de solicitações contendo JWTs legíveis, codificados com um usuário específico como subcampo. Essa enxurrada de solicitações não passará na autenticação, mas contará para o limite de taxa. Ao autenticar o JWT antes de passar a solicitação ao manipulador de conteúdo, você garante que somente solicitações válidas sejam contabilizadas para o limite de taxa.

Alterações herdadas do NGINX Open Source

O NGINX Plus R29 é baseado no NGINX Open Source 1.23.4 e herda alterações funcionais e correções de bugs feitas desde o lançamento do NGINX Plus R28 (no NGINX 1.23.3 a 1.23.4).

Mudanças

• O protocolo TLSv1.3 agora está habilitado por padrão e é o valor padrão para estas diretivas:
• protocolos ssl ( HTTP , fluxo , correio )
• proxy_ssl_protocols ( HTTP , Fluxo )
• protocolos grpc_ssl
• protocolos uwsgi_ssl
• protocolos_ssl_de_sincronização_de_zona
• O NGINX agora emite um aviso se os parâmetros de protocolo de um soquete de escuta forem redefinidos.
• O NGINX agora fecha conexões com persistência se o pipeline foi usado pelo cliente.
• O nível de registro de comprimento de dados é muito longo, comprimento muito curto, versão legada incorreta, nenhum algoritmo de assinatura compartilhada, comprimento de resumo incorreto, extensão sigalgs ausente, comprimento criptografado muito longo, comprimento incorreto, atualização de chave incorreta, dados de handshake mistos e não handshake, ccs recebidos antecipadamente, dados entre ccs e finalizados, comprimento do pacote muito longo, muitos alertas de aviso, registro muito pequeno e recebeu uma multa antes de um ccs. Os erros de SSL foram reduzidos de crítico para informativo.

Recursos

• Intervalos de bytes agora são suportados no ngx_http_gzip_static_module .

Correções de bugs

• Intervalos de portas corrigidos na diretiva listen que não funcionavam.
• Corrigiu um local incorreto que poderia ser escolhido para processar uma solicitação se um local de prefixo com mais de 255 caracteres fosse usado na configuração.
• Corrigidos caracteres não ASCII em nomes de arquivos no Windows, que não eram suportados por ngx_http_autoindex_module , ngx_http_dav_module e pela diretiva include.
• Corrigiu um vazamento de soquete que às vezes ocorria ao usar HTTP/2 e a diretiva error_page para redirecionar erros com código400 .
• Mensagens corrigidas sobre erros de registro no syslog , que não continham informações de que os erros ocorreram durante o registro no syslog .
• Tratamento corrigido de eventos de leitura de cliente bloqueados no proxy -r.
• Corrigiu um erro que às vezes ocorria ao ler o cabeçalho do protocolo PROXY versão 2 com grande número de TLVs.
• Corrigiu uma falha de segmentação que às vezes ocorria em um processo de trabalho se o SSI fosse usado para processar sub-solicitações criadas por outros módulos.
• Corrigido o NGINX potencialmente monopolizando a CPU durante proxy sem buffer se conexões SSL com backends fossem usadas.

Soluções alternativas

• O filtro zip falhou ao usar alertas de memória pré-alocada que apareceram nos logs ao usar o zlib-ng .
• Quando um nome de host usado na diretiva listen é resolvido para vários endereços, o NGINX agora ignora duplicatas dentro desses endereços.

Para obter a lista completa de novos recursos, alterações, correções de bugs e soluções alternativas herdadas dessas versões, consulte o arquivo CHANGES .

Alterações no módulo JavaScript NGINX

O NGINX Plus R29 incorpora alterações das versões 0.7.9 a 0.7.12 do módulo NGINX JavaScript (njs). Vários recursos interessantes foram adicionados ao njs, incluindo:

• Suporte estendido à API de busca
• API de criptografia da Web estendida
• Suporte a documentos XML
• Análise de documentos XML
• API XMLNode para modificar documentos XML
• Suporte de compressão do módulo Zlib

Para uma lista abrangente de todos os recursos, alterações e correções de bugs da versão 0.7.9 a 0.7.12 do njs, consulte o log de alterações do njs .

Suporte estendido à API de busca

Os construtores Headers() , Request() e Response() são adicionados à API Fetch, junto com outras melhorias:

função assíncrona makeRequest(uri, cabeçalhos) {     deixe h = novo Cabeçalhos(cabeçalhos);
    h.delete("bar");
    h.append("foo", "xxx");
    deixe r = novo Pedido(uri, {cabeçalhos: h});
    retorne aguarde ngx.fetch(r);
}

API de criptografia da Web estendida

A API Web Crypto foi estendida para oferecer suporte ao formato JSON Web Key (JWK) e o importKey() agora aceita chaves no formato JWK como entrada:

função assíncrona importSigningJWK(jwk) {    return await crypto.subtle.importKey('jwk', jwk,
                                            {nome: "RSASSA-PKCS1-v1_5"},
                                             verdadeiro, ['sinal']);
}

O njs 0.7.10 também adicionou os métodos generateKey() e exportKey() . O método generateKey() permite gerar uma nova chave para algoritmos simétricos ou um par de chaves para algoritmos de chave pública. O método exportKey() recebe um objeto CryptoKey como entrada e retorna a chave em um formato externo e portátil. Ele suporta o formato JWK para exportar a chave como um objeto JSON.

Para mais detalhes, consulte Web Crypto API .

Suporte a documentos XML

O módulo XML foi adicionado no njs 0.7.10 para fornecer suporte nativo para trabalhar com documentos XML.

Análise de documentos XML

Agora você pode analisar uma string ou buffer para um documento XML, que então retorna um objeto wrapper XMLDoc representando o documento XML analisado:

const xml = require("xml"); deixe dados = `<note><para b="bar" a= "foo">Tove</para><de>Jani</de></note>`;
deixe doc = xml.parse(dados);
   

  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

A API XMLNode foi adicionada no njs 0.7.11 para modificar documentos XML:

Const xml = require("xml"); deixe dados = `<note><para b="bar" a="foo">Tove</para><de>Jani</de></note>`;
deixe doc = xml.parse(dados);
   

  doc.$root.to.$attr$b = 'bar2';
doc.$root.to.setAttribute('c', 'baz');
excluir doc.$root.to.$attr$a;
   

  console.log(xml.serializeToString(doc.$root.to))
/* '<para b="bar2" c="baz">Tove</para>' */
   

  doc.$root.to.removeAllAttributes();
doc.$root.from.$text = 'Jani2';
   

  console.log(xml.serializeToString(doc))
/* '<nota><para>Tove</para><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))
/* '<para><a></a><b></b><a></a></to>' */
   

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

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

Para mais detalhes sobre todos os aprimoramentos relacionados ao XML, consulte os documentos XML .

Suporte de compressão do módulo Zlib

O módulo zlib foi adicionado no njs 0.7.12 e fornece funcionalidade de compactação usando os algoritmos deflate e inflate.

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

Para mais detalhes sobre o zlib, consulte os documentos do zlib .

Atualize ou experimente o NGINX Plus

Se você estiver executando o NGINX Plus, recomendamos fortemente que atualize para o NGINX Plus R29 o mais rápido possível. Além de todos os excelentes novos recursos, você também obterá diversas correções e melhorias adicionais, e estar atualizado ajudará o NGINX a ajudá-lo caso precise abrir um tíquete de suporte.

Se você ainda não experimentou o NGINX Plus, recomendamos que experimente – para segurança, balanceamento de carga e gateway de API, ou como um servidor web totalmente suportado com APIs aprimoradas de monitoramento e gerenciamento. Comece hoje mesmo com um teste gratuito de 30 dias .