ブログ | NGINX

NGINX Plus R29 の発表

NGINX-F5 水平黒タイプ RGB の一部
プラバート・ディクシット サムネイル
プラバート・ディクシット
2023年5月2日公開
マイケル・バーニク サムネイル
マイケル・バーニック
2023年5月2日公開

NGINX Plus リリース 29 (R29) が利用可能になったことをお知らせいたします。 NGINX オープンソースをベースにした NGINX Plus は、唯一のオールインワン ソフトウェア Web サーバー、ロード バランサー、リバース プロキシ、コンテンツ キャッシュ、API ゲートウェイです。
NGINX Plus R29 の新機能と強化された機能は次のとおりです。

  • MQTT プロトコルのサポート- Message Queuing Telemetry Transport (MQTT) は、モノのインターネット (IoT) 内のデバイス間の通信に使用される軽量プロトコルです。 NGINX Plus R29 は、MQTT トラフィックの管理とセキュリティ保護に役立つ複数の新しいディレクティブと変数を導入するPrereadおよびFilterモジュールを備えた MQTT プロトコルをサポートします。
  • 認証と承認のための SAML サポート- セキュリティ アサーション マークアップ言語 (SAML) は、Web アプリケーションにシングル サインオン (SSO) を提供する確立されたプロトコルです。 NGINX Plus を SAML サービス プロバイダー (SP) として構成し、SAML ID プロバイダー (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 以降更新されていないため、 NGINX Plus R24 で導入されたpkgs.nginx.comパッケージ リポジトリを使用することを強くお勧めします。

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

サポートされる新しいオペレーティング システム:

  • アマゾンリナックス2023

削除された古いオペレーティング システム:

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

NGINX Plus R30 で非推奨となり削除が予定されている古いオペレーティング システム:

  • Ubuntu 18.04は2023年6月にEOLを迎える予定
  • 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構成ファイルのストリームコンテキストで定義する必要があり、 ngx_stream_mqtt_preread_moduleで可能になります。
およびngx_stream_mqtt_filter_moduleモジュール。

MQTTの例

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

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

ストリーム { mqtt オン;
サーバー { listen 1883; proxy_pass 10.0.0.8:1883; mqtt_set_connect clientid '$remote_addr'; } }

MQTT クライアントの一時的な性質を考えると、負荷分散されたブローカーへのスティッキー セッションを確立するためにデバイスのホスト名または IP アドレスに単純に依存することはできません。 この例では、デバイスの MQTT クライアント識別子は、負荷分散されたクラスター内の個々の MQTT ブローカーへの接続を維持するためのハッシュ キーとして機能します。 

ストリーム { mqtt_preread オン;
アップストリームブローカー{ゾーン tcp_mem 64k; ハッシュ $mqtt_preread_clientid 一貫性あり;
サーバー 10.0.0.7:1883; # MQTT ブローカー 1 サーバー 10.0.0.8:1883; # MQTT ブローカー 2 サーバー 10.0.0.9:1883; # MQTT ブローカー 3 }
サーバー { listen 1883; proxy_pass ブローカー; proxy_connect_timeout 1s; } }

次のステップ

NGINX Plus の MQTT の今後の開発には、他の MQTT メッセージ タイプの解析や、次のような機能を実現するための CONNECT メッセージのより深い解析が含まれる可能性があります。

  • 追加の認証およびアクセス制御メカニズム
  • 「おしゃべりな」クライアントのレート制限によるブローカーの保護
  • メッセージテレメトリと接続メトリック

お客様にとって最も重要な機能についてのフィードバックをお待ちしております。 コメント欄であなたの考えをお聞かせください。

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

SAML (Security Assertion Markup Language) は、アイデンティティ プロバイダー (IdP) がリソースへのアクセスについてユーザーを認証し (エンド ユーザーが実際に本人であることを確認)、その認証情報とそのリソースに対するユーザーのアクセス権をサービス プロバイダー (SP) に渡して承認を受けられるようにするオープン フェデレーション標準です。

SAML は、ID データを交換するための安全な手段を提供してきた長い実績があり、IdP と SP 間で認証および承認情報を交換するために広く採用されているプロトコルです。

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

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

 
SAML には、次のようないくつかの利点もあります。

  • より良いユーザーエクスペリエンス: SAML は、SSO 統合と IdP での単一認証検証ポイントを備えており、ユーザーは 1 つの認証で接続されているすべてのサービスにアクセスできます。 これにより、ユーザーはさまざまなアプリケーションの複数の資格情報を覚えておく必要がなくなるため、ユーザー エクスペリエンスが向上し、時間が節約されます。
  • セキュリティの強化: 組織のセキュリティおよび認証ポリシーに応じて、ユーザーは SP インターフェイス (SP 開始 SSO) または IdP インターフェイス (IdP 開始 SSO) で直接 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 構成ファイル内で直接行うことができます。
  • 完全に動的な変数ベースのサンプリング– クッキー/トークンによって特定のセッションをトレースし、 NGINX Plus APIおよびキー値ストアモジュールを介してモジュールを動的に制御します。

OTel 動的モジュールの詳細については、 NGINX ドキュメントを参照してください。

OTel トレースの例

以下は、NGINX によって直接提供されるアプリケーションの基本的な OTel トレースの例です。

モジュールモジュール/ngx_otel_module.soをロードします。
イベント {}
 http { otel_exporter { エンドポイント localhost:4317; }
サーバー{ listen 127.0.0.1:8080;
 otel_trace オン;        otel_span_name app1;    } }

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

モジュールモジュール/ngx_otel_module.soをロードします。
 http { server { location / { otel_trace $otel_parent_sampled; otel_trace_context propagate; proxy_pass http://backend; } } }

この比率ベースの例では、トレースはトラフィックのパーセンテージ (この場合は 10%) に対して構成されています。

http { # リクエストの10%をトレースする split_clients "$otel_trace_id" $ratio_sampler { 10% on; * off; }
 # または、ユーザーセッションの10%を追跡できます
split_clients "$cookie_sessionid" $session_sampler { 10% オン; * オフ; }
サーバー { 場所 / { otel_trace $ratio_sampler; otel_trace_context inject;
 proxy_pass http://backend; } } }

この API 制御の例では、/api エンドポイントを介してキー値ストアを操作することでトレースが有効になります。

http { keyval "otel.trace" $trace_switch ゾーン=名前;
サーバー { 場所 / { otel_trace $trace_switch; otel_trace_context inject; proxy_pass http://backend; }
場所 /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 機能を再実装および強化します。 QUIC は、TLS を別個のレイヤーとして持つ HTTP/1.1 および HTTP/2 とは異なり、TLS を不可欠なコンポーネントとして組み込んでいます。 つまり、HTTP/3 メッセージはデフォルトで暗号化された接続を介して送信されるため、本質的に安全です。

通常、安全な通信と暗号化機能のために、NGINX Plus はOpenSSLに依存し、オペレーティング システムに付属の SSL/TLS ライブラリを使用します。 ただし、この記事の執筆時点では QUIC の TLS インターフェースは OpenSSL でサポートされていないため、HTTP/3 に必要な TLS 機能が不足している場合は、サードパーティのライブラリが必要になります。

この懸念に対処するために、QUIC 用の OpenSSL 互換性レイヤーを開発し、quictls、BoringSSL、LibreSSL などのサードパーティの TLS ライブラリを構築して出荷する必要がなくなりました。 これにより、カスタム TLS 実装の負担やサードパーティ ライブラリのスケジュールやロードマップへの依存なしに、NGINX でエンドツーエンドの QUIC+HTTP/3 エクスペリエンスを管理できるようになります。

注記： OpenSSL 互換性レイヤーは、実験的な NGINX Plus QUIC+HTTP/3 パッケージに含まれており、 TLSv1.3 (QUIC プロトコルで必要) を提供するには 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 ログ/access.log quic;
 server { # 互換性を高めるために、quic と https に同じポートを使用することをお勧めします listen 8443 quic reuseport; listen 8443 ssl;
 ssl_certificate certs/example.com.crt; ssl_certificate_key certs/example.com.key;
 location / { # ブラウザが quic ポートに誘導するために必要 add_header Alt-Svc 'h3=":8443"; ma=86400'; } } }

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

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

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

次のステップ

近い将来、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 は、ユーザーが正常に認証してアクセスを承認した後、アクセス トークンを受信し、それをキー値ストアに保存します。 NGINX Plus は、ダウンストリーム アプリケーションに送信されるすべてのリクエストに対して、HTTP Authorization ヘッダーでそのトークンをBearer Tokenとして渡すことができます。

注記： 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などの一部の ID プロバイダーでは、認証リクエストに追加のクエリ文字列引数を追加して、追加機能を有効にすることができます。 たとえば、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 ゾーン=jwt_sub:10m レート=1r/s;
サーバー { 場所 / { auth_jwt "realm"; auth_jwt_key_file key.jwk;
内部リダイレクト @rate_limited; }
場所 @rate_limited { 内部; limit_req zone=jwt_sub バースト=10;
 proxy_pass http://backend ; } } }

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

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

NGINXオープンソースから継承された変更

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

変更点

  • TLSv1.3プロトコルはデフォルトで有効になり、次のディレクティブのデフォルト値になりました。
  • NGINX は、リスニング ソケットのプロトコル パラメータが再定義されると警告を発行するようになりました。
  • NGINX は、クライアントによってパイプラインが使用された場合、接続を残留させて閉じるようになりました。
  • データ長が長すぎる、長さが短すぎる、レガシー バージョンが不正、共有署名アルゴリズムがない、ダイジェスト長が不正、sigalgs 拡張がない、暗号化された長さが長すぎる、長さが不正、キー更新が不正、ハンドシェイク データと非ハンドシェイク データが混在、ccs が早期に受信された、ccs と完了の間のデータ、パケット長が長すぎる、警告アラートが多すぎる、レコードが小さすぎる、ccs の前に fin を取得した、SSL エラーのログ レベルが、crit から info に引き下げられました。

特徴

  • ngx_http_gzip_static_moduleでバイト範囲がサポートされるようになりました。

バグ修正

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

回避策

  • zlib-ngの使用時に、 zip フィルターが事前に割り当てられたメモリを使用できなかったというアラートがログに表示されました。
  • listenディレクティブで使用されるホスト名が複数のアドレスに解決される場合、NGINX はこれらのアドレス内の重複を無視するようになりました。

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

NGINX JavaScript モジュールの変更

NGINX Plus R29 には、NGINX JavaScript (njs) モジュール バージョン 0.7.9 から 0.7.12 までの変更が組み込まれています。 njs には次のようないくつかの魅力的な機能が追加されました:

  • 拡張フェッチ API サポート
  • 拡張ウェブ暗号API
  • XML ドキュメントのサポート
  • XML ドキュメント解析
  • XML文書を変更するためのXMLNode API
  • Zlib モジュールの圧縮サポート

njs バージョン 0.7.9 から 0.7.12 までのすべての機能、変更、バグ修正の包括的なリストについては、 njs 変更ログを参照してください。

拡張フェッチ API サポート

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

非同期関数 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 API は JSON Web Key (JWK) 形式をサポートするように拡張され、importKey() は入力として JWK 形式のキーを受け取るようになりました。

非同期関数 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 モジュールは、XML ドキュメントを操作するためのネイティブ サポートを提供するために、njs 0.7.10 で追加されました。

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

XMLNode API は、XML ドキュメントを変更するために 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');
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 アルゴリズムを使用した圧縮機能を提供します。 

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

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

NGINX Plus をアップグレードまたは試用する

NGINX Plus を実行している場合は、できるだけ早く NGINX Plus R29 にアップグレードすることを強くお勧めします。 素晴らしい新機能に加えて、いくつかの追加の修正と改善も得られます。最新の状態にしておくと、サポート チケットを発行する必要がある場合に NGINX がサポートしやすくなります。

NGINX Plus をまだお試しいただいていない方は、セキュリティ、負荷分散、API ゲートウェイとして、または強化された監視および管理 API を備えた完全にサポートされた Web サーバーとして、ぜひお試しください。 今すぐ30 日間の無料トライアルを始めましょう。

F5 NGINX に関するブログ投稿をもっと読む ›

「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"