Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

16.09.21 – Versionshinweise zu Apigee Edge for Public Cloud

Sie lesen gerade die Dokumentation zu Apigee Edge.
Zur Dokumentation zu Apigee X. info

Am Donnerstag, 13. Oktober 2016, haben wir mit der Veröffentlichung einer neuen Version von Apigee Edge für die Public Cloud begonnen.

Neue Features und Updates

Im Folgenden sind die neuen Features und Aktualisierungen in diesem Release aufgeführt:

Freigegebene Abläufe und Ablauf-Hooks zur Operationalisierung von API-Proxys (nur auf Anfrage als Beta verfügbar)

Mit dem neuen Feature „Freigegebene Abläufe“ können Sie Funktionen in API-Proxys operationalisieren. Wenn Sie bedingte Richtlinien und Ressourcen in einem freigegebenen Ablauf kombinieren, können Sie von jedem API-Proxy darauf verweisen, um wiederverwendbare Logik aus einer einzigen Quelle auszuführen. Ein freigegebener Ablauf kann beispielsweise den API-Schlüssel überprüfen , vor Spike-Arrests schützen und Daten protokollieren.

Sie definieren freigegebene Abläufe in der Management-UI (APIs > Freigegebene Abläufe) und verweisen dann auf zwei verschiedene Arten darauf:

Mit einer neuen Ablauf-Callout-Richtlinie in einem API-Proxy
In einem neuen Artefakt namens Ablauf-Hooks, das sich an den folgenden Stellen befindet:
- Anfrage: Vor dem ProxyEndpoint PreFlow, nach dem TargetEndpoint PostFlow
- Antwort: Vor dem TargetEndpoint PreFlow, nach dem ProxyEndpoint PostFlow
Mit diesen Anhängepunkten können Sie Betriebslogik vor oder nach den Hauptablauf punkten des einzelnen Proxys ausführen. Sie weisen freigegebene Abläufe diesen Ablauf-Hook-Positionen in der Management-UI zu (APIs > Umgebungskonfiguration > Ablauf-Hooks).

Verschlüsselte Schlüssel/Wert-Zuordnungen

Sie können verschlüsselte Schlüssel/Wert-Zuordnungen (KVMs) erstellen, um vertrauliche Informationen wie Anmeldedaten oder personenbezogene Daten/HIPAA-Daten zu speichern. Diese Funktion unterscheidet sich vom vorhandenen sicheren Speicher von Edge (Vault) und soll ihn ersetzen, da auf Vault-Werte neben der Management API nur mit Node.js zugegriffen werden kann. Sie können mit Node.js oder der Richtlinie für Schlüssel /Wert-Zuordnungen auf verschlüsselte KVM-Werte zugreifen.

Verschlüsselte KVMs erstellen

Verwenden Sie die vorhandenen KVM-APIs. Wenn Sie “encrypted”: “true” in die Nutzlastdefinition einfügen, wenn Sie eine KVM erstellen, verschlüsselt Edge die KVM und generiert einen Verschlüsselungsschlüssel, der denselben Bereich wie die KVM hat.
Sie können die Richtlinie für Schlüssel/Wert-Zuordnungen nicht verwenden, um eine verschlüsselte KVM zu erstellen.
Sie können eine vorhandene unverschlüsselte KVM nicht verschlüsseln.

Verschlüsselte KVMs verwenden

Verwenden Sie die Richtlinie für Schlüssel/Wert-Zuordnungen, um verschlüsselte KVM-Werte abzurufen und zu aktualisieren.
Wenn Sie einen verschlüsselten Schlüsselwert abrufen, stellen Sie der Variablen, die den Wert enthält, das Präfix „private.“ voran. Beispiel: <Get assignTo="private.secretVar">. Die private.secretVar Variable enthält den entschlüsselten Wert.
Wenn Sie einen Wert mit der Richtlinie aktualisieren, müssen Sie nichts Besonderes tun. Der Wert wird in verschlüsselten KVMs automatisch verschlüsselt.
Sie können auch mit dem Modul „apigee-access“ im Node.js-Code auf den entschlüsselten Wert zugreifen. Verwenden Sie die Funktion getKeyValueMap(), um eine KVM anhand des Namens und des Bereichs abzurufen. Für das zurückgegebene Objekt sind zwei Funktionen verfügbar: getKeys(callback) zum Abrufen eines Arrays von Schlüsselnamen und get(key, callback) zum Abrufen des Werts für einen bestimmten Schlüssel. Beispiel:
```
var apigee = require('apigee-access');
  var encryptedKVM = apigee.getKeyValueMap('VerySecureKVM', 'apiproxy');
  encryptedKVM.get('secret1', function(err, secretValue) {
  // use the secret value here
});
```

(APIRT-1197)

Warnung:

KVM-PUT-Vorgänge mit Null-Schlüsseln

Wenn eine Richtlinie für Schlüssel/Wert-Zuordnungen versucht, einen neuen Schlüssel/Wert in einer Schlüssel/Wert-Zuordnung (KVM) mit einem Null-Schlüssel zu PUT, wird der folgende Schlüssel automatisch erstellt: __$$_EDGE_KVM_EMPTY_KEY_$$__

Das ist beispielsweise der Fall, wenn Sie einen Schlüssel mit einem Variablen verweis füllen und die referenzierte Variable null ist. Beim Versuch, neue PUT-Vorgänge mit Null-Schlüsseln zu verwenden, wird nur dieser Schlüssel verwendet, sodass vorhandene Werte für diesen Schlüssel bei jeder Ausführung der Richtlinie möglicherweise überschrieben werden.

Bisher wurde bei einem Null-Schlüssel der Schlüssel/Wert nicht zur KVM hinzugefügt. Stattdessen blieb der Eintrag im In-Memory-Cache des Nachrichtenprozessors und war vorübergehend verfügbar für nachfolgende Get-Vorgänge. Wenn Ihre KVM-Richtlinienimplementierung auf dem vorherigen Verhalten basiert, schlagen Get-Vorgänge für Null-Schlüssel jetzt fehl, da sie nicht auf den neuen Schlüsselnamen (oben) verweisen, der für Null-Schlüssel erstellt wird. (APIRT-3530)

In API-Proxy-Metadaten enthaltene OpenAPI-Spezifikations-URLs

Wenn Sie einen API-Proxy auf Grundlage einer OpenAPI-Spezifikation erstellen, wird der Speicherort der OpenAPI Spezifikation in den API-Proxy-Metadaten gespeichert. Wenn Sie beispielsweise die Management API verwenden, um die Details einer Proxy-Revision abzurufen, enthält die Metadaten den Pfad zur OpenAPI-Spezifikation im folgenden Format:

"spec" : "https://raw.githubusercontent.com/apigee/api-platform-samples/master/default-proxies/helloworld/openapi/mocktarget.yaml"

Diese Verbesserung unterstützt die nächste Generation von Edge, die OpenAPI-Spezifikationen mit API-Proxys, API-Produkten und API-Referenzdokumenten im neuen Entwicklerportal verknüpft. (MGMT-2913)

Client-IP-Steuerung mit Sense

Um genauer zu steuern, wo IP-Adressen für die Sense-Bot-Erkennung zu finden sind, wenn Sie Routing-Produkte wie Akamai verwenden, können Sie mit Sense den Standort der Client-IP mit einer additionalIPVars Variablen definieren. Sie können beispielsweise additionalIPVars so festlegen, dass der true-client-ip Header verwendet wird, der die korrekte IP-Adresse von Akamai enthält, die in Bot-Regeln ausgewertet werden soll. (APIRT-3332)

Fehlerkorrekturen

Folgende Fehler wurden in diesem Release behoben. Diese Liste ist hauptsächlich für Nutzer gedacht, die prüfen möchten, ob ihre Support-Tickets erfolgreich bearbeitet wurden. Sie enthält keine detaillierten Informationen für allgemeine Nutzer.

Problem-ID	Beschreibung
APIRT-3507	Zeitweise auftretende Fehler (z. B. SNI-Fehler) bei JavaScript-Dienst aufrufen
APIRT-3408	MP-Release 160817 verarbeitet Nachrichten mit dem Modul „apigee-access“ für Analysen anders
APIRT-3390	Änderung der Fehlerantwort, die von der Richtlinie zum Aktualisieren des Zugriffstokens zurückgegeben wird Warnung:Änderung des OAuthV2-Fehlercodes „invalid_client“ Beachten Sie die folgende Änderung an einem Fehlercode, der von den OAuthV2-Richtlinienvorgängen GenerateAccessToken und RefreshAccessToken ausgelöst wird, wenn die Eigenschaft <GenerateResponse> der OAuthV2-Richtlinie auf false gesetzt ist: `{"ErrorCode" : "invalid_client", "Error" :"Client identifier is required"}` wurde in Folgendes geändert: `{"ErrorCode" : "InvalidClientIdentifier", "Error" :"Client identifier is required"}` Es wird empfohlen, alle FaultRule-Bedingungen zu ändern, die "`invalid_client`" abfangen, damit sowohl der alte als auch der neue Code erfasst werden. Ändern Sie beispielsweise in Ihrer FaultRule: `(fault.name = "invalid_client")` in Folgendes: `(fault.name = "invalid_client") OR (fault.name = "InvalidClientIdentifier")`
APIRT-3389	Warnung: Fehler beim Hochladen von Node.js-Nutzlasten über 25 KB Das Hochladen von Node.js-Nutzlasten über 25 KB ist jetzt zulässig.
APIRT-3381	Hohe Latenzen bei Produktionsproxys von Kunden
APIRT-3366	JavaScript-Richtlinien schlagen bei allen neuen Testorganisationen fehl
APIRT-3363	Bei ungültigem URL-Parsing wird der Status 500 mit ApplicationNotFound zurückgegeben
APIRT-3356	OAuth-Meldung zu ungültigem Token
APIRT-3355	Zeitweise auftretender 403-Fehler bei OAuth-Proxy
APIRT-3285	Warnung: Inkonsistenter Ablauf von OAuth2-Tokens Wenn Sie ein OAuth-Token mit der OAuth v2.0-Richtlinie generieren, können Sie den Ablauf des Tokens entweder per Verweis oder mit einem fest codierten Standardwert festlegen. Beispiel: `<ExpiresIn ref="kvm.oauth.expires_in">1800000</ExpiresIn>`. Als der Ablauf des Tokens zum ersten Mal per Verweis festgelegt wurde, hat Edge diesen Wert für jeden neuen Ablauf des Tokens gespeichert und verwendet. Dieser Fehler wurde behoben, sodass entweder der Referenzwert oder, falls kein Referenz wert angegeben ist, der in der Richtlinie definierte Standardablauf verwendet wird. Diese Korrektur kann die Dauer des Ablaufs Ihrer Tokens ändern. Es können Nebenwirkungen auftreten, z. B. mehr Fehler aufgrund ungültiger Tokens. In diesem Fall müssen Sie möglicherweise häufigere Token-Aktualisierungen implementieren oder den Standardablauf in Ihren OAuth-Richtlinien ändern.
APIRT-3261	Anmeldedaten werden in der Produktion mit einer anderen Entwickler-App validiert
APIRT-3234	Node.js-App gibt NPE zurück
APIRT-3223	Problem mit veraltetem Apigee-Cache
APIRT-3193	Node.js-Zielserver hängt nach dem Umzug zu ASG
APIRT-3152	Management-Aufruf von „cachedlogs“ führt dazu, dass Protokollmeldungen aufgeteilt werden
APIRT-3117	MP hat 100% CPU-Auslastung erreicht und verarbeitet keinen Traffic mehr
APIRT-3064	Router: benutzerdefinierte 503-Fehlermeldung vom Router
APIRT-2620	Separate Threadpools für einige blockierende Schritte zur Verbesserung der Last verteilung
CORESERV-774	Zugriff mit gültigem Schlüssel und ungültigem Verweis auf ein API-Produkt führt zu einem internen Server fehler