Ankündigung von NGINX Plus R29

Wir freuen uns, die Verfügbarkeit von NGINX Plus Release 29 (R29) bekannt zu geben. NGINX Plus basiert auf NGINX Open Source und ist der einzige All-in-One-Software-Webserver, Load Balancer, Reverse-Proxy, Inhaltscache und API-Gateway.
Zu den neuen und erweiterten Funktionen in NGINX Plus R29 gehören:

• Unterstützung für MQTT-Protokoll – Message Queuing Telemetry Transport (MQTT) ist ein einfaches Protokoll für die Kommunikation zwischen Geräten im Internet der Dinge (IoT). NGINX Plus R29 unterstützt das MQTT-Protokoll mit Preread- und Filtermodulen , die mehrere neue Anweisungen und Variablen einführen, um den MQTT-Verkehr zu verwalten und zu sichern.

• SAML-Unterstützung für Authentifizierung und Autorisierung – Security Assertion Markup Language (SAML) ist ein etabliertes Protokoll, das Single Sign-On (SSO) für Webanwendungen ermöglicht. NGINX Plus kann jetzt als SAML-Dienstanbieter (SP) konfiguriert werden, um Benutzer gegenüber einem SAML-Identitätsanbieter (IdP) zu authentifizieren.

• Native OpenTelemetry – OpenTelemetry (OTel) ist ein Framework, das herstellerunabhängig Telemetriedaten (Traces, Metriken und Protokolle) aus Remotequellen generiert, sammelt und exportiert. Das neue dynamische NGINX OTel-Modul bietet eine leistungsstarke OTel-Implementierung für die NGINX Plus-HTTP-Anforderungsverfolgung.

• Experimentelle QUIC+HTTP/3-Pakete – Vorschaupakete von NGINX Plus R29 mit QUIC+HTTP/3 sind jetzt verfügbar. Die NGINX Plus R29 QUIC-Pakete bieten Unterstützung für HttpContext und eine Reihe neuer Anweisungen zur Verwaltung von QUIC-Verbindungen und HTTP/3-Verkehr.

Wichtige Verhaltensänderungen

Notiz : Wenn Sie von einer anderen Version als NGINX Plus R28 aktualisieren, lesen Sie unbedingt den Abschnitt „Wichtige Verhaltensänderungen“ in früheren Ankündigungsblogs für alle Versionen zwischen Ihrer aktuellen und dieser.

Änderungen am Verpackungs-Repository

Das alte Paket-Repository plus-pkgs.nginx.com wird mit der Veröffentlichung von NGINX Plus R29 sofort außer Betrieb genommen. Dieses Repository wurde seit NGINX Plus R25 nicht mehr aktualisiert und es wird dringend empfohlen, das in NGINX Plus R24 eingeführte Paket-Repository pkgs.nginx.com zu verwenden.

Änderungen an der Plattformunterstützung

Neue unterstützte Betriebssysteme:

• Amazon Linux 2023

Ältere Betriebssysteme entfernt:

• Alpine 3.13, das am 1. November 2022 das Ende seiner Lebensdauer (EOL) erreichte

Ältere Betriebssysteme, die veraltet sind und deren Entfernung in NGINX Plus R30 geplant ist:

• Ubuntu 18.04, das im Juni 2023 EOL erreichen wird
• Alpine 3.14, das im Mai 2023 EOL erreichen wird

Anpassung an die Ankündigung zum Ende des Lebenszyklus von ModSecurity

Im Einklang mit der EOL-Ankündigung von ModSecurity entfernt NGINX Plus R29 die Unterstützung für ModSecurity-Pakete. Wenn Sie ein NGINX Plus-Kunde sind und ModSecurity-Pakete verwenden, können Sie sich in Kürze für ein Trade-In-Programm zwischen ModSecurity und NGINX App Protect entscheiden. Einzelheiten hierzu werden in Kürze verfügbar sein. Für weitere Informationen können Sie Ihren Ansprechpartner bei F5 kontaktieren.

Neue Features im Detail

Unterstützung für das MQTT-Protokoll

MQTT (Message Queuing Telemetry Transport) ist ein beliebtes und leichtes Publish-Subscribe-Messaging-Protokoll, das sich ideal für die Verbindung von IoT-Geräten und -Anwendungen (Clients) über das Internet eignet. Es ermöglicht Clients, Nachrichten zu einem bestimmten Thema zu veröffentlichen und andere Themen zu abonnieren. Abonnierte Clients erhalten alle zu diesem Thema veröffentlichten Nachrichten und ermöglichen so einen effizienten und fehlertoleranten Datenaustausch zwischen vielen Geräten und Diensten.

Das Herzstück einer MQTT-Architektur ist ein Broker. Ein Broker ist ein Server, der für die Verfolgung von Clients und aller von ihnen abonnierten Themen, die Verarbeitung von Nachrichten und die Weiterleitung dieser Nachrichten an entsprechende Systeme verantwortlich ist. NGINX Plus R29 unterstützt MQTT 3.1.1 und MQTT 5.0 . Es fungiert als Proxy zwischen Clients und Brokern, was die Systemarchitektur vereinfacht, Aufgaben auslagert und Kosten senkt.

Der anfängliche MQTT-Funktionssatz ermöglicht:

• MQTT-Broker-Lastausgleich
• Sitzungspersistenz (Erneutes Verbinden von Clients mit demselben Broker)
• TLS-Terminierung
• Client-Zertifikatauthentifizierung
• Parsen und Umschreiben von CONNECT-Nachrichten

Das MQTT-Protokoll definiert mehrere Nachrichtentypen, darunter CONNECT, PUBLISH und SUBSCRIBE. NGINX Plus R29 kann Teile von MQTT CONNECT-Nachrichten aktiv analysieren und neu schreiben und ermöglicht so Konfigurationsszenarien, die bisher nur mit benutzerdefinierten Skripten möglich waren.

Das Parsen und Umschreiben von MQTT-Nachrichten muss im Stream-Kontext einer NGINX-Konfigurationsdatei definiert werden und wird mit dem Modul ngx_stream_mqtt_preread_module ermöglicht.
und die Module ngx_stream_mqtt_filter_module .

MQTT Beispiele

Durch die Änderung der von einem MQTT-Gerät gesendeten Standard-Clientkennung kann NGINX vertrauliche Informationen wie die Seriennummer eines Geräts verbergen. In diesem ersten Beispiel wird die Kennung in die IP-Adresse des Geräts umgeschrieben.

Notiz: Die Verwendung der IP-Adresse eines Geräts als MQTT-Clientkennung wird in einer Produktionsumgebung nicht empfohlen.

stream { mqtt ein;
 Server { abhören 1883; Proxy-Passwort 10.0.0.8:1883; mqtt_set_connect Client-ID '$remote_addr'; } }

Angesichts der kurzlebigen Natur von MQTT-Clients können Sie sich zum Einrichten von Sticky Sessions mit Lastenausgleichsbrokern nicht einfach auf den Hostnamen oder die IP-Adresse eines Geräts verlassen. In diesem Beispiel fungiert die MQTT-Clientkennung eines Geräts als Hash-Schlüssel zum Aufrechterhalten von Verbindungen zu einzelnen MQTT-Brokern in einem Cluster mit Lastenausgleich:

stream { mqtt_preread ein;
 Upstream-Broker {Zone TCP_Mem 64k; Hash $mqtt_preread_clientid konsistent;
 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 { abhören 1883; Proxy-Pass-Broker; Proxy-Connect-Timeout 1 s; } }

Nächste Schritte

Zukünftige Entwicklungen von MQTT in NGINX Plus können das Parsen anderer MQTT-Nachrichtentypen sowie ein tieferes Parsen der CONNECT-Nachricht umfassen, um Funktionen wie die folgenden zu ermöglichen:

• Zusätzliche Authentifizierungs- und Zugriffskontrollmechanismen
• Schutz von Brokern durch Ratenbegrenzung „gesprächiger“ Kunden
• Nachrichtentelemetrie und Verbindungsmetriken

Wir würden uns über Ihr Feedback zu den Funktionen freuen, die Ihnen am wichtigsten sind. Teilen Sie uns in den Kommentaren Ihre Meinung mit.

SAML-Unterstützung für Authentifizierung und Autorisierung

SAML (Security Assertion Markup Language) ist ein offener Föderationsstandard, der es einem Identitätsanbieter (IdP) ermöglicht, Benutzer für den Zugriff auf eine Ressource zu authentifizieren (und so sicherzustellen, dass der Endbenutzer tatsächlich der ist, der er vorgibt zu sein) und diese Authentifizierungsinformationen zusammen mit den Zugriffsrechten des Benutzers auf diese Ressource zur Autorisierung an einen Dienstanbieter (SP) weiterzugeben.

SAML bietet seit langem eine sichere Möglichkeit zum Austausch von Identitätsdaten und ist ein weit verbreitetes Protokoll für den Austausch von Authentifizierungs- und Autorisierungsinformationen zwischen einem IdP und einem SP.

Zu den Hauptgründen, warum sich Unternehmen und staatliche Institutionen für die Einführung von SAML entscheiden, gehören:

• Effektive Verwaltung einer großen Anzahl von Identitäten
• Verbesserte, konsistente und einheitliche Identitätssicherheit für Kunden und Mitarbeiter
• Verbesserte Betriebseffizienz durch Standardisierung der Identitätsmanagementprozesse
• Effiziente Handhabung gesetzlicher Vorschriften

 
SAML bietet außerdem mehrere Vorteile:

• Bessere Benutzererfahrung : Dank der SSO-Integration und der einheitlichen Authentifizierungsüberprüfung beim IdP ermöglicht SAML den Benutzern eine einzige Authentifizierung für den Zugriff auf alle verbundenen Dienste. Dies verbessert das Benutzererlebnis und spart Zeit, da sich Benutzer nicht mehr mehrere Anmeldeinformationen für verschiedene Anwendungen merken müssen.

• Erhöhte Sicherheit : Abhängig von den Sicherheits- und Authentifizierungsrichtlinien Ihres Unternehmens können sich Benutzer mit einem SSO-Authentifizierungsschema entweder an der SP-Schnittstelle (SP-initiiertes SSO) oder direkt an der IdP-Schnittstelle (IdP-initiiertes SSO) anmelden. Dies verringert die Sicherheitsrisiken durch potenziell schwache und/oder sich wiederholende Passwörter.

• Reduzierte Verwaltungskosten : SAML unterstützt Unternehmen dabei, die Verantwortung für das Identitätsmanagement an einen vertrauenswürdigen IdP auszulagern und so die Kosten für die Pflege von Kontoinformationen und die damit verbundenen Ausgaben zu senken.

• Standardisiertes Protokoll : SAML wurde mit dem Prinzip entwickelt, die Sicherheit (so weit wie möglich) unabhängig von der Anwendungslogik zu machen. Es ist ein standardisiertes Protokoll, das von fast allen IdPs und Zugriffsverwaltungssystemen unterstützt wird. Es abstrahiert das Sicherheitsframework von Plattformarchitekturen und bestimmten Anbieterimplementierungen und ermöglicht so robuste Sicherheit und zuverlässige Integration zwischen Systemen.

Die aktuelle Referenzimplementierung von SAML verwendet SAML 2.0 und wird mit dem NGINX JavaScript (njs)-Framework erstellt. In dieser Implementierung fungiert NGINX Plus als SAML SP und kann so an einem SSO-Setup mit einem SAML IdP teilnehmen. Die aktuelle Implementierung hängt außerdem vom Schlüssel-Wert-Speicher ab, der eine vorhandene NGINX Plus-Funktion ist und als solche ohne zusätzliche Änderungen nicht für NGINX Open Source geeignet ist.

SAML-Unterstützung in NGINX Plus ist als Referenzimplementierung auf GitHub verfügbar. Das GitHub-Repository enthält eine Beispielkonfiguration mit Anweisungen zur Installation, Konfiguration und Feinabstimmung für bestimmte Anwendungsfälle.

Native OpenTelemetry

OpenTelemetry (OTel) ist eine Technologie und ein Standard, der zum Überwachen, Verfolgen, Troubleshooting und Optimieren von Anwendungen verwendet werden kann. OTel funktioniert, indem es Telemetriedaten aus verschiedenen Quellen sammelt, wie etwa Proxys, Anwendungen oder anderen Diensten in einem bereitgestellten Anwendungsstapel.

Als protokollbewusster Reverse-Proxy und Load Balancer ist NGINX ideal positioniert, um Telemetrieaufrufe zum Verfolgen von Anwendungsanforderungen und -antworten zu initiieren. Obwohl OTel-Module von Drittanbietern bereits seit einiger Zeit verfügbar sind, freuen wir uns, die native Unterstützung für OTel in NGINX Plus mit einem neuen dynamischen Modul bekannt zu geben.

Das neue Modul ngx_otel_module kann mit dem Paket nginx-plus-module-otel installiert werden und bietet mehrere wichtige Verbesserungen für Module von Drittanbietern, darunter:

• Bessere Leistung – Die meisten OTel-Implementierungen reduzieren die Leistung der Anforderungsverarbeitung um bis zu 50 %, wenn die Ablaufverfolgung aktiviert ist. Unser neues natives Modul begrenzt diesen Einfluss auf etwa 10–15 %.
• Einfache Bereitstellung – Das Einrichten und Konfigurieren der Telemetriesammlung kann direkt in den NGINX-Konfigurationsdateien erfolgen.
• Vollständig dynamisches, variablenbasiertes Sampling – Die Möglichkeit, eine bestimmte Sitzung per Cookie/Token zu verfolgen und Steuern Sie das Modul dynamisch über die NGINX Plus-API und Key-Value-Store- Module.

Weitere Einzelheiten zum dynamischen OTel-Modul finden Sie in der NGINX-Dokumentation .

OTel Tracing-Beispiele

Dies ist ein Beispiel für die grundlegende OTel-Verfolgung einer Anwendung, die direkt von NGINX bereitgestellt wird:

Lademodulmodule/ngx_otel_module.so;
 Ereignisse {}
 http { otel_exporter { Endpunkt localhost:4317; }
 Server { abhören 127.0.0.1:8080;
 otel_trace on;        otel_span_name app1;    } }

Im nächsten Beispiel erben wir Ablaufverfolgungskontexte von eingehenden Anfragen und zeichnen Spannen nur auf, wenn ein übergeordneter Span abgetastet wird. Darüber hinaus geben wir Trace-Kontexte und Sampling-Entscheidungen an Upstream-Server weiter.

Lademodulmodule/ngx_otel_module.so;
 http { Server { Standort / { otel_trace $otel_parent_sampled; otel_trace_context propagate; Proxy-Pass http://backend; } } }

In diesem verhältnisbasierten Beispiel wird die Ablaufverfolgung für einen Prozentsatz des Datenverkehrs (in diesem Fall 10 %) konfiguriert:

http { # 10 % der Anfragen verfolgen split_clients "$otel_trace_id" $ratio_sampler { 10 % an; * aus; }
 # oder wir können 10 % der Benutzersitzungen verfolgen
 split_clients "$cookie_sessionid" $session_sampler { 10% an; * aus; }
 Server { Standort / { otel_trace $ratio_sampler; otel_trace_context injizieren;
 Proxy-Passwort http://backend; } } }

In diesem API-gesteuerten Beispiel wird die Ablaufverfolgung durch die Manipulation des Schlüssel-Wert-Speichers über den /api-Endpunkt aktiviert:

http { keyval "otel.trace" $trace_switch zone=name;
 Server { Standort / { otel_trace $trace_switch; otel_trace_context inject; proxy_pass http://backend; }
 Standort /api { api schreiben=ein; } } }

Experimentelle QUIC+HTTP/3-Pakete

Nach unserer Ankündigung von Vorschau-Binärpaketen für NGINX Open Source freuen wir uns, experimentelle QUIC-Pakete für NGINX Plus R29 ankündigen zu können. Dadurch ist es möglich, HTTP/3 mit NGINX Plus zu testen und zu evaluieren.

Mit einem neuen zugrunde liegenden Protokollstapel bringt HTTP/3 UDP und QUIC auf die Transportschicht. QUIC ist ein verschlüsseltes Transportprotokoll, das als Verbesserung gegenüber TCP konzipiert wurde, indem es Verbindungsmultiplexing ermöglicht und Probleme wie Head-of-Line-Blockierung löst. Es implementiert zahlreiche TCP-Funktionen von HTTP/1.1 und HTTP/2 neu und verbessert diese, darunter Verbindungsaufbau, Überlastungskontrolle und zuverlässige Übermittlung. QUIC enthält außerdem TLS als integrale Komponente, im Gegensatz zu HTTP/1.1 und HTTP/2, die TLS als separate Schicht haben. Dies bedeutet, dass HTTP/3-Nachrichten von Natur aus sicher sind, da sie standardmäßig über eine verschlüsselte Verbindung gesendet werden.

Zur Gewährleistung einer sicheren Kommunikation und kryptografischer Funktionen verlässt sich NGINX Plus in der Regel auf OpenSSL und nutzt die SSL/TLS-Bibliotheken, die mit den Betriebssystemen mitgeliefert werden. Da die TLS-Schnittstellen von QUIC zum Zeitpunkt der Erstellung dieses Dokuments jedoch nicht von OpenSSL unterstützt werden, werden Bibliotheken von Drittanbietern benötigt, um die fehlende TLS-Funktionalität bereitzustellen, die von HTTP/3 benötigt wird.

Um dieses Problem zu lösen, haben wir eine OpenSSL-Kompatibilitätsschicht für QUIC entwickelt, wodurch die Notwendigkeit entfällt, TLS-Bibliotheken von Drittanbietern wie quictls, BoringSSL und LibreSSL zu erstellen und bereitzustellen. Dies hilft dabei, das End-to-End-QUIC+HTTP/3-Erlebnis in NGINX zu verwalten, ohne die Belastung einer benutzerdefinierten TLS-Implementierung oder die Abhängigkeit von Zeitplänen und Roadmaps von Bibliotheken von Drittanbietern.

Notiz : Die OpenSSL-Kompatibilitätsschicht ist in den experimentellen NGINX Plus QUIC+HTTP/3-Paketen enthalten und erfordert OpenSSL 1.1.1 oder höher, um TLSv1.3 bereitzustellen (was vom QUIC-Protokoll erforderlich ist). 0-RTT ist noch nicht implementiert.

QUIC+HTTP/3 Beispielkonfiguration

Sehen wir uns eine Beispielkonfiguration von QUIC+HTTP/3 in NGINX Plus an:

http { log_format quic '$remote_addr - $remote_user [$time_local]' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" "$http3"';
 access_log Protokolle/access.log schnell;
 Server { # für bessere Kompatibilität wird empfohlen, # für Quic und HTTPS denselben Port zu verwenden. Listen 8443 Quic Reuseport; Listen 8443 SSL;
 SSL-Zertifikat certs/example.com.crt; SSL-Zertifikatschlüssel certs/example.com.key;
 Standort / { # erforderlich, damit Browser sie zum Quick-Port weiterleiten können add_header Alt-Svc 'h3=":8443"; ma=86400'; } } }

Ähnlich wie bei unserer Implementierung von HTTP/2 werden, wenn NGINX Plus als Proxy fungiert, QUIC+HTTP/3-Verbindungen auf der Clientseite hergestellt und beim Verbinden mit Backend- und Upstream-Diensten in HTTP/1.1 konvertiert.

Die experimentellen NGINX Plus QUIC+HTTP/3-Pakete sind in einem separaten Repository verfügbar und mit vorhandenen NGINX Plus-Zertifikaten und -Schlüsseln zugänglich. Die Installation der experimentellen QUIC-Pakete ähnelt einer Standardinstallation von NGINX Plus . Stellen Sie sicher, dass Sie das QUIC-Repo verwenden, wie in den Installationsschritten hervorgehoben.

Weitere Informationen zum Konfigurieren von NGINX für QUIC+HTTP/3 finden Sie unter Konfigurieren von NGINX für QUIC+HTTP/3. Informationen zu allen neuen Anweisungen und Variablen finden Sie im Abschnitt „Konfiguration“ der nginx-quic-README-Datei .

Nächste Schritte

In naher Zukunft planen wir, den QUIC+HTTP/3-Code in den NGINX-Hauptzweig zu integrieren. Die neueste Version der NGINX-Hauptlinie mit QUIC+HTTP/3-Unterstützung wird dann in eine folgende NGINX-Plus-Version integriert. Erwarten Sie später in diesem Jahr eine Ankündigung zur offiziellen Verfügbarkeit der QUIC+HTTP/3-Unterstützung in NGINX Plus.

Weitere Verbesserungen in NGINX Plus R29

Änderungen an OpenID Connect

Die Unterstützung für OpenID Connect (OIDC) wurde in NGINX Plus R15 eingeführt und in nachfolgenden Versionen erheblich erweitert. NGINX Plus R29 verbessert OIDC weiterhin mit den folgenden Ergänzungen.

Unterstützung für Zugriffstoken

Zugriffstoken werden bei der tokenbasierten Authentifizierung verwendet, um einem OIDC-Client den Zugriff auf eine geschützte Ressource im Namen des Benutzers zu ermöglichen. NGINX Plus erhält einen Zugriffstoken, nachdem ein Benutzer den Zugriff erfolgreich authentifiziert und autorisiert hat, und speichert ihn dann im Schlüssel-Wert-Speicher. NGINX Plus kann dieses Token im HTTP-Autorisierungsheader als Bearer-Token für jede Anfrage weitergeben, die an die nachgelagerte Anwendung gesendet wird.

Notiz : NGINX Plus überprüft die Gültigkeit des Zugriffstokens nicht bei jeder Anfrage (wie dies beim ID-Token der Fall ist) und kann nicht wissen, ob das Zugriffstoken bereits abgelaufen ist. Wenn die Lebensdauer des Zugriffstokens kürzer ist als die des ID-Tokens, müssen Sie die on-Direktive proxy_intercept_errors verwenden. Dadurch werden 401-Unauthorized -Antworten abgefangen und an NGINX umgeleitet und das Zugriffstoken aktualisiert.

Weitere Informationen zur OpenID Connect- und JSON Web Token (JWT)-Validierung mit NGINX Plus finden Sie unter Authentifizieren von Benutzern bei vorhandenen Anwendungen mit OpenID Connect und NGINX Plus .

Hinzugefügte Argumente im OIDC-Authentifizierungsendpunkt

Einige Identitätsanbieter, beispielsweise Keycloak , erlauben das Hinzufügen zusätzlicher Abfragezeichenfolgenargumente zur Authentifizierungsanforderung, um zusätzliche Funktionen zu aktivieren. Keycloak ermöglicht beispielsweise die Angabe eines Standard-IdP durch Hinzufügen eines kc_idp_hint- Parameters zur Authentifizierungsanforderung. Als Teil dieser Erweiterung kann der Benutzer zusätzliche Argumente für den OIDC-Autorisierungsendpunkt angeben.

Erweiterte SSL-Zähler im Prometheus-njs-Modul

In NGINX Plus R28 haben wir zusätzliche SSL-Zählerunterstützung für Handshake-Fehler und Zertifikatsvalidierungsfehler in HTTP- und Stream-Modulen für clientseitige und serverseitige Verbindungen hinzugefügt. Unser Prometheus-njs- Modul, das NGINX Plus-Metriken in ein Prometheus-kompatibles Format konvertiert, unterstützt jetzt diese Zähler.

Neue internal_redirect- Direktive

Die neue Direktive und das neue Modul internal_redirect ermöglichen interne Weiterleitungen nach der Überprüfung der Anforderungsverarbeitungslimits , Verbindungsverarbeitungslimits und Zugriffslimits .

Hier ist ein Beispiel für eine internal_redirect -Konfiguration:

http { limit_req_zone $jwt_claim_sub zone=jwt_sub:10m Rate=1r/s;
 Server { Standort / { auth_jwt "Bereich"; auth_jwt_Schlüsseldatei key.jwk;
 interne_Weiterleitung @rate_limited; }
 Standort @rate_limited { intern; limit_req Zone=jwt_sub Burst=10;
 Proxy-Passwort http://backend ; } } }

Im obigen Beispiel wird die JWT-Authentifizierung am Standortblock durchgeführt und – wenn das Token gültig ist – wird die Anforderung an den internen Inhaltshandler @rate_limited übergeben, wo basierend auf dem Unteranspruchswert eine Anforderungsratenbegrenzung angewendet wird. Dies geschieht im JWT, bevor die Anforderung an den Upstream-Dienst weitergegeben wird.

Diese spezielle Konfiguration verhindert einen Denial-of-Service-Angriff (DoS), bei dem ein Angreifer eine Flut von Anfragen mit lesbaren JWTs sendet, die mit einem bestimmten Benutzer als Unterfeld codiert sind. Diese Flut an Anfragen besteht die Authentifizierung nicht, wird aber auf die Ratenbegrenzung angerechnet. Indem Sie das JWT authentifizieren, bevor Sie die Anforderung an den Inhaltshandler weitergeben, stellen Sie sicher, dass nur gültige Anforderungen für die Ratenbegrenzung berücksichtigt werden.

Von NGINX Open Source übernommene Änderungen

NGINX Plus R29 basiert auf NGINX Open Source 1.23.4 und übernimmt funktionale Änderungen und Fehlerbehebungen seit der Veröffentlichung von NGINX Plus R28 (in NGINX 1.23.3 bis 1.23.4).

Änderungen

• Das TLSv1.3 -Protokoll ist jetzt standardmäßig aktiviert und ist der Standardwert für diese Anweisungen:
• SSL-Protokolle ( HTTP , Stream , Mail )
• Proxy-SSL-Protokolle ( HTTP , Stream )
• grpc_ssl_protokolle
• uwsgi_ssl_protokolle
• Zone_Sync_SSL_Protokolle
• NGINX gibt jetzt eine Warnung aus, wenn Protokollparameter eines Listening-Sockets neu definiert werden.
• NGINX schließt jetzt Verbindungen mit Verweilen, wenn der Client Pipelining verwendet hat.
• Die Protokollierungsebene für die folgenden SSL-Fehler wurde von „Kritisch“ auf „Info“ herabgestuft: Datenlänge zu lang, Länge zu kurz, fehlerhafte Legacy-Version, keine gemeinsam genutzten Signaturalgorithmen, fehlerhafte Digest-Länge, fehlende Sigalgs-Erweiterung, verschlüsselte Länge zu lang, fehlerhafte Länge, fehlerhaftes Schlüsselupdate, gemischte Handshake- und Nicht-Handshake-Daten, CCS zu früh empfangen, Daten zwischen CCS und fertig, Paketlänge zu lang, zu viele Warnmeldungen, Datensatz zu klein und „Fin vor CCS erhalten“ wurde von „Kritisch“ auf „Info“ herabgestuft.

Merkmale

• Bytebereiche werden jetzt im ngx_http_gzip_static_module unterstützt.

Fehlerbehebungen

• Portbereiche in der Listen-Direktive behoben, die nicht funktionierten.
• Es wurde ein falscher Standort behoben, der möglicherweise zur Verarbeitung einer Anfrage ausgewählt wurde, wenn in der Konfiguration ein Präfixstandort mit mehr als 255 Zeichen verwendet wurde.
• Nicht-ASCII-Zeichen in Dateinamen unter Windows behoben, die von ngx_http_autoindex_module , ngx_http_dav_module und der Include-Direktive nicht unterstützt wurden.
• Es wurde ein Socket-Leak behoben, der manchmal auftrat, wenn HTTP/2 und die Direktive error_page zum Umleiten von Fehlern mit Code verwendet wurden400 .
• Meldungen über die Protokollierung von Syslog- Fehlern wurden behoben, die keine Informationen darüber enthielten, dass die Fehler während der Protokollierung in Syslog auftraten.
• Die Handhabung blockierter Client-Lesevorgänge im Proxy -r wurde behoben.
• Ein Fehler wurde behoben, der manchmal beim Lesen des Headers des PROXY-Protokolls Version 2 mit einer großen Anzahl von TLVs auftrat.
• Ein Segmentierungsfehler wurde behoben, der manchmal in einem Arbeitsprozess auftrat, wenn SSI zum Verarbeiten von von anderen Modulen erstellten Unteranforderungen verwendet wurde.
• Behoben: NGINX beanspruchte möglicherweise die CPU während des ungepufferten Proxyings stark, wenn SSL-Verbindungen zu Backends verwendet wurden.

Problemumgehungen

• Bei der Verwendung von zlib-ng wurden in den Protokollen Warnmeldungen angezeigt , dass der Zip-Filter den vorab zugewiesenen Speicher nicht verwenden konnte .
• Wenn ein in der Listen -Direktive verwendeter Hostname in mehrere Adressen aufgelöst wird, ignoriert NGINX jetzt Duplikate innerhalb dieser Adressen.

Die vollständige Liste der neuen Funktionen, Änderungen, Fehlerbehebungen und Problemumgehungen dieser Versionen finden Sie in der Datei CHANGES .

Änderungen am NGINX JavaScript-Modul

NGINX Plus R29 enthält Änderungen der NGINX JavaScript (njs)-Modulversionen 0.7.9 bis 0.7.12. NJS wurden mehrere spannende Funktionen hinzugefügt, darunter:

• Erweiterte Fetch-API-Unterstützung
• Erweiterte Web Crypto API
• XML-Dokumentunterstützung
• XML-Dokumentanalyse
• XMLNode-API zum Ändern von XML-Dokumenten
• Komprimierungsunterstützung für Zlib-Module

Eine umfassende Liste aller Funktionen, Änderungen und Fehlerbehebungen von njs Version 0.7.9 bis 0.7.12 finden Sie im njs-Änderungsprotokoll .

Erweiterte Fetch-API-Unterstützung

Der Fetch API wurden die Konstruktoren Headers() , Request() und Response() sowie weitere Verbesserungen hinzugefügt:

asynchrone Funktion makeRequest(uri, headers) {     let h = neue Header(headers);
    h.delete("bar");
    h.append("foo", "xxx");
    let r = neue Anfrage(uri, {headers: h});
    return warte auf ngx.fetch(r);
}

Erweiterte Web Crypto API

Die Web Crypto API wurde erweitert, um das JSON Web Key (JWK)-Format zu unterstützen, und die Funktion importKey() akzeptiert jetzt Schlüssel im JWK-Format als Eingabe:

asynchrone Funktion importSigningJWK(jwk) {    return warte auf crypto.subtle.importKey('jwk', jwk,
                                          {Name: "RSASSA-PKCS1-v1_5"},
                                              true, ['Zeichen']);
}

njs 0.7.10 hat außerdem die Methoden generateKey() und exportKey() hinzugefügt. Mit der Methode generateKey() können Sie einen neuen Schlüssel für symmetrische Algorithmen oder ein Schlüsselpaar für Public-Key-Algorithmen generieren. Die Methode exportKey() verwendet ein CryptoKey- Objekt als Eingabe und gibt den Schlüssel in einem externen, portablen Format zurück. Es unterstützt das JWK-Format, um den Schlüssel als JSON-Objekt zu exportieren.

Weitere Einzelheiten finden Sie unter Web Crypto API .

XML-Dokumentunterstützung

Das XML-Modul wurde in njs 0.7.10 hinzugefügt, um native Unterstützung für die Arbeit mit XML-Dokumenten bereitzustellen.

XML-Dokumentanalyse

Sie können jetzt einen String oder Puffer für ein XML-Dokument analysieren, das dann ein XMLDoc- Wrapperobjekt zurückgibt, das das analysierte XML-Dokument darstellt:

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

XMLNode-API zum Ändern von XML-Dokumenten

Die XMLNode-API wurde in njs 0.7.11 hinzugefügt, um XML-Dokumente zu ändern:

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 löschen;
   

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

Weitere Einzelheiten zu allen XML-bezogenen Erweiterungen finden Sie in den XML-Dokumenten .

Komprimierungsunterstützung für Zlib-Module

Das zlib-Modul wurde in njs 0.7.12 hinzugefügt und bietet Komprimierungsfunktionen mithilfe der Deflate- und Inflate-Algorithmen.

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

Weitere Einzelheiten zu zlib finden Sie in den zlib-Dokumenten .

Upgrade oder Testen von NGINX Plus

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich auf NGINX Plus R29 zu aktualisieren. Zusätzlich zu den ganzen tollen neuen Funktionen erhalten Sie auch mehrere zusätzliche Fehlerbehebungen und Verbesserungen. Und wenn Sie auf dem neuesten Stand sind, kann NGINX Ihnen helfen, wenn Sie ein Support-Ticket erstellen müssen.

Wenn Sie NGINX Plus noch nicht ausprobiert haben, empfehlen wir Ihnen, es auszuprobieren – für Sicherheit, Lastausgleich und API-Gateway oder als vollständig unterstützten Webserver mit erweiterten Überwachungs- und Verwaltungs-APIs. Beginnen Sie noch heute mit einer kostenlosen 30-Tage-Testversion .