Anunciando o NGINX Plus R29

Prabhat Dixit

Michael Vernik

Temos o prazer de anunciar a disponibilidade do NGINX Plus Release 29 (R29). Baseado no NGINX Open Source, o NGINX Plus é o único software completo que reúne servidor web, 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– O Message Queuing Telemetry Transport (MQTT) é um protocolo leve usado para a comunicação entre dispositivos na Internet das Coisas (IoT). O NGINX Plus R29 oferece suporte ao protocolo MQTT com os módulos Preread e Filter, que introduzem várias novas diretivas e variáveis para ajudar a gerenciar e proteger o tráfego MQTT.
• Suporte a SAML para autenticação e autorização – Security Assertion Markup Language (SAML) é um protocolo consolidado que oferece logon único (SSO) para aplicações web. Agora, o NGINX Plus pode ser configurado como um provedor de serviços (SP) SAML para autenticar usuários por meio de um provedor de identidade (IdP) SAML.
• OpenTelemetry nativo – O OpenTelemetry (OTel) é uma estrutura que gera, coleta e exporta dados de telemetria (rastreamentos, métricas e logs) de fontes remotas de forma independente de fornecedor. O novo módulo dinâmico NGINX OTel oferece uma implementação de OTel de alto desempenho para o rastreamento de solicitações HTTP do NGINX Plus.
• Pacotes experimentais de QUIC+HTTP/3 – Os pacotes de prévia do NGINX Plus R29 com QUIC+HTTP/3 já estão disponíveis. Os pacotes QUIC do NGINX Plus R29 oferecem suporte ao HttpContext e a diversas novas diretivas para gerenciar conexões QUIC e tráfego HTTP/3.

Mudanças importantes de comportamento

Observação: se você estiver fazendo upgrade de uma versão diferente do NGINX Plus R28, consulte a seção Alterações importantes de comportamento nos blogs de anúncios anteriores de todas as versões entre a sua versão atual e esta.

Alterações no repositório de pacotes

O antigo repositório de pacotes plus-pkgs.nginx.com foi desativado imediatamente com o lançamento do NGINX Plus R29. Esse repositório não recebe atualizações desde o NGINX Plus R25, e é altamente recomendável usar o repositório de pacotes pkgs.nginx.com, que foi introduzido no NGINX Plus R24.

Alterações no suporte a plataformas

Novos sistemas operacionais compatíveis:

• Amazon Linux 2023

Sistemas operacionais mais antigos removidos:

• Alpine 3.13, que chegou ao fim da vida útil (EOL) em 1º de novembro de 2022

Sistemas operacionais mais antigos descontinuados e com remoção programada no NGINX Plus R30:

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

Adaptando-se ao anúncio do fim da vida útil do ModSecurity

Em conformidade com o anúncio de fim de vida útil do ModSecurity, o NGINX Plus R29 deixa de oferecer suporte aos pacotes do ModSecurity. Se você é cliente do NGINX Plus e usa pacotes do ModSecurity, em breve poderá optar por participar de um programa de troca entre o ModSecurity e o NGINX App Protect. Mais detalhes estarão disponíveis em breve. Para obter mais informações, entre em contato com seu representante da F5.

Novos recursos em detalhes

Suporte ao protocolo MQTT

O MQTT (Message Queuing Telemetry Transport) é um protocolo de mensagens leve e popular baseado no modelo de publicação e assinatura, ideal para conectar dispositivos e aplicações de IoT (clientes) pela internet. Ele permite que os clientes publiquem mensagens em um tópico específico e assinem outros tópicos. Os clientes inscritos recebem todas as mensagens publicadas nesse tópico, possibilitando uma troca de dados eficiente e tolerante a falhas entre diversos dispositivos e serviços.

No centro de uma arquitetura MQTT está um broker. Um broker é um servidor responsável por monitorar os clientes e os tópicos nos quais eles estão inscritos, processar mensagens e encaminhá-las aos sistemas apropriados. O NGINX Plus R29 oferece suporte a MQTT 3.1.1 e MQTT 5.0. Ele atua como um proxy entre clientes e brokers, o que simplifica a arquitetura do sistema, transfere tarefas e reduz custos.

O conjunto inicial de recursos do MQTT permite:

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

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

A análise e a reescrita de mensagens MQTT devem ser definidas no contexto Stream de um arquivo de configuração do NGINX e são possibilitadas pelos módulos ngx_stream_mqtt_preread_module
e 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 do dispositivo. Neste primeiro exemplo, o identificador é reescrito para usar o endereço IP do dispositivo.

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

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

Dada a natureza efêmera dos clientes MQTT, não é possível depender apenas do nome do host ou do endereço IP de um dispositivo para estabelecer sessões persistentes com brokers com balanceamento de carga. Neste exemplo, o identificador do cliente MQTT de um dispositivo funciona como uma chave de hash para manter as conexões com brokers MQTT individuais em um cluster com balanceamento 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 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 aprofundada da mensagem CONNECT para habilitar funções como:

• Mecanismos adicionais de autenticação e controle de acesso
• Proteção dos brokers por meio da limitação de taxa de clientes que geram tráfego excessivo
• Telemetria de mensagens e métricas de conexão

Adoraríamos receber seu feedback sobre os recursos que mais importam para você. Conte-nos o que você acha nos comentários.

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

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

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

Entre os principais motivos pelos quais empresas e instituições governamentais optam por adotar o SAML estão:

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

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

• Melhor experiência do usuário: Com a integração de SSO e um único ponto de verificação de autenticação no IdP, o SAML permite que os usuários façam uma única autenticação para acessar todos os serviços conectados. Isso melhora a experiência do usuário e economiza tempo, pois não é mais necessário lembrar várias credenciais para diferentes aplicações.
• Maior segurança: Dependendo das políticas de segurança e autenticação da sua organização, os usuários podem fazer login usando um esquema de autenticação SSO pela interface do SP (SSO iniciado pelo SP) ou diretamente pela interface do IdP (SSO iniciado pelo IdP). Isso reduz os riscos de segurança decorrentes de senhas potencialmente fracas e/ou repetidas.
• Redução dos custos administrativos: o SAML permite que as organizações transfiram as responsabilidades de gerenciamento de identidades para um IdP confiável, reduzindo assim o custo de manutenção das informações das contas e as despesas associadas.
• Protocolo padronizado: Projetado com base no princípio de tornar a segurança independente da lógica da aplicação (tanto quanto possível), o SAML é um protocolo padronizado compatível com quase todos os IdPs e sistemas de gerenciamento de acesso. Ele desvincula a estrutura de segurança das arquiteturas de plataforma e das implementações específicas de fornecedores, o que possibilita uma segurança robusta e uma integração confiável entre sistemas.

A implementação de referência atual do SAML usa SAML 2.0 e foi desenvolvida usando o framework NGINX JavaScript (njs). Nessa implementação, o NGINX Plus atua como um SP SAML, o que permite sua participação em 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, portanto, não é adequado para o NGINX Open Source sem modificações adicionais.

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

OpenTelemetry nativo

O OpenTelemetry (OTel) é uma tecnologia e um padrão que podem ser usados para monitorar, rastrear, solucionar problemas e otimizar aplicações. O OTel funciona coletando dados de telemetria de várias fontes, como proxies, aplicações ou outros serviços em uma pilha de aplicações implantada.

Como proxy reverso e balanceador de carga com reconhecimento de protocolo, o NGINX está em uma posição ideal para iniciar chamadas de telemetria a fim de rastrear solicitações e respostas de aplicações. Embora os módulos OTel de terceiros já estejam disponíveis há algum tempo, temos o prazer de anunciar o suporte nativo ao 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 oferece várias melhorias importantes em relação aos módulos de terceiros, incluindo:

• Melhor desempenho – A maioria das implementações do 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% a 15%.
• Provisionamento fácil – A coleta de telemetria pode ser instalada e configurada diretamente nos arquivos de configuração do NGINX.
• Amostragem totalmente dinâmica baseada em variáveis – A capacidade de rastrear uma sessão específica por cookie/token e controlar o módulo dinamicamente por meio da API do NGINX Plus e dos módulos de armazenamento de chave-valor.

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

Exemplos de rastreamento com OTel

Veja um exemplo de rastreamento básico com OTel de uma aplicação servida diretamente pelo 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;
      }
  }

Neste próximo exemplo, herdamos os contextos de rastreamento das solicitações recebidas e registramos spans somente se um span pai tiver sido amostrado. Também propagamos os contextos de rastreamento e as decisões de amostragem para os servidores upstream.

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

Neste exemplo baseado em proporção, o rastreamento é configurado para uma porcentagem do tráfego (neste caso, 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;
          }
      }
  }

Neste exemplo controlado por API, o rastreamento é habilitado por meio da manipulação do armazenamento de chave-valor pelo 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;
          } 
      }
  }

Pacotes experimentais de QUIC+HTTP/3

Após nosso anúncio dos pacotes binários de prévia para o NGINX Open Source, temos o prazer de anunciar pacotes QUIC experimentais para o NGINX Plus R29. Isso permite testar e avaliar o HTTP/3 com o NGINX Plus.

Com uma nova pilha de protocolos subjacente, o HTTP/3 leva UDP e QUIC à camada de transporte. O QUIC é um protocolo de transporte criptografado desenvolvido para aprimorar o TCP, oferecendo multiplexação de conexões e solucionando problemas como o bloqueio de início de fila. Ele reimplementa e aprimora diversos recursos do TCP presentes no HTTP/1.1 e no HTTP/2, incluindo o estabelecimento de conexões, o controle de congestionamento e a entrega confiável. O QUIC também incorpora o TLS como um componente integral, diferentemente do HTTP/1.1 e do HTTP/2, nos quais o TLS é uma camada separada. Isso significa que as mensagens HTTP/3 são inerentemente seguras, pois, por padrão, são enviadas por uma conexão criptografada.

Normalmente, para comunicação segura e funcionalidades criptográficas, o NGINX Plus utiliza o OpenSSL, aproveitando as bibliotecas SSL/TLS fornecidas com os sistemas operacionais. No entanto, como as interfaces TLS do QUIC não são compatíveis com o OpenSSL no momento da redação deste texto, são necessárias bibliotecas de terceiros para fornecer as funcionalidades TLS ausentes exigidas pelo HTTP/3.

Para resolver essa questão, desenvolvemos uma camada de compatibilidade com o OpenSSL para QUIC, eliminando a necessidade de compilar e distribuir bibliotecas TLS de terceiros, como quictls, BoringSSL e LibreSSL. Isso ajuda a gerenciar a experiência completa de QUIC+HTTP/3 no NGINX sem o ônus de uma implementação TLS personalizada nem a dependência de cronogramas e planos de desenvolvimento de bibliotecas de terceiros.

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

Exemplo de configuração de QUIC+HTTP/3

Vamos analisar um exemplo de configuração 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 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';
          }
      }
  }

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

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

Consulte Configuração do 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 breve, planejamos incorporar o código QUIC+HTTP/3 à ramificação principal do NGINX. A versão mais recente da ramificação principal do NGINX com suporte a QUIC+HTTP/3 será então incorporada a uma versão futura do NGINX Plus. Aguarde um anúncio sobre a disponibilidade oficial do suporte a 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, posteriormente, aprimorado de forma significativa nas versões seguintes. O NGINX Plus R29 continua aprimorando o OIDC com as seguintes adições.

Suporte a 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 o usuário se autentica e autoriza o acesso com sucesso e, em seguida, o armazena no armazenamento de chave-valor. O NGINX Plus pode transmitir esse token no cabeçalho HTTP Authorization como um token Bearer em 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 consegue saber se o token de acesso já expirou. Se a vida útil do token de acesso for menor que a do token de ID, você deverá usar a diretiva proxy_intercept_errors com o valor on. Isso interceptará e redirecionará as respostas 401 Unauthorized 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 aplicações existentes com OpenID Connect e NGINX Plus.

Argumentos adicionados ao endpoint de autenticação OIDC

Alguns provedores de identidade, como o Keycloak, permitem adicionar argumentos extras à string de consulta da solicitação de autenticação para habilitar recursos adicionais. Por exemplo, o Keycloak permite especificar um IdP padrão 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 endpoint de autorização OIDC.

Contadores SSL estendidos no módulo Prometheus-njs

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

Nova diretiva internal_redirect Directive

A nova diretiva e o módulo internal_redirect permitem redirecionamentos internos após a verificação dos limites de processamento de solicitações, dos limites de processamento de conexões e dos limites de acesso.

Veja um exemplo de configuração 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;
          }
      }
  }

No exemplo acima, a autenticação JWT é realizada no bloco location e, se o token for válido, a solicitação é encaminhada ao manipulador de conteúdo interno @rate_limited, onde é aplicado um limite de taxa de solicitações com base no valor da claim sub. Isso ocorre no JWT antes que a solicitação seja encaminhada ao serviço upstream.

Essa configuração específica evita um ataque de negação de serviço (DoS) no qual um invasor envia uma enxurrada de solicitações contendo JWTs legíveis, codificados com um usuário específico no campo sub. Essa enxurrada de solicitações não passaria pela autenticação, mas seria contabilizada no limite de taxa. Ao autenticar o JWT antes de encaminhar a solicitação ao manipulador de conteúdo, você garante que apenas solicitações válidas sejam contabilizadas no 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 (do NGINX 1.23.3 ao 1.23.4).

Alterações

• O protocolo TLSv1.3 agora está habilitado por padrão e é o valor padrão para estas diretivas:
• ssl_protocols (HTTP, Stream, E-mail)
• proxy_ssl_protocols (HTTP, Stream)
• grpc_ssl_protocols
• uwsgi_ssl_protocols
• zone_sync_ssl_protocols
• O NGINX agora emite um aviso se os parâmetros de protocolo de um soquete de escuta forem redefinidos.
• Agora, o NGINX encerra as conexões de forma prolongada caso o cliente tenha usado pipelining.
• O nível de registro dos erros 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 e got a fin before a ccs foi reduzido de crit para info.

Recursos

• Agora há suporte a intervalos de bytes no ngx_http_gzip_static_module.

Correções de bugs

• Corrigidos os intervalos de portas na diretiva listen que não funcionavam.
• Corrigida a possível seleção de um local incorreto para processar uma solicitação quando um local de prefixo com mais de 255 caracteres era usado na configuração.
• Corrigido o problema com caracteres não ASCII em nomes de arquivos no Windows, que não eram compatíveis com o módulo ngx_http_autoindex_module, o módulo ngx_http_dav_module e a diretiva include.
• Corrigido um vazamento de socket que às vezes ocorria ao usar HTTP/2 e a diretiva error_page para redirecionar erros com o código 400.
• Corrigidas as mensagens sobre erros ao registrar no syslog, que não informavam que os erros haviam ocorrido durante o registro no syslog.
• Corrigido o tratamento de eventos de leitura bloqueados do cliente no proxy -r.
• Corrigido um erro que às vezes ocorria ao ler o cabeçalho da versão 2 do protocolo PROXY com um grande número de TLVs.
• Corrigida uma falha de segmentação que às vezes ocorria em um processo de trabalho quando o SSI era usado para processar subsolicitações criadas por outros módulos.
• Corrigido um problema que poderia fazer o NGINX consumir excessivamente a CPU durante o proxy sem buffer quando eram usadas conexões SSL com os backends.

Soluções alternativas

• o filtro zip não conseguiu usar a memória pré-alocada alertas apareceram nos logs ao usar zlib-ng.
• Quando um nome de host usado na diretiva listen é resolvido para vários endereços, o NGINX agora ignora endereços duplicados entre eles.

Para ver 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 do 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 ampliado à API Fetch
• API Web Crypto estendida
• Suporte a documentos XML
• Análise de documentos XML
• API XMLNode para modificar documentos XML
• Suporte à compactação do módulo Zlib

Para obter uma lista completa de todos os recursos, alterações e correções de bugs da versão 0.7.9 à 0.7.12 do njs, consulte o registro de alterações do njs.

Suporte ampliado à API Fetch

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

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 estendida

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

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

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 oferece suporte ao formato JWK para exportar a chave como um objeto JSON.

Para mais detalhes, consulte a API Web Crypto.

Suporte a documentos XML

O módulo XML foi adicionado ao njs 0.7.10 para oferecer suporte nativo ao trabalho com documentos XML.

Análise de documentos XML

Agora, você pode analisar uma string ou um buffer como um documento XML, o que retorna um objeto wrapper XMLDoc que representa o documento XML analisado:

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

A API XMLNode foi adicionada ao 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 obter mais detalhes sobre todas as melhorias relacionadas a XML, consulte a documentação sobre XML.

Suporte à compactação do módulo Zlib

O módulo zlib foi adicionado no njs 0.7.12 e oferece recursos 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 a documentação do zlib.

Atualize ou experimente o NGINX Plus

Se você estiver usando o NGINX Plus, recomendamos enfaticamente que faça a atualização para o NGINX Plus R29 o mais rápido possível. Além de todos os excelentes novos recursos, você também receberá várias correções e melhorias adicionais. Manter-se em dia com as atualizações ajudará a NGINX a oferecer suporte caso você precise abrir um chamado.

Se você ainda não experimentou o NGINX Plus, recomendamos que faça um teste — seja para segurança, balanceamento de carga e gateway de API, seja como um servidor web com suporte completo e APIs avançadas de monitoramento e gerenciamento. Comece hoje mesmo com uma avaliação gratuita de 30 dias.

Sobre os autores

Prabhat Dixit

Mais publicações de Prabhat Dixit

Michael Vernik

Mais publicações de Michael Vernik