Cette page a été traduite par l'API Cloud Translation.

16.09.21 : Notes de version d'Apigee Edge pour le cloud public

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

Le jeudi 13 octobre 2016, nous avons commencé à publier une nouvelle version d'Apigee Edge pour Google Cloud.

Nouvelles fonctionnalités et mises à jour

Vous trouverez ci-dessous les nouvelles fonctionnalités et mises à jour offertes par cette version.

Partagées Flux et hooks de flux pour opérationnaliser les proxys d'API (bêta par requête uniquement)

Un nouveau "Flux partagés" fonctionnalité vous permet d'opérationnaliser une fonctionnalité dans les mandataires d'API. Par combinant des règles et des ressources conditionnelles dans un flux partagé, vous pouvez le référencer n'importe quel proxy d'API pour exécuter une logique à source unique et réutilisable. Par exemple, un flux partagé peut vérifier la clé API, la protection contre les arrestations de pics et les données de journal.

Définissez les flux partagés dans l'interface utilisateur de gestion (API > Flux partagés), puis les référencer de deux manières différentes:

Avec une nouvelle règle d'appel de flux dans un proxy d'API
ou
Sur un nouvel artefact appelé hooks de flux, qui se trouvent aux emplacements suivants:
- Requête: avant le PreFlow du ProxyEndpoint, après le TargetEndpoint PostFlow
- Réponse: Avant le PreFlow de TargetEndpoint, après le ProxyEndpoint PostFlow
Ces points d'attache vous permettent d'exécuter une logique opérationnelle avant ou après le flux principal les points de terminaison du proxy individuel. Vous attribuez des flux partagés à ces emplacements de hook de flux dans la section (API > Environment Configuration > Flow Hooks [API > Configuration de l'environnement > Hooks de flux]).

Mappages de clés-valeurs chiffrées

Vous pouvez créer des cartes KVM (Key Value Map) chiffrées pour stocker des informations sensibles telles que ou des informations personnelles/HIPAA. Cette fonctionnalité est différente du stockage sécurisé Edge existant (vault) et est conçu pour le remplacer, car les valeurs Vault ne sont accessibles qu'avec Node.js (dans en plus de l'API de gestion). Vous pouvez accéder aux valeurs KVM chiffrées avec Node.js ou la clé Règle Opérations sur la carte de valeur.

Créer des KVM chiffrées

Utiliser les API KVM existantes Lorsque vous incluez “encrypted”: “true” dans la définition de la charge utile lors de la création d'une KVM, Edge chiffre la KVM et génère une clé de chiffrement ayant le même champ d'application que la KVM.
Vous ne pouvez pas utiliser la règle Opérations de mappage de valeurs clés pour créer une KVM chiffrée.
Vous ne pouvez pas chiffrer une KVM non chiffrée existante.

Utiliser des KVM chiffrées

Utilisez la règle Opérations de mappage de valeurs clés pour obtenir et mettre à jour les valeurs KVM chiffrées.
Lorsque vous obtenez une valeur de clé chiffrée, ajoutez le préfixe "private" à la variable pour qu'elle contienne cette valeur. Exemple : <Get assignTo="private.secretVar">. Cela La variable private.secretVar contient la valeur déchiffrée.
Lorsque vous mettez à jour une valeur avec la règle, aucune action spéciale n'est requise. La valeur seront chiffrés automatiquement dans des KVM chiffrées.
Vous pouvez également accéder à la valeur déchiffrée à l'aide du module "apigee-access" dans le code Node.js. Utilisez La fonction getKeyValueMap() pour récupérer une KVM en fonction de son nom et de son champ d'application Deux des fonctions sont disponibles sur l'objet renvoyé: getKeys(callback) pour obtenir un tableau. de noms de clés et get(key, callback) pour obtenir la valeur d'une clé particulière. Exemple :
```
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> Avertissement:

Opérations PUT KVM avec des clés nulles

Si une règle d'opérations de mappage de valeurs clés tente d'exécuter la méthode PUT dans un mappage de clé-valeur (KVM) à l'aide d'une clé nulle, la clé suivante est créée automatiquement: __$$_EDGE_KVM_EMPTY_KEY_$$__

Cette situation se produit, par exemple, si vous insérez une clé à l'aide d'une référence de variable et que la variable référencée est nulle. Lors de l'exécution de nouvelles opérations PUT contenant des clés nulles, seule cette clé est utilisée. Les valeurs existantes de cette clé sont donc potentiellement écrasées à chaque exécution de la règle.

Auparavant, pour une clé nulle, la clé/valeur n'était pas ajoutée à la KVM. Au lieu de cela, l'entrée est restée dans le cache en mémoire du processeur de messages et a été temporairement disponibles pour les opérations Get ultérieures. Si l'implémentation de votre stratégie KVM repose sur précédent, les opérations Get sur des clés nulles échoueront maintenant, car elles ne font pas référence le nouveau nom de clé (ci-dessus) créé pour les clés nulles. (APIRT-3530).

URL des spécifications OpenAPI inclus dans les métadonnées du proxy d'API

Lorsque vous créez un proxy d'API basé sur une spécification OpenAPI, l'emplacement du La spécification est stockée dans les métadonnées du proxy d'API. Par exemple, si vous utilisez l'API de gestion pour obtenir d'une révision de proxy, les métadonnées incluent le chemin d'accès à la spécification OpenAPI dans format:

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

Cette amélioration prend en charge la version nouvelle génération d'Edge, qui associe les spécifications OpenAPI à Proxys d'API, produits d'API et documents de référence des API dans le nouveau portail des développeurs (MGMT-2913)

Contrôle des adresses IP client avec Sense

Afin de contrôler plus précisément où trouver les adresses IP pour la détection des bots Sense lorsque à l'aide de produits de routage tels qu'Akamai, Sense vous permet de définir l'emplacement de l'adresse IP du client avec Une variable additionalIPVars. Par exemple, vous pouvez définir additionalIPVars d'utiliser l'en-tête true-client-ip, qui contient l'adresse IP correcte d'Akamai vers à évaluer dans les règles de bot. (APIRT-3332).

Bugs résolus

Les bugs suivants sont résolus dans cette version. Cette liste s'adresse principalement aux utilisateurs qui veulent vérifier si leurs demandes d'assistance ont été corrigées. Elle n'est pas conçue pour fournir des informations détaillées à tous les utilisateurs.

ID du problème	Description
APIRT-3507	Erreurs intermittentes (telles que les erreurs SNI) sur le service JavaScript accroches
APIRT-3408	Module d'analyse d'accès Apigee version 160817 du MP traitant les messages différemment
APIRT-3390	Modification de la réponse d'erreur renvoyée par la stratégie d'actualisation des jetons d'accès <ph type="x-smartling-placeholder"> </ph> Avertissement:Modification du code d'erreur OAuthV2 "invalid_client". Notez la modification suivante apportée à un code d'erreur généré par les opérations de la stratégie OAuthV2. <ph type="x-smartling-placeholder"></ph> GenerateAccessToken et RefreshAccessToken lorsque la propriété <GenerateResponse> de la règle OAuthV2 est définie sur false: `{"ErrorCode" : "invalid_client", "Error" :"Client identifier is required"}` a été remplacé par: `{"ErrorCode" : "InvalidClientIdentifier", "Error" :"Client identifier is required"}` Il est recommandé de modifier les conditions des règles d'erreur "`invalid_client`" pour détecter à la fois l'ancien et le nouveau code. Pour exemple, dans votre règle de faute, remplacez: `(fault.name = "invalid_client")` par: `(fault.name = "invalid_client") OR (fault.name = "InvalidClientIdentifier")`
APIRT-3389	Avertissement:Erreur lors du chargement des charges utiles Node.js sur 25 Ko L'importation de charges utiles Node.js de plus de 25 Ko est désormais autorisée.
APIRT-3381	Latences élevées sur les proxys de production client
APIRT-3366	Les règles JavaScript ne fonctionnent pas dans toutes les nouvelles organisations en phase d'essai
APIRT-3363	L'analyse des URL non valides renvoie un état 500 avec ApplicationNotFound
APIRT-3356	Message de jeton OAuth non valide
APIRT-3355	Erreur 403 intermittente sur le proxy OAuth
APIRT-3285	Avertissement:Jeton OAuth2 incohérent expiration Lors de la génération d'un jeton OAuth à l'aide de la règle OAuth v2.0, vous pouvez définir le jeton soit par référence, soit par défaut codée en dur. Exemple : `<ExpiresIn ref="kvm.oauth.expires_in">1800000</ExpiresIn>`. La première fois que le jeton expiration a été définie par référence, Edge a stocké et utilisé cette valeur pour chaque nouveau jeton la date d'expiration. Ce bug a été corrigé afin d'utiliser la valeur de référence ou, en l'absence de référence, est fournie, le délai d'expiration par défaut défini dans la stratégie. Ce correctif est susceptible de changer la durée d'expiration de vos jetons, et vous risquez de rencontrer des effets secondaires, les erreurs de jeton non valide, ce qui peut vous obliger à mettre en œuvre des actualisations de jeton plus fréquentes ou modifier le délai d'expiration par défaut dans vos règles OAuth.
APIRT-3261	Les identifiants sont validés par rapport à une autre application de développement en production
APIRT-3234	L'application Node.js renvoie une exception NPE
APIRT-3223	Problème de cache Apigee non actualisé
APIRT-3193	Le serveur cible Node.js est suspendu après son déplacement vers ASG
APIRT-3152	L'appel de gestion cachedlogs entraîne la rupture des messages de journal
APIRT-3117	La MP a atteint 100% d'utilisation du processeur et a cessé de diffuser le trafic
APIRT-3064	Routeur : message d'erreur 503 personnalisé du routeur
APIRT-2620	Pool de threads distinct pour certaines étapes bloquantes afin d'améliorer la charge de traitement
CORESERV-774	L'accès à l'aide d'une clé valide avec une référence de produit d'API non valide entraîne un serveur interne aïe !"