Verwenden von VMware Spring Cloud Gateway-Routenfiltern mit dem Azure Spring Apps Enterprise-Plan
Hinweis
Azure Spring Apps ist der neue Name für den Azure Spring Cloud-Dienst. Obwohl der Dienst umbenannt wurde, wird der alte Name noch an einigen Stellen verwendet, solange wir Ressourcen wie Screenshots, Videos und Diagramme aktualisieren.
Dieser Artikel gilt für:❌ Basic/Standard ✔️ Enterprise
In diesem Artikel wird erläutert, wie Sie VMware Spring Cloud Gateway-Routenfilter mit dem Azure Spring Apps Enterprise-Plan verwenden, um Anforderungen an Ihre Anwendungen weiterzuleiten.
VMware Spring Cloud Gateway ist eine kommerzielle VMware Tanzu-Komponente, die auf dem Spring Cloud Gateway-Open-Source-Projekt basiert. Spring Cloud Gateway erleichtert die Berücksichtigung übergreifender Aspekte durch API-Entwicklungsteams, z. B. einmaliges Anmelden (SSO), Zugriffssteuerung, Ratenbegrenzung, Resilienz, Sicherheit usw. Sie können die API-Bereitstellung mit modernen cloudnativen Modellen und einer beliebigen Programmiersprache für die API-Entwicklung beschleunigen.
VMware Spring Cloud Gateway umfasst die folgenden Funktionen:
- Dynamische Routingkonfiguration, unabhängig von einzelnen Anwendungen, die ohne Neukompilierung angewendet und geändert werden können.
- Commercial API route filters for transporting authorized JSON Web Token (JWT) claim to application services.
- Clientzertifikatautorisierung.
- Ratenbegrenzungsansätze.
- Konfiguration von Trennschaltern (Circuit Breakers)
- Unterstützung für den Zugriff auf Anwendungsdienste über HTTP-Standardauthentifizierungsanmeldeinformationen.
Um das API-Portal für VMware Tanzu zu integrieren, generiert VMware Spring Cloud Gateway automatisch openAPI Version 3-Dokumentation nach allen Routenkonfigurationszufügungen oder -änderungen. Weitere Informationen finden Sie unter Verwenden des API-Portals für VMware Tanzu.
Voraussetzungen
- Eine bereits bereitgestellte Azure Spring Apps Enterprise-Plandienstinstanz mit aktiviertem Spring Cloud Gateway. Weitere Informationen finden Sie in der Schnellstartanleitung: Erstellen und Bereitstellen von Apps in Azure Spring Apps mit dem Enterprise-Plan.
- Azure CLI-Version 2.0.67 oder höher Verwenden Sie den folgenden Befehl, um die Azure Spring Apps-Erweiterung zu installieren:
az extension add --name spring.
Filter verwenden
Sie verwenden Filter in Ihrer Spring Cloud Gateway-Konfiguration, um auf die eingehende Anforderung oder ausgehende Antwort auf eine Routenkonfiguration zu reagieren.
Sie können z. B. einen Filter verwenden, um einen HTTP-Header hinzuzufügen oder den Zugriff basierend auf einem Autorisierungstoken zu verweigern.
Verwenden von Open Source-Filtern
Spring Cloud Gateway OSS enthält mehrere GatewayFilter Fabriken, die zum Erstellen von Filtern für Routen verwendet werden. In den folgenden Abschnitten werden diese Fabriken beschrieben.
AddRequestHeader
Die AddRequestHeader Factory fügt einen Header zu den Headern der downstream-Anforderung für alle übereinstimmenden Anforderungen hinzu.
Diese Factory akzeptiert die folgenden Konfigurationsparameter:
namevalue
Im folgenden Beispiel wird eine Factory konfiguriert, die den Header zu den Headern der downstream-Anforderung für alle übereinstimmenden Anforderungen hinzufügt:The following example configures an AddRequestHeader factory that adds the header X-Request-red:blue to the downstream request's header for all matching requests:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"AddRequestHeader=X-Request-red, blue"
]
}
]
Die AddRequestHeader Factory hat Zugriff auf die URI-Variablen, die zum Abgleichen eines Pfads oder Hosts verwendet werden. Sie können URI-Variablen im Wert verwenden, und die Variablen werden zur Laufzeit erweitert.
Im folgenden Beispiel wird eine AddRequestHeader Factory konfiguriert, die eine Variable verwendet:
[
{
"predicates": [
"Path=/api/{segment}"
],
"filters": [
"AddRequestHeader=X-Request-red, blue-{segment}"
]
}
]
AddRequestHeadersIfNotPresent
Die AddRequestHeadersIfNotPresent Factory fügt Kopfzeilen hinzu, wenn sie in der ursprünglichen Anforderung nicht vorhanden sind.
Diese Factory akzeptiert den folgenden Konfigurationsparameter:
headers: Eine durch Trennzeichen getrennte Liste von Schlüssel-Wert-Paaren (Headername, Headerwert).
Im folgenden Beispiel wird eine AddRequestHeadersIfNotPresent Factory konfiguriert:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"AddRequestHeadersIfNotPresent=Content-Type:application/json,Connection:keep-alive"
]
}
]
AddRequestParameter
Die AddRequestParameter Factory fügt einen Parameter zur Abfragezeichenfolge der downstream-Anforderung für alle übereinstimmenden Anforderungen hinzu.
Diese Factory akzeptiert die folgenden Konfigurationsparameter:
namevalue
Im folgenden Beispiel wird eine AddRequestParameter Factory konfiguriert, die der Abfragezeichenfolge der nachgeschalteten Anforderung einen red=blue Parameter für alle übereinstimmenden Anforderungen hinzufügt:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"AddRequestParameter=red, blue"
]
}
]
Die AddRequestParameter Factory hat Zugriff auf die URI-Variablen, die zum Abgleichen eines Pfads oder Hosts verwendet werden. Sie können URI-Variablen im Wert verwenden, und die Variablen werden zur Laufzeit erweitert.
Im folgenden Beispiel wird eine AddRequestParameter Factory konfiguriert, die eine Variable verwendet:
[
{
"predicates": [
"Path=/api/{segment}"
],
"filters": [
"AddRequestParameter=foo, bar-{segment}"
]
}
]
AddResponseHeader
Die AddResponseHeader Factory fügt einen Header zu den Headern der nachgeschalteten Antwort für alle übereinstimmenden Anforderungen hinzu.
Diese Factory akzeptiert die folgenden Konfigurationsparameter:
namevalue
Im folgenden Beispiel wird eine AddResponseHeader Factory konfiguriert, die den Headern der nachgeschalteten Antwort für alle übereinstimmenden Anforderungen einen X-Response-Red:Blue Header hinzufügt:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"AddResponseHeader=X-Response-Red, Blue"
]
}
]
Die AddResponseHeader Factory hat Zugriff auf die URI-Variablen, die zum Abgleichen eines Pfads oder Hosts verwendet werden. Sie können URI-Variablen im Wert verwenden, und die Variablen werden zur Laufzeit erweitert.
Im folgenden Beispiel wird eine AddResponseHeader Factory konfiguriert, die eine Variable verwendet:
[
{
"predicates": [
"Path=/api/{segment}"
],
"filters": [
"AddResponseHeader=foo, bar-{segment}"
]
}
]
CircuitBreaker
Die CircuitBreaker Fabrik umschließt Routen in einem Schaltkreisschalter.
Diese Factory akzeptiert die folgenden Konfigurationsparameter:
name: Der Name des Schaltkreisschalters.fallbackUri: Der Umleitungs-URI, der eine lokale Route oder ein externer Handler sein kann.status codes(optional): Die durch Doppelpunkt getrennte Liste der Statuscodes, die übereinstimmen sollen, im Zahlen- oder Textformat.failure rate(optional): Der Schwellenwert, über dem der Schaltkreisschalter geöffnet wird. Der Standardwert ist 50 %.duration(optional): Die Wartezeit, bevor sie erneut geschlossen wird. Der Standardwert beträgt 60 Sekunden.
Im folgenden Beispiel wird eine CircuitBreaker Factory konfiguriert:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"CircuitBreaker=myCircuitBreaker,forward:/inCaseOfFailureUseThis,401:NOT_FOUND:500,10,30s"
]
}
]
DeDupeResponseHeader
Die DeDupeResponseHeader Factory entfernt doppelte Werte von Antwortheadern.
Diese Factory akzeptiert die folgenden Konfigurationsparameter:
name: Eine durch Leerzeichen getrennte Liste von Kopfzeilennamen.strategy(optional): Die akzeptierten Werte sindRETAIN_FIRST,RETAIN_LASTundRETAIN_UNIQUE. Der Standardwert istRETAIN_FIRST.
Im folgenden Beispiel wird eine DeDupeResponseHeader Factory konfiguriert, die doppelte Werte von Access-Control-Allow-Credentials und Access-Control-Allow-Origin Antwortheader entfernt, wenn beide Werte von der CORS-Logik des Gateways und der downstream-Logik hinzugefügt werden:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"DeDupeResponseHeader=Access-Control-Allow-Credentials Access-Control-Allow-Origin"
]
}
]
FallbackHeaders
Die FallbackHeaders Factory fügt einer Kopfzeile eine Ausnahme für den Schaltkreistrennschalter hinzu. Für diesen Filter ist die Verwendung des CircuitBreaker Filters in einer anderen Route erforderlich.
Für diese Factory gibt es keine Parameter.
Im folgenden Beispiel wird eine FallbackHeaders Factory mit dem Ausnahmetyp, der Nachricht und (sofern verfügbar) der Ursache für den Ausnahmetyp und die Meldung konfiguriert, die der FallbackHeaders Filter der Anforderung hinzufügt:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"CircuitBreaker=myCircuitBreaker,forward:/inCaseOfFailureUseThis,401:NOT_FOUND:500,10,30s"
]
},
{
"predicates": [
"Path=/inCaseOfFailureUseThis"
],
"filters": [
"FallbackHeaders"
]
}
]
Sie können die Namen der Header in der Konfiguration überschreiben, indem Sie die Werte der folgenden Parameter festlegen (Erwähnung mit ihren Standardwerten):
executionExceptionTypeHeaderName("Execution-Exception-Type")executionExceptionMessageHeaderName("Execution-Exception-Message")rootCauseExceptionTypeHeaderName("Root-Cause-Exception-Type")rootCauseExceptionMessageHeaderName("Root-Cause-Exception-Message")
JSONToGRPC
Die JSONToGRPCFilter Factory konvertiert eine JSON-Nutzlast in eine gRPC-Anforderung.
Diese Factory akzeptiert den folgenden Konfigurationsparameter:
protoDescriptor: Eine Protobeschreibungsdatei.
Sie können diese Datei mithilfe protoc und Angeben des --descriptor_set_out Flags generieren, wie im folgenden Beispiel gezeigt:
protoc --proto_path=src/main/resources/proto/ \
--descriptor_set_out=src/main/resources/proto/hello.pb \
src/main/resources/proto/hello.proto
Hinweis
Der streaming Parameter wird nicht unterstützt.
Im folgenden Beispiel wird eine JSONToGRPCFilter Factory mithilfe der Ausgabe von protoc:
[
{
"predicates": [
"Path=/json/**"
],
"filters": [
"JsonToGrpc=file:proto/hello.pb,file:proto/hello.proto,HelloService,hello"
]
}
]
LocalResponseCache
Die LocalResponseCache Factory setzt die konfiguration des lokalen Antwortcaches für bestimmte Routen außer Kraft, wenn der globale Cache aktiviert wird.
Diese Factory akzeptiert die folgenden Konfigurationsparameter:
size: Die maximal zulässige Größe der Cacheeinträge für diese Route, bevor die Cacheräumung beginnt (in KB, MB und GB).timeToLive: Die zulässige Lebensdauer eines Cacheeintrags vor ablaufen. Verwenden Sie das Suffixs"Dauer" für Sekunden,mminutenlang oderhstundenlang.
Im folgenden Beispiel wird eine LocalResponseCache Factory konfiguriert:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"LocalResponseCache=3m,1MB"
]
}
]
MapRequestHeader
Die MapRequestHeader Factory fügt der downstream-Anforderung einen Header mit aktualisierten Werten aus dem Header der eingehenden HTTP-Anforderung hinzu.
Diese Factory akzeptiert die folgenden Konfigurationsparameter:
fromHeadertoHeader
Diese Factory erstellt einen neuen benannten Header (toHeader), und der Wert wird aus einem vorhandenen benannten Header (fromHeader) aus der eingehenden HTTP-Anforderung extrahiert. Wenn der Eingabeheader nicht vorhanden ist, hat der Filter keine Auswirkung. Wenn der neue benannte Header bereits vorhanden ist, werden die Werte mit den neuen Werten erweitert.
Im folgenden Beispiel wird eine MapRequestHeader Factory konfiguriert, die den X-Request-Red:<values> Header der downstream-Anforderung mit aktualisierten Werten aus dem Header der eingehenden HTTP-Anforderung Blue hinzufügt:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"MapRequestHeader=Blue, X-Request-Red"
]
}
]
PrefixPath
Die PrefixPath Factory fügt dem Pfad aller Anforderungen ein Präfix hinzu.
Diese Factory akzeptiert den folgenden Konfigurationsparameter:
prefix
Im folgenden Beispiel wird eine PrefixPath Factory konfiguriert, die das Präfix /api zum Pfad aller Anforderungen hinzufügt, sodass eine Anforderung /catalog an /api/catalog:
[
{
"predicates": [
"Path=/catalog/**"
],
"filters": [
"PrefixPath=/api"
]
}
]
PreserveHostHeader
Die PreserveHostHeader Factory legt ein Anforderungsattribut fest, das der Routingfilter prüft, um festzustellen, ob der ursprüngliche Hostheader oder der vom HTTP-Client festgelegte Hostheader gesendet werden soll.
Für diese Factory gibt es keine Parameter.
Im folgenden Beispiel wird eine PreserveHostHeader Factory konfiguriert:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"PreserveHostHeader"
]
}
]
RedirectTo
Die RedirectTo Factory fügt eine Umleitung zur ursprünglichen URL hinzu.
Diese Factory akzeptiert die folgenden Konfigurationsparameter:
status: Ein 300-Reihenumleitungs-HTTP-Code, z301. B. .url: Der Wert derLocationKopfzeile. Muss ein gültiger URI sein. Für relative Umleitungen sollten Sie als URI Ihrer Routendefinition verwendenuri: no://op.
Im folgenden Beispiel wird eine RedirectTo Factory konfiguriert, die einen Status 302 mit einem Location:https://acme.org Header sendet, um eine Umleitung auszuführen:
[
{
"uri": "https://example.org",
"filters": [
"RedirectTo=302, https://acme.org"
]
}
]
RemoveJsonAttributesResponseBody
Die RemoveJsonAttributesResponseBody Factory entfernt die JSON-Attribute und deren Werte aus JSON-Antworttexten.
Diese Factory akzeptiert die folgenden Konfigurationsparameter:
attribute names: Eine durch Trennzeichen getrennte Liste der Namen von Attributen, die aus einer JSON-Antwort entfernt werden sollen.delete recursively(optional, boolescher Wert): Eine Konfiguration, die die Attribute nur auf Stammebene () oderfalserekursiv (true) entfernt. Der Standardwert istfalse.
Im folgenden Beispiel wird eine RemoveJsonAttributesResponseBody Factory konfiguriert:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"RemoveJsonAttributesResponseBody=origin,foo,true"
]
}
]
RemoveRequestHeader
Die RemoveRequestHeader Factory entfernt einen Header aus der downstream-Anforderung.
Diese Factory akzeptiert den folgenden Konfigurationsparameter:
name: Der Name der zu entfernenden Kopfzeile.
In der folgenden Auflistung wird eine RemoveRequestHeader Factory konfiguriert, die den X-Request-Foo Header entfernt, bevor er nachgelagert gesendet wird:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"RemoveRequestHeader=X-Request-Foo"
]
}
]
RemoveRequestParameter
Die RemoveRequestParameter Factory entfernt einen Parameter, bevor er nach unten gesendet wird.
Diese Factory akzeptiert den folgenden Konfigurationsparameter:
name: Der Name des zu entfernenden Abfrageparameters.
Im folgenden Beispiel wird eine RemoveRequestParameter Factory konfiguriert, die den red Parameter entfernt, bevor er nachgelagert gesendet wird:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"RemoveRequestParameter=red"
]
}
]
RemoveResponseHeader
Die RemoveResponseHeader Factory entfernt einen Header aus der Antwort, bevor sie an den Gatewayclient zurückgegeben wird.
Diese Factory akzeptiert den folgenden Konfigurationsparameter:
name: Der Name der zu entfernenden Kopfzeile.
Die folgende Auflistung konfiguriert eine RemoveResponseHeader Factory, die den X-Response-Foo Header aus der Antwort entfernt, bevor sie an den Gatewayclient zurückgegeben wird:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"RemoveResponseHeader=X-Response-Foo"
]
}
]
RequestHeaderSize
Die RequestHeaderSize Factory bestimmt die Größe des Anforderungsheaders.
Diese Factory akzeptiert die folgenden Konfigurationsparameter:
maxSize: Die vom Anforderungsheader zulässige maximale Datengröße, einschließlich Schlüssel und Wert.errorHeaderName: Der Name des Antwortheaders, der eine Fehlermeldung enthält. Standardmäßig lauteterrorMessageder Name des Antwortheaders .
Die folgende Auflistung konfiguriert eine RequestHeaderSize Factory, die einen Status 431 sendet, wenn die Größe eines Anforderungsheaders größer als 1000 Byte ist:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"RequestHeaderSize=1000B"
]
}
]
RewriteLocationResponseHeader
Die RewriteLocationResponseHeader Factory ändert den Wert des Location Antwortheaders, normalerweise um back-end-spezifische Details zu entfernen.
Diese Factory akzeptiert die folgenden Konfigurationsparameter:
stripVersionMode: Dieser Parameter hat die folgenden möglichen Werte:NEVER_STRIP, ,AS_IN_REQUESTundALWAYS_STRIP. Der Standardwert istAS_IN_REQUEST.NEVER_STRIP: Die Version wird nicht entfernt, auch wenn der ursprüngliche Anforderungspfad keine Version enthält.AS_IN_REQUEST: Die Version wird nur entfernt, wenn der ursprüngliche Anforderungspfad keine Version enthält.ALWAYS_STRIP: Die Version wird immer entfernt, auch wenn der ursprüngliche Anforderungspfad Version enthält.
hostValue: Dieser Parameter wird verwendet, um denhost:portTeil des AntwortheadersLocationzu ersetzen, wenn angegeben. Wenn er nicht angegeben wird, wird der Wert desHostAnforderungsheaders verwendet.protocolsRegex: Ein gültiger regexString, mit dem der Protokollname abgeglichen wird. Wenn sie nicht übereinstimmen, funktioniert der Filter nicht. Der Standardwert isthttp|https|ftp|ftps.locationHeaderName
Die folgende Auflistung konfiguriert eine RewriteLocationResponseHeader Factory:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"RewriteLocationResponseHeader=AS_IN_REQUEST, Location, ,"
]
}
]
In diesem Beispiel wird für einen Anforderungswert des POSTapi.example.com/some/object/nameAntwortheaders der Locationobject-service.prod.example.net/v2/some/object/id Wert neu geschrieben als api.example.com/some/object/id.
Rewritepath
Die RewritePath Factory verwendet reguläre Java-Ausdrücke für eine flexible Methode zum Umschreiben des Anforderungspfads.
Diese Factory akzeptiert die folgenden Konfigurationsparameter:
regexpreplacement
Die folgende Auflistung konfiguriert eine RewritePath Factory:
[
{
"predicates": [
"Path=/red/**"
],
"filters": [
"RewritePath=/red/?(?<segment>.*), /$\\{segment}"
]
}
]
In diesem Beispiel legt diese Konfiguration für einen Anforderungspfad /red/blueden Pfad vor /blue dem Erstellen der downstream-Anforderung fest.
RewriteResponseHeader
Die RewriteResponseHeader Factory verwendet reguläre Java-Ausdrücke für eine flexible Möglichkeit, den Antwortheaderwert umzuschreiben.
Diese Factory akzeptiert die folgenden Konfigurationsparameter:
nameregexpreplacement
Im folgenden Beispiel wird eine RewriteResponseHeader Factory konfiguriert:
[
{
"predicates": [
"Path=/red/**"
],
"filters": [
"RewriteResponseHeader=X-Response-Red, , password=[^&]+, password=***"
]
}
]
In diesem Beispiel wird die Konfiguration für einen Headerwert /42?user=ford&password=omg!what&flag=truefestgelegt /42?user=ford&password=***&flag=true , nachdem die downstream-Anforderung vorgenommen wurde.
SetPath
Die SetPath Factory bietet eine einfache Möglichkeit, den Anforderungspfad zu bearbeiten, indem vorlagenbasierte Segmente des Pfads zugelassen werden. Dieser Filter verwendet die URI-Vorlagen aus Spring Framework und ermöglicht mehrere übereinstimmende Segmente.
Diese Factory akzeptiert den folgenden Konfigurationsparameter:
template
Im folgenden Beispiel wird eine SetPath Factory konfiguriert:
[
{
"predicates": [
"Path=/red/{segment}"
],
"filters": [
"SetPath=/{segment}"
]
}
]
In diesem Beispiel legt diese Konfiguration für einen Anforderungspfad /red/blueden Pfad vor /blue dem Erstellen der downstream-Anforderung fest.
SetRequestHeader
Die SetRequestHeader Factory ersetzt (anstatt alle Kopfzeilen durch den angegebenen Namen hinzuzufügen).
Diese Factory akzeptiert die folgenden Konfigurationsparameter:
namevalue
Die folgende Auflistung konfiguriert eine SetRequestHeader Factory:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"SetRequestHeader=X-Request-Red, Blue"
]
}
]
In diesem Beispiel hat der nachgeschaltete Server mit X-Request-Red:1234, und er wird durch X-Request-Red:Blueersetzt .
Die SetRequestHeader Factory hat Zugriff auf die URI-Variablen, die zum Abgleichen eines Pfads oder Hosts verwendet werden. Sie können URI-Variablen im Wert verwenden, und die Variablen werden zur Laufzeit erweitert.
Im folgenden Beispiel wird eine SetRequestHeader Factory konfiguriert, die eine Variable verwendet:
[
{
"predicates": [
"Path=/api/{segment}"
],
"filters": [
"SetRequestHeader=foo, bar-{segment}"
]
}
]
SetResponseHeader
Die SetResponseHeader Factory ersetzt (anstatt alle Kopfzeilen durch den angegebenen Namen hinzuzufügen).
Diese Factory akzeptiert die folgenden Konfigurationsparameter:
namevalue
Die folgende Auflistung konfiguriert eine SetResponseHeader Factory:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"SetResponseHeader=X-Response-Red, Blue"
]
}
]
In diesem Beispiel hat der nachgeschaltete Server mit X-Response-Red:1234, und er wird durch X-Response-Red:Blueersetzt .
Die SetResponseHeader Factory hat Zugriff auf die URI-Variablen, die zum Abgleichen eines Pfads oder Hosts verwendet werden. Sie können URI-Variablen im Wert verwenden, und die Variablen werden zur Laufzeit erweitert.
Im folgenden Beispiel wird eine SetResponseHeader Factory konfiguriert, die eine Variable verwendet:
[
{
"predicates": [
"Path=/api/{segment}"
],
"filters": [
"SetResponseHeader=foo, bar-{segment}"
]
}
]
SetStatus
Die SetStatus Factory konfiguriert den Antwortstatus der Serveranforderung.
Diese Factory akzeptiert den folgenden Konfigurationsparameter:
status: Ein gültiger SpringwertHttpStatus, der einen ganzzahligen Wert wie404z. B. die Zeichenfolgendarstellung der Aufzählung wie zNOT_FOUND. B. .
Die folgende Auflistung konfiguriert eine SetStatus Factory:
[
{
"predicates": [
"Path=/experimental/**"
],
"filters": [
"SetStatus=UNAUTHORIZED"
]
},
{
"predicates": [
"Path=/unknown/**"
],
"filters": [
"SetStatus=401"
]
}
]
StripPrefix
Die StripPrefix Factory entfernt das Präfix aus der Anforderung, bevor sie nachgelagert gesendet wird.
Diese Factory akzeptiert den folgenden Konfigurationsparameter:
parts: Die Anzahl der Teile im Pfad, die von der Anforderung entfernt werden sollen, bevor sie nachgelagert gesendet wird. Der Standardwert ist 1.
Im folgenden Beispiel wird eine StripPrefix Factory konfiguriert:
[
{
"predicates": [
"Path=/name/**"
],
"filters": [
"StripPrefix=2"
]
}
]
In diesem Beispiel wird eine Anforderung über das Gateway zu /name/blue/red. Die angeforderte nameservice Anforderung wird angezeigt als nameservice/red.
Wiederholen
Die Retry Factory bestimmt die Anzahl der versuchten Wiederholungen.
Diese Factory akzeptiert die folgenden Konfigurationsparameter:
retries: Die Anzahl der Wiederholungen, die versucht werden sollen.statuses: Die HTTP-Statuscodes, die wiederholt werden sollen, dargestellt durch die Verwendungorg.springframework.http.HttpStatus.methods: Die HTTP-Methoden, die wiederholt werden sollen, dargestellt mithilfe vonorg.springframework.http.HttpMethod.series: Die Reihe von Statuscodes, die wiederholt werden sollen, dargestellt durch die Verwendungorg.springframework.http.HttpStatus.Series.exceptions: Die Liste der ausgelösten Ausnahmen, die wiederholt werden sollen.backoff: Der konfigurierte exponentielle Backoff für die Wiederholungen. Wiederholungen werden nach einem Backoffintervall vonfirstBackoff * (factor ^ n), wobeindie Iteration erfolgt. WennmaxBackoffdies konfiguriert ist, ist der maximal angewendete Backoff aufmaxBackoff. WennbasedOnPreviousValuewahr, wird diebackoffBerechnung mithilfeprevBackoff * factorvon .
Die folgenden Standardwerte sind für den Retry Filter konfiguriert, wenn diese aktiviert sind:
retries:Dreimal.series: 5XX Serie.methods: GET-Methode.exceptions:IOExceptionundTimeoutException.backoff:Deaktiviert.
Im folgenden Beispiel wird eine Retry Factory konfiguriert:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"Retry=3,INTERNAL_SERVER_ERROR,GET,10ms,50ms,2,false"
]
}
]
RequestSize
Die RequestSize Fabrik kann einschränken, dass eine Anforderung den nachgelagerten Dienst erreicht, wenn die Anforderungsgröße größer als der zulässige Grenzwert ist.
Diese Factory akzeptiert den folgenden Konfigurationsparameter:
maxSize: EinDataSizeTyp, bei dem Werte als Zahl definiert werden, gefolgt von einem optionalenDataUnitSuffix wieKBoderMB. Der Standardsuffixwert istBfür Bytes. Dies ist die zulässige Größenbeschränkung der anforderung, die in Bytes definiert ist.
Im folgenden Beispiel wird eine RequestSize Factory konfiguriert:
[
{
"predicates": [
"Path=/upload"
],
"filters": [
"RequestSize=5000000"
]
}
]
Wenn die Anforderung in diesem Beispiel aufgrund der Größe abgelehnt wird, legt die RequestSize Factory den Antwortstatus 413 Payload Too Large mit einem anderen Header errorMessagefest.
Das folgende Beispiel zeigt folgendes:errorMessage
errorMessage : Request size is larger than permissible limit. Request size is 6.0 MB where permissible limit is 5.0 MB
TokenRelay
Die TokenRelay Factory leitet ein OAuth2 Zugriffstoken an downstream-Ressourcen weiter. Dieser Filter wird als Wert in der Routendefinition und nicht als boolean expliziter Filter konfiguriert.
Im folgenden Beispiel wird eine TokenRelay Factory konfiguriert:
[
{
"predicates": [
"Path=/api/**"
],
"tokenRelay": true
}
]
Verwenden kommerzieller Filter
Spring Cloud Gateway für Kubernetes bietet auch viele benutzerdefinierte GatewayFilter Fabriken. In den folgenden Abschnitten werden diese Fabriken beschrieben.
AllowedRequestCookieCount
Die AllowedRequestCookieCount Factory bestimmt, ob eine übereinstimmende Anforderung basierend auf der Anzahl der Cookies fortgesetzt werden darf.
Diese Factory akzeptiert den folgenden Konfigurationsparameter:
amount: Die Anzahl der zulässigen Cookies.
Im folgenden Beispiel wird eine AllowedRequestCookieCount Factory konfiguriert:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"AllowedRequestCookieCount=2"
]
}
]
AllowedRequestHeadersCount
Die AllowedRequestHeadersCount Factory bestimmt, ob eine übereinstimmende Anforderung basierend auf der Anzahl der Header fortgesetzt werden darf.
Diese Factory akzeptiert den folgenden Konfigurationsparameter:
amount: Die Anzahl der zulässigen Kopfzeilen.
Im folgenden Beispiel wird eine AllowedRequestHeadersCount Factory konfiguriert:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"AllowedRequestHeadersCount=4"
]
}
]
AllowedRequestQueryParamsCount
Die AllowedRequestQueryParamsCount Factory bestimmt, ob eine übereinstimmende Anforderung basierend auf den Zahlenabfrageparametern fortgesetzt werden darf.
Diese Factory akzeptiert den folgenden Konfigurationsparameter:
amount: Die Anzahl der zulässigen Parameter.
Im folgenden Beispiel wird eine AllowedRequestQueryParamsCount Factory konfiguriert:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"AllowedRequestQueryParamsCount=3"
]
}
]
BasicAuth
Die BasicAuth Factory fügt eine BasicAuthAuthorization Kopfzeile zu Anforderungen hinzu.
Für diese Factory gibt es keine Parameter.
Im folgenden Beispiel wird eine BasicAuth Factory konfiguriert:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"BasicAuth"
]
}
]
ClaimHeader
Die ClaimHeader Factory kopiert Daten aus einem JWT-Anspruch in einen HTTP-Header.
Diese Factory akzeptiert die folgenden Konfigurationsparameter:
Claim name: Der Name der Groß-/Kleinschreibung des zu übergebenden Anspruchs.Header name: Der Name des HTTP-Headers.
Im folgenden Beispiel wird eine ClaimHeader Factory konfiguriert:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"ClaimHeader=sub,X-Claim-Sub"
]
}
]
ClientCertificateHeader
Die ClientCertificateHeader Factory überprüft das X-Forwarded-Client-Cert Headerzertifikat.
Diese Factory akzeptiert die folgenden Konfigurationsparameter:
domain pattern: DerX-Forwarded-Client-CertWert gemäß der Fähigkeit von Kubernetes, die Zertifizierungsstelle des Clientzertifikats zu erkennen.certificate fingerprint(optional): Der Fingerabdruck des TLS/SSL-Zertifikats.
Im folgenden Beispiel wird eine ClientCertificateHeader Factory konfiguriert:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"ClientCertificateHeader=*.example.com,sha-1:aa:bb:00:99"
]
}
]
Cors
Die Cors Factory aktiviert die CORS-Validierungen auf einer Route.
Diese Factory akzeptiert die folgenden Konfigurationsparameter, die als Schlüsselwertpaare für CORS-Optionen organisiert sind:
allowedOriginsallowedMethodsallowedHeadersmaxAgeallowCredentialsallowedOriginPatterns
Im folgenden Beispiel wird eine Cors Factory konfiguriert:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"Cors=[allowedOrigins:https://origin-1,allowedMethods:GET;POST;DELETE,allowedHeaders:*,maxAge:400,allowCredentials:true,allowedOriginPatterns:https://*.test.com:8080]"
]
}
]
JsonToXml
Die JsonToXml Factory transformiert JSON-Antworttext in XML-Antworttext.
Diese Factory akzeptiert den folgenden Konfigurationsparameter:
wrapper: Der Stammtagname für die XML-Antwort, wenn ein anderes Stammtag zum Generieren gültiger XML-Daten erforderlich ist. Der Standardwert istresponse.
Im folgenden Beispiel wird eine JsonToXml Factory konfiguriert:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"JsonToXml=custom-response"
]
}
]
RateLimit
Die RateLimit Factory bestimmt, ob eine übereinstimmende Anforderung basierend auf dem Anforderungsvolumen fortgesetzt werden darf.
Diese Factory akzeptiert die folgenden Konfigurationsparameter:
request limit: Die maximale Anzahl von Anforderungen, die während des Fensters akzeptiert werden.window duration: Die Fensterdauer in Millisekunden. Alternativ können Sie mit densmSuffixen diehDauer in Sekunden, Minuten oder Stunden angeben.partition source(optional): Der Speicherort des Partitionsschlüssels (claim,headeroderIPs).partition key(optional): Der Wert, der zum Partitionieren von Anforderungsindikatoren verwendet wird.
Im folgenden Beispiel wird eine RateLimit Factory konfiguriert:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"RateLimit=1,10s"
]
}
]
Die folgenden Beispiele zeigen andere RateLimit Konfigurationen:
RateLimit=1,10s
RateLimit=1,10s,{claim:client_id}
RateLimit=1,10s,{header:client_id}
RateLimit=2,10s,{IPs:2;127.0.0.1;192.168.0.1}
RestrictRequestHeaders
Die RestrictRequestHeaders Factory bestimmt, ob eine übereinstimmende Anforderung basierend auf den Headern fortgesetzt werden darf.
Wenn http-Header vorhanden sind, die sich nicht in der Konfiguration ohne Groß-/Kleinschreibung headerList befinden, wird eine Antwort an 431 Forbidden error den Client zurückgegeben.
Diese Factory akzeptiert den folgenden Konfigurationsparameter:
headerList: Die Liste der Namen zulässiger Kopfzeilen wird durch Groß-/Kleinschreibung nicht beachtet.
Im folgenden Beispiel wird eine RestrictRequestHeaders Factory konfiguriert:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"RestrictRequestHeaders=Content-Type,x-request-temp"
]
}
]
RewriteAllResponseHeaders
Die RewriteAllResponseHeaders Factory schreibt mehrere Antwortheader gleichzeitig um.
Diese Factory akzeptiert die folgenden Konfigurationsparameter:
pattern to match: Der reguläre Ausdruck, der mit Headerwerten abgeglichen werden soll.replacement: Der Ersetzungswert.
Im folgenden Beispiel wird eine RewriteAllResponseHeaders Factory konfiguriert:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"RewriteAllResponseHeaders=\\d,0"
]
}
]
RewriteResponseBody
Die RewriteResponseBody Factory ändert den Textkörper einer Antwort.
Diese Factory akzeptiert die folgenden Konfigurationsparameter, die als durch Trennzeichen getrennte Liste von Schlüssel-Wert-Paaren organisiert sind, wobei jedes Paar das Formular pattern to match:replacementakzeptiert:
pattern to match: Der reguläre Ausdruck, der mit Text im Antworttext abgeglichen werden soll.replacement: Der Ersetzungswert.
Im folgenden Beispiel wird eine RewriteResponseBody Factory konfiguriert:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"RewriteResponseBody=foo:bar,/path-one/:/path-two/"
]
}
]
RewriteJsonAttributesResponseBody
Die RewriteJsonAttributesResponseBody Factory schreibt JSON-Attribute mithilfe der Schreibweise neu JSONPath .
Diese Factory akzeptiert die folgenden Konfigurationsparameter, die als durch Trennzeichen getrennte Liste von Schlüssel-Wert-Paaren organisiert sind, wobei jedes Paar das Formular jsonpath:replacementakzeptiert:
jsonpath: DerJSONPathAusdruck, der mit dem Antworttext abgeglichen werden soll.replacement: Der Ersetzungswert.
Im folgenden Beispiel wird eine RewriteJsonAttributesResponseBody Factory konfiguriert:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"RewriteJsonAttributesResponseBody=slides[1].title:Welcome,date:11-11-2022"
]
}
]
Rollen
Die Roles Factory autorisiert Anforderungen, die eine der konfigurierten Rollen enthalten.
Diese Factory akzeptiert den folgenden Konfigurationsparameter:
roles: Eine durch Trennzeichen getrennte Liste autorisierter Rollen.
Im folgenden Beispiel wird eine Roles Factory konfiguriert:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"Roles=role_01,role_02"
]
}
]
Bereiche
Die Scopes Factory autorisiert Anforderungen, die einen der konfigurierten OAuth Bereiche enthalten.
Diese Factory akzeptiert den folgenden Konfigurationsparameter:
scopes: Eine durch Trennzeichen getrennte Liste autorisierterOAuthBereiche.
Im folgenden Beispiel wird eine Scopes Factory konfiguriert:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"Scopes=api.read,api.write,user"
]
}
]
StoreIpAddress
Die StoreIPAddress Fabrik wird nur für die Erweiterungsentwicklung und im Kontext der Anwendung verwendet.
Diese Factory akzeptiert den folgenden Konfigurationsparameter:
attribute name: Der Name, der zum Speichern der IP als Exchange-Attribut verwendet wird.
Im folgenden Beispiel wird eine StoreIPAddress Factory konfiguriert:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"StoreIpAddress=ip"
]
}
]
SSO-Anmeldung
Die SSO login Factory leitet zur Authentifizierung um, wenn kein gültiges Autorisierungstoken vorhanden ist. Diese Factory wird als Wert in der Routendefinition und nicht als boolean expliziter Filter konfiguriert.
Im folgenden Beispiel wird eine SSO login Factory konfiguriert:
[
{
"predicates": [
"Path=/api/**"
],
"ssoEnabled": true
}
]
StoreHeader
Die StoreHeader Factory speichert einen Headerwert im Kontext der Anwendung. Dieser Filter wird nur für die Erweiterungsentwicklung verwendet.
Diese Factory akzeptiert die folgenden Konfigurationsparameter:
headers: Eine Liste der zu überprüfenden Kopfzeilen. Die erste gefundene wird verwendet.attribute name: Der Name, der zum Speichern des Headerwerts als Exchange-Attribut verwendet wird.
Im folgenden Beispiel wird eine StoreHeader Factory konfiguriert:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"StoreHeader=x-tracing-header,custom-id,x-custom-id,tracingParam"
]
}
]
XmlToJson
Die XmlToJson Factory wandelt den XML-Antworttext in DEN JSON-Antworttext um.
Für diese Factory gibt es keine Parameter.
Im folgenden Beispiel wird eine XmlToJson Factory konfiguriert:
[
{
"predicates": [
"Path=/api/**"
],
"filters": [
"XmlToJson"
]
}
]
Nächste Schritte
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Tickets als Feedbackmechanismus für Inhalte auslaufen lassen und es durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter: https://aka.ms/ContentUserFeedback.
Einreichen und Feedback anzeigen für