NGINX Plus R29リリースのお知らせ

NGINX | 2023年5月02日

NGINX Plus Release 29（R29）の提供開始をお知らせします。NGINX Open SourceをベースとするNGINX Plusは、Webサーバー、ロードバランサー、リバースプロキシ、コンテンツキャッシュ、APIゲートウェイを1つに統合した唯一のソフトウェアです。
NGINX Plus R29の新機能および強化された機能は次のとおりです。

MQTTプロトコルのサポート– Message Queuing Telemetry Transport（MQTT）は、モノのインターネット（IoT）におけるデバイス間通信に使用される軽量プロトコルです。NGINX Plus R29では、MQTTトラフィックの管理と保護に役立つ複数の新しいディレクティブと変数を導入したPrereadモジュールとFilterモジュールにより、MQTTプロトコルをサポートします。
認証および認可のSAMLサポート – Security Assertion Markup Language（SAML）は、Webアプリケーションにシングルサインオン（SSO）を提供する、広く確立されたプロトコルです。NGINX PlusをSAMLサービスプロバイダー（SP）として構成し、SAMLアイデンティティプロバイダー（IdP）を使用してユーザーを認証できるようになりました。
ネイティブOpenTelemetry – OpenTelemetry（OTel）は、リモートソースからテレメトリデータ（トレース、メトリクス、ログ）をベンダーに依存しない方法で生成、収集、エクスポートするフレームワークです。新しいNGINX OTel動的モジュールは、NGINX PlusのHTTPリクエストトレース向けに高性能なOTel実装を提供します。
試験的なQUIC+HTTP/3パッケージ – QUIC+HTTP/3に対応したNGINX Plus R29のプレビューパッケージが利用可能になりました。NGINX Plus R29 QUICパッケージは、HttpContextに加え、QUIC接続とHTTP/3トラフィックを管理するための各種の新しいディレクティブをサポートします。

動作に関する重要な変更

注記：NGINX Plus R28以外のリリースからアップグレードする場合は、現在のバージョンから本リリースまでのすべてのリリースについて、動作に関する重要な変更のセクションを過去のリリース告知ブログで必ず確認してください。

パッケージリポジトリの変更

旧パッケージリポジトリ「plus-pkgs.nginx.com」は、NGINX Plus R29のリリースに伴い、直ちに廃止されます。このリポジトリはNGINX Plus R25以降更新されていないため、pkgs.nginx.comパッケージリポジトリの使用を強く推奨します。このリポジトリはNGINX Plus R24で導入されました。

プラットフォームサポートの変更

新たにサポートされるオペレーティングシステム：

Amazon Linux 2023

削除された旧バージョンのオペレーティングシステム：

2022年11月1日にサポート終了（EOL）となったAlpine 3.13

非推奨となり、NGINX Plus R30で削除される予定の旧バージョンのオペレーティングシステム：

2023年6月にEOLを迎えるUbuntu 18.04
Alpine 3.14（2023年5月にEOLを迎えます）

ModSecurityのサポート終了発表への対応

「ModSecurityのEOL発表」に伴い、NGINX Plus R29ではModSecurityパッケージのサポートが終了します。ModSecurityパッケージをご利用のNGINX Plusのお客さまは、近日中にModSecurityからNGINX App Protectへの移行プログラムにお申し込みいただけるようになります。詳細は近日中に公開予定です。詳しくは、F5の担当者までお問い合わせください。

新機能の詳細

MQTTプロトコルのサポート

MQTT（Message Queuing Telemetry Transport）は、IoTデバイスやアプリケーション（クライアント）をインターネット経由で接続するのに適した、広く利用されている軽量なパブリッシュ／サブスクライブ型メッセージングプロトコルです。クライアントは、特定のトピックにメッセージをパブリッシュし、別のトピックをサブスクライブできます。サブスクライブしたクライアントは、そのトピックにパブリッシュされたすべてのメッセージを受信できるため、多数のデバイスやサービス間で効率的かつ耐障害性の高いデータ交換が可能になります。

MQTTアーキテクチャの中核となるのがブローカーです。ブローカーは、クライアントとそのサブスクライブ先のトピックを追跡し、メッセージを処理して適切なシステムにルーティングするサーバーです。NGINX Plus R29は、MQTT 3.1.1およびMQTT 5.0をサポートしています。クライアントとブローカーの間でプロキシとして機能することで、システムアーキテクチャを簡素化し、タスクをオフロードしてコストを削減します。

初期のMQTT機能セットでは、以下が可能です。

MQTTブローカーの負荷分散
セッション維持（再接続するクライアントを同じブローカーに接続）
TLS終端
クライアント証明書認証
CONNECTメッセージの解析と書き換え

MQTTプロトコルでは、CONNECT、PUBLISH、SUBSCRIBEなど、複数のメッセージタイプが定義されています。NGINX Plus R29では、MQTT CONNECTメッセージの一部を能動的に解析して書き換えられるため、これまでカスタムスクリプトでしか実現できなかった構成が可能になります。

MQTTメッセージの解析と書き換えは、NGINX設定ファイルのStreamコンテキストで定義する必要があり、ngx_stream_mqtt_preread_module
およびngx_stream_mqtt_filter_moduleモジュールによって実現されます。

MQTTの例

MQTTデバイスから送信されるデフォルトのクライアント識別子を変更することで、NGINXはデバイスのシリアル番号などの機密情報を隠すことができます。最初の例では、識別子をデバイスのIPアドレスに書き換えます。

注：本番環境では、デバイスのIPアドレスをMQTTクライアント識別子として使用することは推奨されません。

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

MQTTクライアントは一時的に接続される性質があるため、ロードバランシングされたブローカーへのスティッキーセッションを確立する際に、デバイスのホスト名やIPアドレスだけに依存することはできません。この例では、デバイスのMQTTクライアント識別子をハッシュキーとして使用し、ロードバランシングされたクラスター内の個々のMQTTブローカーへの接続を維持します。

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

次のステップ

NGINX PlusにおけるMQTTの今後の開発では、他のMQTTメッセージタイプの解析に加え、CONNECTメッセージをより詳細に解析し、次のような機能を実現する可能性があります。

追加の認証およびアクセス制御メカニズム
「通信量の多い」クライアントをレート制限し、ブローカーを保護
メッセージのテレメトリと接続メトリクス

皆さまが特に重視する機能について、ぜひご意見をお聞かせください。コメント欄でご感想をお寄せください。

認証と認可のためのSAMLサポート

SAML（Security Assertion Markup Language）は、アイデンティティプロバイダー（IdP）が、リソースへのアクセスを求めるユーザーを認証し（エンドユーザーが本人であることを確認し）、その認証情報と当該リソースに対するユーザーのアクセス権をサービスプロバイダー（SP）に渡して認可を行えるようにする、オープンなフェデレーション標準です。

IDデータを安全に交換する手段として長年にわたる実績を持つSAMLは、IdPとSPの間で認証情報と認可情報を交換するために広く採用されているプロトコルです。

企業や政府機関がSAMLを採用する主な理由は次のとおりです。

大量のIDを効率的に管理
顧客と従業員に対する、強化された一貫性のある統合型アイデンティティセキュリティ
アイデンティティ管理プロセスの標準化による業務効率の向上
規制要件への効率的な対応

SAMLには、ほかにもいくつかのメリットがあります。

ユーザーエクスペリエンスの向上：SSOとの統合とIdPでの一元的な認証検証により、SAMLでは1回の認証ですべての接続済みサービスにアクセスできます。さまざまなアプリケーションの複数の認証情報を覚える必要がなくなるため、ユーザーエクスペリエンスが向上し、時間を節約できます。
セキュリティの強化：組織のセキュリティおよび認証ポリシーに応じて、ユーザーはSSO認証方式を使用し、SPインターフェース（SP起点SSO）またはIdPインターフェース（IdP起点SSO）から直接ログインできます。これにより、脆弱なパスワードや使い回されたパスワードに起因するセキュリティリスクを軽減できます。
管理コストの削減: SAMLを使用すると、組織はID管理の責任を信頼できるIdPに移管できるため、アカウント情報の維持コストと関連費用を削減できます。
標準化されたプロトコル：SAMLは、セキュリティを可能な限りアプリケーションロジックから独立させるという原則に基づいて設計された標準プロトコルであり、ほぼすべてのIdPとアクセス管理システムでサポートされています。セキュリティフレームワークをプラットフォームアーキテクチャや特定ベンダーの実装から抽象化することで、堅牢なセキュリティとシステム間の信頼性の高い統合を実現します。

現在のSAMLリファレンス実装では、SAML 2.0を使用し、NGINX JavaScript（njs）フレームワークで構築されています。この実装では、NGINX PlusがSAML SPとして機能するため、SAML IdPを使用するSSO構成に参加できます。また、現在の実装は、NGINX Plusの既存機能であるキーバリューストアにも依存しているため、追加の変更を加えない限り、NGINX Open Sourceには適していません。

NGINX PlusのSAMLサポートは、リファレンス実装としてGitHubで提供されています。GitHubリポジトリには、インストール、設定、および特定のユースケースに応じた微調整の手順を含むサンプル設定が用意されています。

ネイティブOpenTelemetry

OpenTelemetry（OTel）は、アプリケーションの監視、トレース、トラブルシューティング、最適化に使用できるテクノロジーおよび標準です。OTelは、デプロイされたアプリケーションスタック内のプロキシ、アプリケーション、その他のサービスなど、さまざまなソースからテレメトリデータを収集します。

プロトコルを認識するリバースプロキシおよびロードバランサーであるNGINXは、アプリケーションのリクエストとレスポンスをトレースするためのテレメトリ呼び出しを開始するのに最適な位置にあります。サードパーティ製OTelモジュールは以前から提供されていましたが、このたびNGINX Plusで新しい動的モジュールによるOTelのネイティブサポートを提供開始します。

新しいモジュール「ngx_otel_module」は、インストールできます。インストールにはnginx-plus-module-otelパッケージを使用します。また、サードパーティ製モジュールと比べて、次のような重要な改善点があります。

パフォーマンスの向上 – 多くのOTel実装では、トレーシングを有効にするとリクエスト処理のパフォーマンスが最大50%低下します。新しいネイティブモジュールでは、この影響を約10～15%に抑えます。
容易なプロビジョニング – テレメトリ収集のセットアップと設定は、NGINX設定ファイル内で直接行えます。
完全に動的な変数ベースのサンプリング – Cookie／トークンを使用して特定のセッションをトレースし、NGINX Plus APIおよびKey-Valueストアモジュールを介してモジュールを動的に制御できます。

OTelダイナミックモジュールの詳細については、NGINXドキュメントをご覧ください。

OTelトレーシングの例

以下は、NGINXから直接配信されるアプリケーションに対する基本的なOTelトレーシングの例です。

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

次の例では、受信リクエストからトレースコンテキストを継承し、親スパンがサンプリングされている場合にのみスパンを記録します。また、トレースコンテキストとサンプリングの決定をアップストリームサーバーに伝播します。

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

この比率ベースの例では、トラフィックの一定割合（この場合は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;
          }
      }
  }

このAPI制御の例では、/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;
          } 
      }
  }

試験的なQUIC+HTTP/3パッケージ

先般の「NGINX Open Source向けプレビュー版バイナリパッケージの発表」に続き、NGINX Plus R29向けの試験的なQUICパッケージを発表いたします。これにより、NGINX PlusでHTTP/3をテストし、評価できるようになります。

HTTP/3では、新しい基盤プロトコルスタックにより、トランスポート層でUDPとQUICが使用されます。QUICは暗号化されたトランスポートプロトコルで、コネクションの多重化を実現し、ヘッドオブラインブロッキングなどの問題を解決することで、TCPを改善するよう設計されています。HTTP/1.1およびHTTP/2でTCPが担うコネクション確立、輻輳制御、信頼性の高い配信などの多くの機能を再実装し、強化しています。また、TLSを独立したレイヤーとして使用するHTTP/1.1やHTTP/2とは異なり、QUICではTLSが不可欠な構成要素として組み込まれています。そのため、HTTP/3メッセージはデフォルトで暗号化されたコネクションを介して送信され、本質的にセキュアです。

通常、NGINX Plusは、安全な通信と暗号化機能を実現するために、オペレーティングシステムに付属するSSL/TLSライブラリを利用して、OpenSSLに依存しています。ただし、本稿執筆時点ではOpenSSLがQUICのTLSインターフェースをサポートしていないため、HTTP/3に必要なTLS機能を補うには、サードパーティ製ライブラリが必要です。

この問題に対処するため、F5はQUIC向けのOpenSSL互換レイヤーを開発し、quictls、BoringSSL、LibreSSLなどのサードパーティ製TLSライブラリをビルドして提供する必要をなくしました。これにより、カスタムTLS実装の負担や、サードパーティ製ライブラリのスケジュールおよびロードマップへの依存を伴わずに、NGINXでエンドツーエンドのQUIC+HTTP/3エクスペリエンスを管理しやすくなります。

注記：OpenSSL Compatibility Layerは、試験提供のNGINX Plus QUIC+HTTP/3パッケージに含まれています。QUICプロトコルに必要なTLSv1.3を提供するには、OpenSSL 1.1.1以降が必要です。0-RTTはまだ実装されていません。

QUIC+HTTP/3のサンプル構成

NGINX PlusでのQUIC+HTTP/3の設定例を見てみましょう。

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

HTTP/2のF5による実装と同様に、NGINX Plusがプロキシとして動作する場合、クライアント側ではQUIC+HTTP/3接続が確立され、バックエンドおよびアップストリームサービスへの接続時にHTTP/1.1へ変換されます。

NGINX Plus QUIC+HTTP/3実験用パッケージは、既存のNGINX Plus証明書とキーを使用してアクセスできる別のリポジトリから入手できます。実験用QUICパッケージのインストール方法は、標準のNGINX Plusインストールと同様です。インストール手順で強調されているとおり、必ずQUICリポジトリを使用してください。

NGINXでQUIC+HTTP/3を構成する方法の詳細については、「Configuring NGINX for QUIC+HTTP/3」を参照してください。新しいディレクティブと変数の詳細については、nginx-quic READMEの「Configuration」セクションを参照してください。

次のステップ

近い将来、QUIC+HTTP/3コードをNGINXのメインラインブランチにマージする予定です。その後、QUIC+HTTP/3をサポートするNGINXメインラインの最新バージョンを、今後のNGINX Plusリリースに統合します。NGINX PlusにおけるQUIC+HTTP/3サポートの正式提供については、今年後半に発表する予定です。

NGINX Plus R29のその他の機能強化

OpenID Connectの変更点

OpenID Connect（OIDC）のサポートはNGINX Plus R15で導入され、その後のバージョンで大幅に強化されました。NGINX Plus R29でも、以下の機能追加によりOIDCが引き続き強化されています。

アクセストークンのサポート

アクセストークンは、トークンベース認証で使用され、OIDCクライアントがユーザーに代わって保護されたリソースにアクセスできるようにします。ユーザーの認証とアクセスの承認が正常に完了すると、NGINX Plusはアクセストークンを受け取り、Key-Valueストアに保存します。NGINX Plusは、ダウンストリームアプリケーションに送信されるすべてのリクエストについて、そのトークンをHTTP AuthorizationヘッダーでBearerトークンとして渡すことができます。

注記：NGINX Plusは、IDトークンの場合とは異なり、リクエストごとにアクセストークンの有効性を検証しないため、アクセストークンがすでに期限切れかどうかを判断できません。アクセストークンの有効期間がIDトークンより短い場合は、proxy_intercept_errors onディレクティブを使用する必要があります。これにより、401 UnauthorizedレスポンスがインターセプトされてNGINXにリダイレクトされ、アクセストークンが更新されます。

NGINX PlusによるOpenID ConnectおよびJSON Web Token（JWT）の検証について詳しくは、「OpenID ConnectとNGINX Plusを使用した既存アプリケーションのユーザー認証」をご覧ください。

OIDC認証エンドポイントに追加された引数

一部のアイデンティティプロバイダー（Keycloakなど）では、追加機能を有効にするため、認証リクエストにクエリ文字列引数を追加できます。たとえば、Keycloakでは、認証リクエストにkc_idp_hintパラメーターを追加することで、デフォルトのIdPを指定できます。この機能強化により、ユーザーはOIDC認可エンドポイントに追加の引数を指定できます。

Prometheus-njsモジュールの拡張SSLカウンター

NGINX Plus R28では、クライアント側接続とサーバー側接続の両方について、HTTPモジュールとStreamモジュールにおけるハンドシェイクエラーおよび証明書検証エラーを対象としたSSLカウンターの追加サポートを導入しました。NGINX PlusのメトリクスをPrometheus準拠の形式に変換するPrometheus-njsモジュールが、これらのカウンターに対応しました。

新しい「`internal_redirect`」ディレクティブ

新しいinternal_redirectディレクティブとモジュールでは、リクエスト処理の制限、接続処理の制限、およびアクセス制限を確認した後に、内部リダイレクトを実行できます。

以下は、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;
          }
      }
  }

上記の例では、locationブロックでJWT認証が実行され、トークンが有効な場合、リクエストは内部コンテンツハンドラー@rate_limitedに渡されます。そこで、subクレームの値に基づいてリクエストレート制限が適用されます。この処理は、リクエストがアップストリームサービスに渡される前にJWT内で行われます。

この構成では、攻撃者が特定のユーザーをsubフィールドに指定してエンコードした、読み取り可能なJWTを含む大量のリクエストを送信するサービス拒否（DoS）攻撃を防止します。これらの大量のリクエストは認証を通過しませんが、レート制限の対象としてカウントされる可能性があります。リクエストをコンテンツハンドラーに渡す前にJWTを認証することで、有効なリクエストのみがレート制限の対象としてカウントされるようにします。

NGINX Open Sourceから継承された変更

NGINX Plus R29はNGINX Open Source 1.23.4をベースとしており、NGINX Plus R28のリリース以降（NGINX 1.23.3～1.23.4）に行われた機能変更とバグ修正を継承しています。

変更点

The TLSv1.3プロトコルがデフォルトで有効になり、次のディレクティブのデフォルト値になりました：
ssl_protocols（HTTP、Stream、Mail）
proxy_ssl_protocols（HTTP、Stream）
grpc_ssl_protocols
uwsgi_ssl_protocols
zone_sync_ssl_protocols
リスニングソケットのプロトコルパラメーターが再定義された場合、NGINXは警告を出すようになりました。
クライアントがパイプライン処理を使用した場合、NGINXは接続を lingering close で終了するようになりました。
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、およびgot a fin before a ccsの各SSLエラーについて、ログレベルがcritからinfoに引き下げられました。

機能

Byte ranges are now supported in the ngx_http_gzip_static_moduleでバイト範囲がサポートされるようになりました。

バグ修正

listenディレクティブで機能していなかったポート範囲を修正しました。
構成で255文字を超えるプレフィックスロケーションを使用した場合に、リクエストの処理に誤ったロケーションが選択される可能性がある問題を修正しました。
Windows上のファイル名に含まれる非ASCII文字が、ngx_http_autoindex_module、ngx_http_dav_module、およびincludeディレクティブでサポートされていなかった問題を修正しました。
HTTP/2とerror_pageディレクティブを使用してコード400のエラーをリダイレクトした際に、ソケットリークが発生することがある問題を修正しました。
Fixed messages about logging to syslogへのログ記録中に発生したエラーであることが示されていなかったエラーメッセージを修正しました。syslog.
proxy -rでブロックされたクライアント読み取りイベントの処理を修正しました。
多数のTLVを含むPROXY protocol version 2ヘッダーの読み取り時に発生することがあったエラーを修正しました。
他のモジュールによって作成されたサブリクエストをSSIで処理した場合に、ワーカープロセスでセグメンテーションフォールトが発生することがある問題を修正しました。
バックエンドへのSSL接続を使用した場合、バッファリングなしのプロキシ処理中にNGINXがCPUを占有する可能性がある問題を修正しました。

回避策

zip filter failed to use pre-allocated memoryを使用すると、ログにアラートが表示されました：zlib-ng。
When a hostname used in the listenディレクティブで使用されるホスト名が複数のアドレスに解決される場合、NGINXは重複するアドレスを無視するようになりました。

これらのリリースから継承された新機能、変更、バグ修正、回避策の全一覧については、CHANGESファイルを参照してください。

NGINX JavaScript Moduleの変更点

NGINX Plus R29には、NGINX JavaScript（njs）モジュールのバージョン0.7.9～0.7.12で行われた変更が取り込まれています。njsには、次のような注目すべき機能が追加されました。

Fetch APIサポートの拡張
拡張Web Crypto API
XMLドキュメントのサポート
XMLドキュメントの解析
XMLドキュメントを変更するためのXMLNode API
Zlibモジュールの圧縮サポート

njsバージョン0.7.9～0.7.12のすべての機能、変更点、バグ修正の包括的な一覧については、njs Changes logを参照してください。

Fetch APIサポートの拡張

Headers()、Request()、およびResponse()の各コンストラクターが、その他の機能強化とともにFetch APIに追加されました。

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

拡張Web Crypto API

Web Crypto APIが拡張され、JSON Web Key（JWK）形式がサポートされるようになりました。また、importKey()はJWK形式の鍵を入力として受け取るようになりました。

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

njs 0.7.10では、generateKey()メソッドとexportKey()メソッドも追加されました。generateKey()メソッドを使用すると、対称アルゴリズム用の新しい鍵、または公開鍵アルゴリズム用の鍵ペアを生成できます。exportKey()メソッドは、CryptoKeyオブジェクトを入力として受け取り、外部で利用可能な移植性のある形式で鍵を返します。鍵をJSONオブジェクトとしてエクスポートするためのJWK形式をサポートしています。

詳細については、「Web Crypto API」を参照してください。

XMLドキュメントのサポート

XMLドキュメントをネイティブに扱えるようにするため、njs 0.7.10でXMLモジュールが追加されました。

XMLドキュメントの解析

文字列またはバッファをXMLドキュメントとして解析できるようになりました。解析すると、解析済みのXMLドキュメントを表すXMLDocラッパーオブジェクトが返されます。

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

XMLドキュメントを変更するためのXMLNode API

XMLドキュメントを変更するためのXMLNode APIがnjs 0.7.11で追加されました。

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

XML関連のすべての機能強化について詳しくは、XMLドキュメントを参照してください。

Zlibモジュールの圧縮サポート

zlibモジュールはnjs 0.7.12で追加され、deflateおよびinflateアルゴリズムを使用した圧縮機能を提供します。

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

zlibの詳細については、zlibドキュメントを参照してください。