Diese Seite wurde von der Cloud Translation API übersetzt.

16.09.21 – Versionshinweise zu Apigee Edge for Public Cloud

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation. Weitere Informationen

Am Donnerstag, dem 13. Oktober 2016, haben wir mit der Veröffentlichung einer neuen Version von Apigee Edge for Public begonnen. Cloud

Neue Features und Updates

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

Freigegeben Abläufe und Fluss-Hooks zum Operationalisieren von API-Proxys (nur Beta für Anfrage)

Eine neue Funktion „Shared Flows“ können Sie Funktionen in API-Proxys operationalisieren. Von Wenn Sie bedingte Richtlinien und Ressourcen in einem freigegebenen Ablauf kombinieren, können Sie darauf verweisen. einen beliebigen API-Proxy, um wiederverwendbare Einzelquelllogik auszuführen. Ein freigegebener Ablauf kann z. B. überprüfen, den API-Schlüssel, Schutz vor Spike Arrest und Protokolldaten.

Freigegebene Abläufe werden in der Verwaltungsoberfläche definiert (APIs > Freigegebene Abläufe) und auf zwei verschiedene Arten zu verweisen:

Mit einer neuen Flow Callout-Richtlinie in einem API-Proxy
oder
Auf einem neuen Artefakt namens Flow Hooks an den folgenden Stellen:
- Anfrage: Vor dem ProxyEndpoint PreFlow, nach dem TargetEndpoint PostFlow
- Antwort: Vor dem TargetEndpoint PreFlow, nach dem ProxyEndpoint PostFlow
Mit diesen Verbindungspunkten können Sie die operative Logik vor oder nach dem Hauptablauf ausführen des einzelnen Proxys. Sie weisen diesen Flow Hook-Positionen freigegebene Abläufe in der Verwaltungsoberfläche (APIs > Umgebungskonfiguration > Ablauf-Hooks) angezeigt.

Verschlüsselte Schlüssel/Wert-Zuordnungen

Sie können verschlüsselte Schlüssel/Wert-Zuordnungen (KVMs) zum Speichern vertraulicher Informationen wie Anmeldedaten oder personenidentifizierbare Informationen/HIPAA-Daten enthalten. Diese Funktion unterscheidet sich vom vorhandenen Edge Secure Store. (Vault) und soll diesen ersetzen, da Vault-Werte nur mit Node.js (in der Verwaltungs-API). Sie können mit Node.js oder dem Schlüssel auf verschlüsselte KVM-Werte zugreifen Richtlinie für Wertzuordnungsvorgänge.

Verschlüsselte KVMs erstellen

Verwenden Sie die vorhandenen KVM APIs. Wenn Sie beim Erstellen einer KVM “encrypted”: “true” in die Nutzlastdefinition aufnehmen, verschlüsselt Edge die KVM und generiert einen Verschlüsselungsschlüssel mit demselben Bereich wie die KVM.
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 ein verschlüsseltes Schlüssel/Wert-Paar abrufen, stellen Sie der Variablen das Präfix „private“ voran. Beispiel: <Get assignTo="private.secretVar">. Das Die Variable private.secretVar enthält den entschlüsselten Wert.
Wenn Sie einen Wert mit der Richtlinie aktualisieren, müssen Sie nichts weiter tun. Der Wert werden in verschlüsselten KVMs automatisch verschlüsselt.
Sie können auch mithilfe des Moduls „apigee-access“ im Node.js-Code auf den entschlüsselten Wert zugreifen. Verwenden Sie die Funktion getKeyValueMap(), um eine KVM basierend auf dem Namen und dem Bereich abzurufen Zwei Funktionen sind für das zurückgegebene Objekt getKeys(callback) verfügbar, um ein Array abzurufen. und get(key, callback), um den Wert für einen bestimmten Schlüssel abzurufen. 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)

</ph> Warnung:

KVM-PUT-Vorgänge mit Nullschlüsseln

Wenn eine Richtlinie für Schlüsselwertzuordnungsoperationen versucht, einen in einer Schlüsselwertzuordnung (KVM) mithilfe eines Nullschlüssels einen neuen Schlüssel/Wert erstellen, wird der folgende Schlüssel automatisch erstellt: __$$_EDGE_KVM_EMPTY_KEY_$$__

Das ist beispielsweise der Fall, wenn Sie einen Schlüssel mit einem Variablenverweis 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.

Das bisherige Verhalten für einen Null-Schlüssel war, dass der Schlüssel/Wert nicht zur KVM hinzugefügt wurde. Stattdessen blieb der Eintrag im In-Memory-Cache des Nachrichtenprozessors und wurde vorübergehend für nachfolgende Get-Vorgänge zur Verfügung. Wenn Ihre KVM-Richtlinienimplementierung das vorherigen Verhaltens schlagen Get-Vorgänge für Null-Schlüssel fehl, da sie nicht auf Den neuen Schlüsselnamen (oben), der für Nullschlüssel erstellt wird. (APIRT-3530)

OpenAPI-Spezifikations-URLs in API-Proxy-Metadaten enthalten

Wenn Sie einen API-Proxy basierend auf einer OpenAPI-Spezifikation erstellen, wird der Speicherort der OpenAPI Die Spezifikation wird in den API-Proxy-Metadaten gespeichert. Wenn Sie beispielsweise die Verwaltungs-API verwenden, um die Details zu einer Proxyversion enthalten sind, enthalten die Metadaten den Pfad zur OpenAPI-Spezifikation im folgenden Abschnitt: Format:

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

Diese Verbesserung unterstützt die Edge-Version der nächsten Generation, die OpenAPI-Spezifikationen mit API-Proxys, API-Produkte und API-Referenzdokumente im neuen Entwicklerportal. (MGMT-2913)

Client-IP-Steuerung mit Sense

Um genauer steuern zu können, wo IP-Adressen für die Sense-Bot-Erkennung zu finden sind, Mit Routing-Produkten wie Akamai können Sie mit Sense den Standort der Client-IP-Adresse eine additionalIPVars-Variable. Sie können beispielsweise additionalIPVars festlegen. wird der true-client-ip-Header verwendet, der die korrekte IP-Adresse von Akamai an in Bot-Regeln auszuwerten. (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	Zeitweilige Fehler (wie SNI-Fehler) im JavaScript-Dienst Erweiterungen mit Zusatzinformationen
APIRT-3408	MP-Version 160817 des Apigee-Access-Analysemoduls zur Verarbeitung von Meldungen anders
APIRT-3390	Änderung der Fehlerantwort, die durch die Richtlinie zum Aktualisieren des Zugriffstokens zurückgegeben wird <ph type="x-smartling-placeholder"> </ph> Warnung: Änderung des OAuthV2-Fehlercodes "invalid_client". Beachten Sie die folgende Änderung eines Fehlercodes, der von den OAuthV2-Richtlinienvorgängen ausgegeben wird <ph type="x-smartling-placeholder"></ph> GenerateAccessToken und RefreshAccessToken ausführen, wenn Das Attribut <GenerateResponse> der OAuthV2-Richtlinie ist auf false: `{"ErrorCode" : "invalid_client", "Error" :"Client identifier is required"}` wurde geändert zu: `{"ErrorCode" : "InvalidClientIdentifier", "Error" :"Client identifier is required"}` Es wird empfohlen, alle Fehlerregelbedingungen zu ändern, die eine „`invalid_client`“ um sowohl die alten als auch die neuen Codes zu erfassen. Für Ändern Sie beispielsweise in Ihrer Fehlerregel: `(fault.name = "invalid_client")` in: `(fault.name = "invalid_client") OR (fault.name = "InvalidClientIdentifier")`
APIRT-3389	Warnung:Fehler beim Hochladen von Node.js-Nutzlasten über 25KB 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 der Analyse ungültiger URLs wird der Status 500 mit ApplicationNotFound zurückgegeben
APIRT-3356	OAuth-Token-Nachricht
APIRT-3355	Zeitweiliger Fehler 403 auf OAuth-Proxy
APIRT-3285	Warnung: Inkonsistentes OAuth2-Token Ablauf Beim Generieren eines OAuth-Tokens mithilfe der OAuth v2.0-Richtlinie können Sie das Token entweder durch Verweis oder einen hartcodierten Standardwert. Beispiel: `<ExpiresIn ref="kvm.oauth.expires_in">1800000</ExpiresIn>`. Das erste Mal, dass das Token Ablauf wurde durch Verweis festgelegt, Edge hat diesen Wert für jedes neue Token gespeichert und verwendet Gültigkeit haben. Für diesen Fehler wurde entweder der Referenzwert oder, wenn keine Referenz vorhanden ist, verwendet. angegeben wird, die in der Richtlinie festgelegte Standardablaufzeit. Diese Korrektur kann sich ändern die Dauer des Ablaufs Ihres Tokens erhöhen. Dies kann zu Nebenwirkungen wie Fehler wegen ungültiger Tokens, die eine häufigere Aktualisierung von Tokens oder ändern Sie die Standardablaufzeit in Ihren OAuth-Richtlinien.
APIRT-3261	Anmeldedaten werden anhand einer anderen Entwicklungsanwendung in der Produktion 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 Verschieben zu ASG
APIRT-3152	Verwaltungsaufruf von im Cache gespeicherten Logs führt dazu, dass Lognachrichten aufgeteilt werden
APIRT-3117	MP hat eine CPU-Auslastung von 100% erreicht und stellt keinen Traffic mehr bereit
APIRT-3064	Router: Benutzerdefinierte Fehlermeldung 503 von einem Router
APIRT-2620	Separaten Thread-Pool für einige Blockierschritte zur Verbesserung der Last Umgang
CORESERV-774	Zugriff über einen gültigen Schlüssel mit einer ungültigen API-Produktreferenz führt zu einem internen Server Fehler