Notes de version d'Edge MicroGate

Vous consultez la documentation d'Apigee Edge.
Accédez à la documentation Apigee X. info

Version 3.3.x

Correction de bugs et améliorations v.3.3.x

3.3.7

Le 17 juillet 2025, nous avons publié les correctifs et améliorations suivants pour Edge Microgateway.

Correction de bugs et améliorations :

edgemicro:
  plugins:
    excludeUrls: '/hello,/proxy_one/*' # global exclude urls
    sequence:
      -oauth
      -json2xml
      -quota
      -json2xml:
          excludeUrls: '/hello/xml/*'  # plugin level exclude urls

Problèmes de sécurité résolus

• CVE-2024-12905
• CVE-2025-46653

3.3.6

Le 16 avril 2025, nous avons publié les correctifs et améliorations suivants pour Edge Microgateway.

Versions des composants :

Le tableau suivant liste les numéros de version des projets de composants individuels associés à Edge Microgateway 3.3.6. Notez que, comme chaque composant est un projet distinct, les numéros de version peuvent ne pas correspondre à la version principale du produit :

Problèmes de sécurité résolus

• CVE-2025-27789
• CVE-2024-21538
• CVE-2024-12133

3.3.5

Le vendredi 20 décembre 2024, nous avons publié les correctifs et améliorations suivants pour Edge Microgateway.

Versions des composants :

Le tableau suivant répertorie les numéros de version des projets de composants individuels associés à Edge Microgateway 3.3.5. Notez que, comme chaque composant est un projet distinct, les numéros de version peuvent ne pas correspondre à la version principale du produit :

Correction de bugs et améliorations :

current nodejs version is  18.x.x Note, v18.x.x will be out of support soon, see https://docs.apigee.com/release/notes/edge-microgateway-release-notes-0

You are using a version of NodeJS that is not supported

Problèmes de sécurité résolus

• CVE-2024-21538
• CVE-2024-45590
• CVE-2019-3844
• CVE-2019-12290
• CVE-2020-1751
• CVE-2018-12886
• CVE-2023-50387
• CVE-2019-3843
• CVE-2022-4415
• CVE-2021-3997

3.3.4

Le 18 septembre 2024, nous avons publié les correctifs et améliorations suivants pour Edge Microgateway.

Versions des composants :

Le tableau suivant répertorie les numéros de version des projets de composants individuels associés à Edge Microgateway 3.3.4. Notez que, comme chaque composant est un projet distinct, les numéros de version peuvent ne pas correspondre à la version principale du produit :

Correction de bugs et améliorations :

Problèmes de sécurité résolus

• CVE-2021-23337
• CVE-2024-4068
• CVE-2020-28469
• CVE-2020-28503

3.3.3

Le 25 avril 2024, nous avons publié les correctifs et améliorations suivants pour Edge Microgateway.

Versions des composants :

Le tableau suivant répertorie les numéros de version des projets de composants individuels associés à Edge Microgateway 3.3.3. Notez que, comme chaque composant est un projet distinct, les numéros de version peuvent ne pas correspondre à la version principale du produit :

Correction de bugs et améliorations :

Problèmes de sécurité résolus

• CVE-2023-0842
• CVE-2023-26115
• CVE-2022-25883
• CVE-2017-20162
• CVE-2022-31129
• CVE-2022-23539
• CVE-2022-23541
• CVE-2022-23540
• CVE-2024-21484
• CVE-2022-46175
• CVE-2023-45133
• CVE-2020-15366
• CVE-2023-26136
• CVE-2023-26115

3.3.2

Le 18 août 2023, nous avons publié les corrections et améliorations suivantes pour Edge Microgateway.

Versions des composants :

Le tableau suivant répertorie les numéros de version des projets de composants individuels associés à Edge Microgateway 3.3.2. Notez que, comme chaque composant est un projet distinct, les numéros de version peuvent ne pas correspondre à la version principale du produit :

Correction de bugs et améliorations :

Problèmes de sécurité résolus

Aucune.

3.3.1

Le 7 juin 2022, nous avons publié les correctifs et améliorations suivants pour Edge Microgateway.

Versions des composants :

Le tableau suivant répertorie les numéros de version des projets de composants individuels associés à Edge Microgateway 3.3.1. Notez que, comme chaque composant est un projet distinct, les numéros de version peuvent ne pas correspondre à la version principale du produit :

Correction de bugs et améliorations :

Problèmes de sécurité résolus

3.3.0

Le 4 février 2022, nous avons publié les corrections et améliorations suivantes pour Edge Microgateway.

Versions des composants :

Le tableau suivant répertorie les numéros de version des projets de composants individuels associés à Edge Microgateway 3.3.0. Notez que, comme chaque composant est un projet distinct, les numéros de version peuvent ne pas correspondre à la version principale du produit :

Correction de bugs et améliorations :

npm install apigeetool@0.15.1

Version 3.2.x

Correction de bugs et améliorations v.3.2.x

3.2.3

Le 17 septembre 2021, nous avons publié les correctifs et améliorations suivants pour Edge Microgateway.

Versions des composants :

Le tableau suivant répertorie les numéros de version des projets de composants individuels associés à Edge Microgateway 3.2.3. Notez que, comme chaque composant est un projet distinct, les numéros de version peuvent ne pas correspondre à la version principale du produit :

Correction de bugs et améliorations :

Problèmes de sécurité résolus

3.2.2

Le jeudi 15 juillet 2021, nous avons publié les correctifs et améliorations suivants pour Edge Microgateway.

Versions des composants :

Le tableau suivant répertorie les numéros de version des projets de composants individuels associés à Edge Microgateway 3.2.2. Notez que, comme chaque composant est un projet distinct, les numéros de version peuvent ne pas correspondre à la version principale du produit :

Correction de bugs et améliorations :

Problèmes de sécurité résolus

3.2.1

Le vendredi 5 mars 2021, nous avons publié les correctifs et améliorations suivants pour Edge Microgateway.

Versions des composants :

Le tableau suivant répertorie les numéros de version des projets de composants individuels associés à Edge Microgateway 3.2.1. Notez que, comme chaque composant est un projet distinct, les numéros de version peuvent ne pas correspondre à la version principale du produit :

Correction de bugs et améliorations :

edgemicro:
 enable_GET_req_body: true

3.2.0

Le jeudi 21 janvier 2021, nous avons publié les correctifs et améliorations suivants pour Edge Microgateway.

Versions des composants :

Le tableau suivant liste les numéros de version des projets de composants individuels associés à Edge Microgateway 3.2.0. Notez que, comme chaque composant est un projet distinct, les numéros de version peuvent ne pas correspondre à la version principale du produit :

Correction de bugs et améliorations :

Version 3.1.x

Correction de bugs et améliorations v.3.1.x

3.1.8

Le lundi 16 novembre 2020, nous avons publié les correctifs et améliorations suivants pour Edge Microgateway.

Versions des composants :

Le tableau suivant répertorie les numéros de version des projets de composants individuels associés à Edge Microgateway 3.1.8. Notez que, comme chaque composant est un projet distinct, les numéros de version peuvent ne pas correspondre à la version principale du produit :

Correction de bugs et améliorations :

3.1.7

Le jeudi 24 septembre 2020, nous avons publié les correctifs et améliorations suivants pour Edge Microgateway.

Versions des composants :

Le tableau suivant répertorie les numéros de version des projets de composants individuels associés à Edge Microgateway 3.1.7. Notez que, comme chaque composant est un projet distinct, les numéros de version peuvent ne pas correspondre à la version principale du produit :

Correction de bugs et améliorations :

{"message":"write after end","code":"ERR_STREAM_WRITE_AFTER_END"}

3.1.6

Le jeudi 20 août 2020, nous avons publié les correctifs et améliorations suivants pour Edge Microgateway.

Versions des composants :

Le tableau suivant répertorie les numéros de version des projets de composants individuels associés à Edge Microgateway 3.1.6. Notez que, comme chaque composant est un projet distinct, les numéros de version peuvent ne pas correspondre à la version principale du produit :

Correction de bugs et améliorations :

3.1.5

Le vendredi 26 juin 2020, nous avons publié les correctifs et améliorations suivants pour Edge Microgateway.

Versions des composants :

Le tableau suivant répertorie les numéros de version des projets de composants individuels associés à Edge Microgateway 3.1.5. Notez que, comme chaque composant est un projet distinct, les numéros de version peuvent ne pas correspondre à la version principale du produit :

Correction de bugs et améliorations :

3.1.4

Le vendredi 23 avril 2020, nous avons publié le correctif suivant pour Edge Microgateway.

Correction de bug :

Un problème de dépendance dans la version 3.1.3 a été résolu. La version 3.1.3 a été marquée comme obsolète dans le dépôt npm. Sinon, tous les correctifs et améliorations décrits dans les notes de version 3.1.3 s'appliquent à cette version.

3.1.3

Le mercredi 15 avril 2020, nous avons publié les correctifs et améliorations suivants pour Edge Microgateway.

Versions des composants :

Le tableau suivant répertorie les numéros de version des projets de composants individuels associés à Edge Microgateway 3.1.3. Notez que, comme chaque composant est un projet distinct, les numéros de version peuvent ne pas correspondre à la version principale du produit :

Correction de bugs et améliorations :

• 153509313 : correction d'un problème lié au module de débogage Node.js qui entraînait des fuites de mémoire. Ce problème existe dans les versions 3.1.0, 3.1.1 et 3.1.2.
• 153509313 : un problème a été résolu, qui entraînait l'affichage du même ID de message pour deux transactions différentes dans la sortie de journalisation.
• 151673570 : un problème a été résolu, qui empêchait Edge Microgateway d'être mis à jour pour utiliser les nouvelles API KVM Apigee. Edge Microgateway utilise désormais les nouvelles commandes pour ajouter et mettre à jour les valeurs KVM.
• 152822846 : dans les versions précédentes, Edge Microgateway a été mis à jour afin que le traitement du mappage des chemins de ressources corresponde à celui d'Apigee Edge. Dans cette version, un problème a été résolu. Il empêchait le modèle /literal_string/* d'être géré correctement. Exemple : /*/2/*. Consultez également Configurer le comportement d'un chemin de ressource de '/', '/*' et '/**'.
• 152005003 : des modifications ont été apportées pour activer les identifiants à portée d'organisation et d'environnement pour les quotas.
• 152005003 : des modifications ont été apportées pour activer les identifiants à portée d'organisation et d'environnement pour les quotas. La combinaison "org + env + appName + productName" est utilisée comme identifiant de quota.

3.1.2

Le lundi 16 mars 2020, nous avons publié les corrections et améliorations suivantes pour Edge Microgateway.

Versions des composants :

Le tableau suivant répertorie les numéros de version des projets de composants individuels associés à Edge Microgateway 3.1.3. Notez que, comme chaque composant est un projet distinct, les numéros de version peuvent ne pas correspondre à la version principale du produit :

Correction de bugs et améliorations :

• 151285018 : une amélioration a été apportée pour ajouter la compatibilité avec le proxy HTTP pour le trafic entre Edge Microgateway et les cibles de backend. De plus, des problèmes ont été résolus concernant la prise en charge du proxy HTTP existant entre Edge Microgateway et Apigee Edge. Pour en savoir plus, consultez :
  • Utiliser un proxy HTTP pour communiquer avec Apigee Edge
  • Utiliser un proxy HTTP pour la communication cible
• 149101890 : le code de notification du journal pour les cas où le serveur cible ou l'équilibreur de charge ferme sa connexion est passé d'ERROR à INFO.
• 150746985 : correction d'un problème qui empêchait la commande edgemicro verify de fonctionner correctement si redisBasedConfigCache: true ou quotaUri: https://%s-%s.apigee.net/edgemicro-auth étaient présents dans le fichier de configuration.
• 151284716 : une amélioration a été apportée pour fermer plus rapidement les connexions au serveur lorsque les workers sont redémarrés lors d'un rechargement.
• 151588764 : mettre à jour la version de Node.js dans l'image Docker utilisée pour exécuter Edge Microgateway dans un conteneur Docker vers la version 12, car Node.js v8 est obsolète.
• 151306049 : la documentation a été mise à jour pour lister les API de gestion Apigee Edge utilisées par les commandes CLI Edge Microgateway. Consultez Quelles API de gestion Edge Microgateway utilise-t-il ?.

3.1.1

Le jeudi 20 février, nous avons publié les correctifs et améliorations suivants pour Edge Microgateway.

Versions des composants :

Le tableau suivant répertorie les numéros de version des projets de composants individuels associés à Edge Microgateway 3.1.1. Notez que, comme chaque composant est un projet distinct, les numéros de version peuvent ne pas correspondre à la version principale du produit :

Correction de bugs et améliorations :

• 146069701 – Correction d'un problème qui empêchait le module microgateway-core de respecter les variables d'environnement HTTP_PROXY et HTTPS_PROXY. Avec cette modification, les paramètres de proxy du fichier de configuration YAML, s'ils sont spécifiés, sont désormais ignorés. Seules les variables d'environnement sont utilisées pour spécifier le proxy.

  Si vous souhaitez spécifier la configuration du proxy dans le fichier de configuration, vous devez également spécifier une variable HTTP_PROXY qui mentionne la même URL de proxy que celle spécifiée dans le fichier de configuration. Par exemple, si vous spécifiez la configuration suivante :

  edge_config:
    proxy: http://10.128.0.20:3128
    proxy_tunnel: true

  Vous devez également spécifier cette variable d'environnement :

  HTTP_PROXY=http://10.128.0.20:3128

• 146320620 – Ajout d'un nouveau paramètre de configuration, edgemicro.headers_timeout. Cet attribut limite la durée (en millisecondes) pendant laquelle l'analyseur HTTP attend de recevoir les en-têtes HTTP complets. Exemple :

  edgemicro:
  keep_alive_timeout: 6000
  headers_timeout: 12000

  En interne, le paramètre définit l'attribut Node.js Server.headersTimeout sur les requêtes. (Par défaut : 5 secondes de plus que la durée définie avec edgemicro.keep_alive_timeout. Ce paramètre par défaut empêche les équilibreurs de charge ou les proxys d'interrompre la connexion par erreur.)

• 149278885 : une nouvelle fonctionnalité a été ajoutée pour vous permettre de définir le délai avant expiration de l'API cible au niveau du proxy d'API au lieu d'utiliser un paramètre de délai avant expiration global.

  Si vous définissez la propriété TargetEndpoint io.timeout.millis dans le proxy d'API, Edge Microgateway pourra récupérer cette propriété et appliquer des délais d'attente spécifiques au point de terminaison cible. Si ce paramètre n'est pas appliqué, Edge Microgateway utilise le délai d'expiration global spécifié avec edgemicro.request_timeout.

3.1.0

Le mardi 21 janvier, nous avons publié les corrections et améliorations suivantes pour Edge Microgateway.

Versions des composants :

Le tableau suivant répertorie les numéros de version des projets de composants individuels associés à Edge Microgateway 3.1.0. Notez que, comme chaque composant est un projet distinct, les numéros de version peuvent ne pas correspondre à la version principale du produit :

Correction de bugs et améliorations :

• 144187500 : un événement de niveau AVERTISSEMENT sera consigné lorsque l'indicateur quotas.failOpen est déclenché. Ce signalement est déclenché si une erreur de traitement de quota se produit ou si la requête "quota apply" envoyée à Edge ne parvient pas à mettre à jour les compteurs de quota à distance. Dans ce cas, le quota sera traité en fonction des nombres locaux uniquement jusqu'à la prochaine synchronisation réussie du quota à distance. Auparavant, cet événement n'était enregistré que lorsque le niveau de journalisation était défini sur DEBUG.

  Exemple :

  2020-01-20T02:52:53.040Z [warn][localhost:8000][5][foo-eval][test][hello/][]
  [DbpGIq9jKfzPX8jvXEivhA0LPwE][f372cc30-3b2f-11ea-845f-a627f][quota][remote quota not
  available so processing locally, setting quota-failed-open for identifier: AppQuota60.Quota60]
  [GET][][][][]

• 145023519 : résolution d'un problème qui affectait les transactions en cours ou nouvelles chaque fois qu'Edge Microgateway détectait une modification d'un proxy d'API. Désormais, lorsqu'une modification est apportée à un proxy, Edge Microgateway actualise le cache et les nœuds de calcul redémarrent. Ce changement n'a aucune incidence sur les transactions en cours ni sur les nouveaux appels d'API envoyés à la micro-passerelle.
• 146378327 : le niveau de journalisation de sourceRequest, targetRequest et targetResponse a été défini sur INFO.
• 146019878 : correction d'un écart entre la latence calculée pour "Performances du proxy d'API" dans les événements de journal sourceResponse/targetResponse d'analyse Edge et Edge Microgateway. La latence des événements de journaux Edge Analytics et Microgateway est désormais alignée.
• Modifications de la logique de correspondance des modèles :
  • 147027862 : le plug-in OAuth a été mis à jour pour prendre en charge les modèles de correspondance de chemin de ressource suivants, comme spécifié dans les produits d'API :
    • /{literal}**
    • /{literal}*
    • Toute combinaison des deux schémas ci-dessus

    Avec ce changement, le plug-in Edge Microgateway suit désormais le même modèle de correspondance que celui d'Apigee Edge, comme expliqué dans Configurer le comportement d'un chemin de ressource de '/', '/*' et '/**'.

  • 145644205 : mise à jour de la logique de correspondance des modèles du plug-in apiKeys pour qu'elle corresponde à celle du plug-in oauth.
• 143488312 : un problème a été résolu. Les espaces en début ou en fin du paramètre d'ID client entraînaient la création d'une liste de produits JWT vide pour les requêtes de jeton OAuth et de clé API.
• 145640807 et 147579179 : une nouvelle fonctionnalité a été ajoutée. Elle permet à une instance Edge Microgateway spéciale appelée "synchroniseur" de récupérer les données de configuration d'Apigee Edge et de les écrire dans une base de données Redis locale. D'autres instances de microgateway peuvent ensuite être configurées pour lire leurs données de configuration à partir de la base de données. Cette fonctionnalité ajoute un niveau de résilience à Edge Microgateway. Il permet aux instances de microgateway de démarrer et de fonctionner sans avoir besoin de communiquer avec Apigee Edge. Pour en savoir plus, consultez Utiliser le synchronisateur.

  La fonctionnalité de synchronisation est actuellement compatible avec Redis 5.0.x.

Version 3.0.x

Correction de bugs et améliorations v.3.0.x

3.0.10

Le vendredi 8 novembre, nous avons publié les correctifs et améliorations suivants pour Edge Microgateway.

Versions des composants :

Le tableau suivant répertorie les numéros de version des projets de composants individuels associés à Edge Microgateway 3.0.10. Notez que, comme chaque composant est un projet distinct, les numéros de version peuvent ne pas correspondre à la version principale du produit :

Correction de bugs et améliorations :

• 142677575 : une mise à jour de fonctionnalité a été effectuée afin que la correspondance de modèle pour les chemins d'accès aux ressources utilisés dans les produits API pour Edge Microgateway s'aligne désormais sur la correspondance de modèle des chemins d'accès aux ressources utilisée par Apigee Edge, comme décrit dans Configurer le comportement d'un chemin d'accès aux ressources de "/", "/*" et "/**".

  Remarque : Si vous utilisez un modèle de ressource composé tel que /*/2/**, vous devez vous assurer que le proxy edgemicro_auth est ajouté à un produit d'API autonome. Vous devez ensuite inclure ce produit dans l'application pour les développeurs du proxy, comme illustré dans la capture d'écran suivante :

  

  Remarque : La propriété de configuration features.isSingleForwardSlashBlockingEnabled, décrite dans Configurer le comportement d'un chemin de ressource de '/', '/*', et '/**', n'est pas compatible avec Edge Microgateway.

• 143740696 : la structure de configuration quotas a été modifiée (consultez également les notes de version de la version 3.0.9). La propriété quotas permet de configurer le plug-in de quota. La structure a été modifiée pour rendre les éléments de configuration plus clairs. Pour configurer le plug-in de quota, utilisez la configuration YAML suivante. Notez que la propriété de configuration s'appelle quotas. Pour en savoir plus sur les propriétés de configuration quotas individuelles, consultez Options de configuration pour les quotas.

  edgemicro:
    home: ../gateway
    port: 8000
    max_connections: -1
    max_connections_hard: -1
    logging:
      level: info
      dir: /var/tmp
      stats_log_interval: 60
    plugins:
      dir: ../plugins
      sequence:
        - oauth
        - quota
  quotas:
    bufferSize:
      hour: 20000
      minute: 500
      default: 10000
    useDebugMpId: true
    failOpen: true
  ...

• 141750056 : une nouvelle fonctionnalité a été ajoutée pour vous permettre d'utiliser Redis comme magasin de stockage des quotas. Si la valeur est "true", le module volos-quota-redis est utilisé.useRedis Si la valeur est "true", le quota est limité aux instances Edge Microgateway qui se connectent à Redis. Si la valeur est "false", le module volos-quota-apigee est utilisé comme magasin de stockage et le compteur de quota est global. Pour en savoir plus, consultez Options de configuration pour les quotas. Exemple :

  edgemicro:
  ...
  quotas:
    useRedis: true
    redisHost: localhost
    redisPort: 6379
    redisDb: 1

• 140574210 : le délai d'expiration par défaut des jetons générés par le proxy edgemicro-auth est passé de 108 000 millisecondes (1,8 minute) à 1 800 secondes (30 minutes).
• 143551282 : pour prendre en charge les organisations compatibles avec SAML, la commande edgemicro genkeys a été mise à jour pour inclure un paramètre ‑‑token. Ce paramètre vous permet d'utiliser un jeton OAuth pour l'authentification au lieu d'un nom d'utilisateur et d'un mot de passe. Pour en savoir plus, consultez Générer des clés.

3.0.9

Le vendredi 11 octobre, nous avons publié les correctifs et améliorations suivants pour Edge Microgateway.

Versions des composants :

Le tableau suivant liste les numéros de version des projets de composants individuels associés à Edge Microgateway 3.0.9. Notez que, comme chaque composant est un projet distinct, les numéros de version peuvent ne pas correspondre à la version principale du produit :

Correction de bugs et améliorations :

• 141989374 – Une nouvelle fonctionnalité "fail open" a été ajoutée au plug-in de quota. Lorsque cette fonctionnalité est activée, si une erreur de traitement du quota se produit ou si la requête "quota apply" envoyée à Edge ne parvient pas à mettre à jour les compteurs de quota à distance, le quota est traité en fonction des nombres locaux uniquement jusqu'à la prochaine synchronisation réussie du quota à distance. Dans les deux cas, un indicateur quota-failed-open est défini dans l'objet de requête.

  Pour activer la fonctionnalité "fail open" pour les quotas, définissez la configuration suivante :

  quotas :
   failOpen : true

  Remarque : De plus, le nom de l'indicateur d'objet de requête fail-open du plug-in OAuth a été remplacé par oauth-failed-open.

• 142093764 : une modification de configuration a été apportée au proxy edgemicro-auth pour éviter les dépassements de quota. La modification consiste à définir le type de quota sur calendar. Pour utiliser cette amélioration, vous devez mettre à jour votre edgemicro-auth vers la version 3.0.7 ou ultérieure.
• 142520568 : une nouvelle fonctionnalité a été ajoutée pour permettre la journalisation de l'ID du processeur de messages dans les réponses de quota. Pour utiliser cette fonctionnalité, vous devez mettre à jour votre proxy edgemicro-auth vers la version 3.0.7 ou ultérieure, et définir la configuration suivante :

  quotas:
    useDebugMpId: true

  Lorsque useDebugMpId est défini, les réponses de quota d'Edge contiennent l'ID du MP et sont enregistrées par Edge Microgateway. Exemple :

  {
      "allowed": 20,
      "used": 3,
      "exceeded": 0,
      "available": 17,
      "expiryTime": 1570748640000,
      "timestamp": 1570748580323,
      "debugMpId": "6a12dd72-5c8a-4d39-b51d-2c64f953de6a"
  }

3.0.8

Le jeudi 26 septembre, nous avons publié les correctifs et améliorations suivants pour Edge Microgateway.

Versions des composants :

Le tableau suivant répertorie les numéros de version des projets de composants individuels associés à Edge Microgateway 3.0.8. Notez que, comme chaque composant est un projet distinct, les numéros de version peuvent ne pas correspondre à la version principale du produit :

Correction de bugs et améliorations :

• 140025210 : une nouvelle fonctionnalité "fail open" a été ajoutée. Cette fonctionnalité permet au traitement de l'API de se poursuivre si un jeton JWT expiré ne peut pas être actualisé en raison d'une erreur de connexion qui empêche un appel de validation de clé API réussi au proxy edgemicro-auth.

  Cette fonctionnalité vous permet de définir un délai de grâce pendant lequel l'ancien jeton reste en cache et est réutilisé jusqu'à l'expiration du délai de grâce. Cette fonctionnalité permet à Edge Microgateway de continuer à traiter les requêtes en cas d'échec temporaire de la connexion. Lorsque la connectivité est rétablie et qu'un appel réussi à l'API Verify est effectué, un nouveau JWT est récupéré et remplace l'ancien JWT dans le cache.

  Pour configurer la nouvelle fonctionnalité "fail open" :

  1. Définissez les propriétés suivantes dans la section oauth du fichier de configuration Edge Microgateway :

     oauth:
       failOpen: true
       failopenGraceInterval: time_in_seconds
       cacheKey: true
       ...

     Exemple :

     oauth:
       failOpen: true
       failopenGraceInterval: 5
       cacheKey: true
       ...

     Dans cet exemple, l'ancien jeton sera utilisé pendant cinq secondes s'il ne peut pas être actualisé en raison d'un problème de connectivité. Au bout de cinq secondes, une erreur d'authentification sera renvoyée.

• 141168968 : une modification a été apportée pour inclure correlation_id dans toutes les sorties de journaux de plug-in. De plus, les niveaux de journalisation de certains journaux ont été définis sur error, selon les besoins.
• 140193349 : une modification a été apportée au proxy edgemicro-auth pour exiger que la clé et le secret Edge Microgateway soient validés à chaque requête de validation de clé API. Edge Microgateway a été mis à jour pour toujours envoyer la clé et le secret à chaque requête de validation de clé API. Cette modification empêche les clients d'obtenir un JWT avec une clé API uniquement.
• 140090250 : une mise à jour a été effectuée pour ajouter la journalisation des diagnostics pour le traitement des quotas. Cette modification permet désormais de corréler la sortie du journal de quota avec le reste des journaux Edge Microgateway.

3.0.7

Le jeudi 12 septembre, nous avons publié les correctifs et améliorations suivants pour Edge Microgateway.

Versions des composants :

Le tableau suivant liste les numéros de version des projets de composants individuels associés à Edge Microgateway 3.0.7. Notez que, comme chaque composant est un projet distinct, les numéros de version peuvent ne pas correspondre à la version principale du produit :

Correction de bugs et améliorations :

• 140075602 : une mise à jour a été apportée au plug-in OAuth pour renvoyer un code d'état 5xx le cas échéant. Auparavant, le plug-in ne renvoyait que des codes d'état 4xx dans tous les cas non 200. Désormais, pour toute réponse de message qui n'est pas un état 200, le code 4xx ou 5xx exact sera renvoyé, en fonction de l'erreur.

  Cette fonctionnalité est désactivée par défaut. Pour activer cette fonctionnalité, ajoutez la propriété oauth.useUpstreamResponse: true à votre configuration Edge Microgateway. Exemple :

  oauth:
    allowNoAuthorization: false
    allowInvalidAuthorization: false
    gracePeriod: 10
    useUpstreamResponse: true

• 140090623 : dans la version 3.0.6, une nouvelle propriété de configuration, quota.quotaUri, a été ajoutée. Définissez cette propriété de configuration si vous souhaitez gérer les quotas via le proxy edgemicro-auth déployé dans votre organisation. Si cette propriété n'est pas définie, le point de terminaison du quota est défini par défaut sur le point de terminaison Edge Microgateway interne. Exemple :

  edge_config:
    quotaUri: https://%s-%s.apigee.net/edgemicro-auth

  Dans la version 3.0.7, le edgemicro-auth a été mis à jour pour accepter cette nouvelle configuration. Pour utiliser la propriété quotaUri, vous devez passer au dernier proxy edgemicro-auth. Pour en savoir plus, consultez Mettre à niveau le proxy edgemicro-auth.

• 140470888 : un en-tête d'autorisation a été ajouté aux appels de quota pour fournir une authentification. De plus, le proxy edgemicro-auth a été modifié pour supprimer "organization" de l'identifiant de quota. Étant donné que le point de terminaison de quota réside dans l'organisation du client, l'identifiant de quota n'est plus nécessaire.
• 140823165 : nom de propriété suivant :

  edgemicro:
      keepAliveTimeout

  a été documentée de manière incorrecte dans la version 3.0.6. Le nom de propriété correct est :

  edgemicro:
      keep_alive_timeout

• 139526406 : correction d'un bug qui entraînait un nombre de quotas incorrect si une application de développeur comportait plusieurs produits. Le quota est désormais appliqué correctement à chaque produit d'une application comportant plusieurs produits. La combinaison "appName + productName" est utilisée comme identifiant de quota.

3.0.6

Le jeudi 29 août, nous avons publié les corrections et améliorations suivantes pour Edge Microgateway.

• 138633700 – Ajout d'une nouvelle propriété de configuration, keepAliveTimeout. Cette propriété vous permet de définir le délai avant expiration d'Edge Microgateway (en millisecondes). (Par défaut : 5 000 millisecondes)

  Exemple :

  edgemicro:
    keep_alive_timeout: 600

• 140090623 : ajout d'une nouvelle propriété de configuration, quotaUri. Définissez cette propriété de configuration si vous souhaitez gérer les quotas via le proxy edgemicro-auth déployé dans votre organisation. Si cette propriété n'est pas définie, le point de terminaison du quota est défini par défaut sur le point de terminaison interne Edge Microgateway. Exemple :

  edge_config:
    quotaUri: https://your_org-your_env.apigee.net/edgemicro-auth
  

  Pour utiliser cette fonctionnalité, vous devez d'abord déployer la dernière version du proxy edgemicro-auth dans votre organisation. Pour en savoir plus, consultez Mettre à niveau le proxy edgemicro-auth.

• 138722809 : ajout d'une nouvelle propriété de configuration, stack_trace. Cette propriété vous permet de contrôler si les traces de pile s'affichent ou non dans les fichiers journaux. Exemple :

  stack_trace: false

  Si stack_trace est défini sur true, la trace de la pile sera imprimée dans les journaux. Si elle est définie sur false, la trace de pile ne sera pas imprimée dans les journaux.

3.0.5

Le jeudi 15 août, nous avons publié les correctifs et améliorations suivants pour Edge Microgateway.

• 139005279 – Correction d'un problème où la commande edgemicro status ne renvoyait pas le bon nombre de processus de nœud de calcul.
• 138437710 – Correction d'un problème dans la classe ExitCounter qui empêchait l'écriture du journal approprié.

• 139064652 : ajout de la possibilité d'ajouter des niveaux de journalisation trace et debug pour les journaux d'événements et système. Pour l'instant, seule la possibilité d'ajouter ces niveaux de journaux a été ajoutée. Actuellement, les niveaux de journalisation disponibles sont info, warn et error.
• 139064616 : la sortie du journal a été standardisée pour toutes les instructions de journal de la console. Les instructions de journalisation de la console incluent désormais les attributs suivants :
• Horodatage
• Nom du composant
• ID du processus
• Message du journal de la console

• 138413755 : améliorer les messages de journaux liés aux clés et aux secrets JWT pour les commandes CLI suivantes : cert, verify, upgradekvm, token, genkeys, revokekeys, rotatekey et configure.

• 138413577 : ajout et amélioration de la gestion des erreurs pour les délais d'expiration des services de backend.
• 138413303 : ajout et amélioration de la gestion des erreurs pour les délais d'expiration des réponses et des sockets.
• 138414116 : ajout et amélioration de la gestion des erreurs "connexion refusée".

3.0.4

Le jeudi 1er août, nous avons publié les correctifs et améliorations suivants pour Edge Microgateway.

• 134445926 : améliorations apportées à l'authentification interne d'Edge Microgateway.
• 137582169 : correction d'un problème qui entraînait le démarrage de processus indésirables. Les processus supplémentaires entraînaient le rechargement des plug-ins et utilisaient une quantité excessive de mémoire. Edge Microgateway maintient désormais le nombre de processus dans la limite prévue.
• 137768774 – Améliorations apportées aux messages du journal :
  • Journaux de transactions (requêtes) nettoyés.
  • Ajout de messages de journaux supplémentaires, si nécessaire.
  • Les messages du journal des transactions (demandes) ont été déplacés de la sortie de la console vers le fichier journal correspondant.
  • Mise à jour des journaux de la console pour utiliser une fonction de journalisation centralisée.
• 138321133, 138320563 : modification interne fondamentale du tampon de quota pour permettre de futures améliorations des quotas.

3.0.3

Le mardi 23 juillet, nous avons publié les correctifs et améliorations suivants pour Edge Microgateway.

• Améliorations de la journalisation : les journaux d'exécution existants utilisent une nouvelle fonction eventLog() qui capture et enregistre les données d'exécution dans un format cohérent. Les informations du journal incluent :
  • Code temporel (ISO 8601 : AAAA-MM-JJTHH:mm:ss.sssZ).
  • Niveau de journalisation (erreur, avertissement ou info).
  • Nom d'hôte : nom d'hôte de la requête provenant de l'en-tête de requête.
  • ID du processus : si vous exécutez un cluster de processus Node.js, il s'agit de l'ID du processus dans lequel la journalisation a eu lieu.
  • Nom de l'organisation Apigee.
  • Nom de l'environnement dans l'organisation.
  • Nom du proxy d'API.
  • Adresse IP du client.
  • ClientId.
  • ID de corrélation (non défini actuellement).
  • Nom du composant Edge Microgateway.
  • Message personnalisé : certains objets peuvent afficher des informations supplémentaires transmises à cette propriété d'erreur.
  • Méthode de la requête (si requête HTTP).
  • Code d'état de la réponse (si requête HTTP).
  • Message d'erreur
  • Code d'erreur : si un objet inclut un code d'erreur, il est imprimé dans cette propriété.
  • Durée
  • Marqueur de fin de ligne du système d'exploitation .

  Les valeurs de propriété nulles génèrent des crochets vides, [].

  L'exemple suivant montre le format du journal :

  Timestamp [level][hostname][ProcessId][Org][Environment][APIProxy][ClientIp][ClientId][][component][customMessage][reqMethod][respStatusCode][errMessage][errCode][timeTaken]

  (137770055)

• Performances : les produits API n'étaient pas filtrés en fonction de l'environnement. Ce problème a été résolu. (135038879)
• Diverses intégrations de tests fonctionnels et améliorations de la qualité du code.

3.0.2

Le mercredi 3 juillet 2019, nous avons publié les correctifs et améliorations suivants pour Edge Microgateway.

Qualité du code : le code a été examiné pour vérifier sa qualité et des modifications ont été apportées pour répondre aux normes de qualité demandées par les utilisateurs. Nous avons corrigé les erreurs et les avertissements liés à la qualité du code provenant de JSHint. Par conséquent, certaines erreurs de code ont été identifiées et corrigées. Tous les modules Apigee Edge Microgateway ont été soumis à ce processus. Consultez les commits du 28 juin et du 2 juillet pour microgateway-config, microgateway-core, microgateway-plugins et microgateway. Tous les modules ayant subi des modifications de la qualité du code ont été testés avec des outils internes qui vérifient l'exécution d'Edge Microgateway pour les cas d'utilisation des clients.

3.0.1

Le vendredi 21 juin 2019, nous avons publié les correctifs et améliorations suivants pour Edge Microgateway.

• 134834551 : modifier les versions Node.js compatibles pour Edge Microgateway
  (Versions Node.js compatibles : 8 et 12 ; les versions 7, 9 et 11 sont expérimentales)
• 134751883 : Edge Microgateway plante lors du rechargement sous charge
• 134518428 - Le point de terminaison Products pour Edge Microgateway renvoie 5XX si le modèle de filtre est incorrect
• 135113408 : les nœuds de calcul doivent redémarrer s'ils s'arrêtent de manière inattendue
• 134945852 - tokenCacheSize n'est pas utilisé dans le plug-in OAuth
• 134947757 : définir cacheTTL dans le plug-in OAuth
• 135445171 - gracePeriod calculation in OAuth is not correct
• Utiliser le module memored fourni avec l'installation d'Edge Microgateway
• 135367906 - Audit de sécurité

Version 2.5.x

Nouvelles fonctionnalités et améliorations v.2.5.x

(Corrigé dans la version 2.5.38, 07/06/2019)

Des JWT mal mis en forme peuvent entraîner le plantage des nœuds de calcul lors de l'utilisation du cache de jetons. Correction dans le module Edge microgateway-plugins. (b/134672029)

(Ajouté dans la version 2.5.37) Ajoutez l'option CLI edgemicro-cert -t.

L'option edgemicro cert -t vous permet de spécifier un jeton OAuth pour authentifier les API de gestion. Consultez également Gérer les certificats.

(Ajouté dans la version 2.5.35) Ajout de la compatibilité pour déboguer Edge Microgateway à l'aide de edgemicroctl.

Vous pouvez utiliser l'option mgdebug avec edgemicroctl. Consultez également Tâches d'intégration de Kubernetes.

(Ajouté dans la version 2.5.35) Activez une version Windows pour edgemicroctl.

(Ajouté dans la version 2.5.31) Nouvelle API edgemicro-auth/token

Une nouvelle API edgemicro-auth/token a été ajoutée. Elle vous permet de transmettre le client/secret en tant qu'en-tête d'autorisation de base encodé en base64 et le grant_type en tant que paramètre de formulaire. Consultez Obtenir des jetons de support directement.

(Corrigé dans la version 2.5.31) La configuration privée ne respecte pas l'indicateur de jeton

Correction d'un problème qui empêchait la configuration d'Edge Microgateway pour utiliser un jeton d'accès OAuth2 sur Edge pour Private Cloud (le jeton n'était pas respecté).

Docker : compatibilité avec l'utilisation de certificats autosignés

(Ajouté le 29/05/2024) Si vous utilisez une autorité de certification (CA) qui n'est pas approuvée par défaut par Node.js, vous pouvez utiliser le paramètre NODE_EXTRA_CA_CERTS lorsque vous exécutez un conteneur Docker avec Edge Microgateway. Pour en savoir plus, consultez Utiliser une autorité de certification non approuvée par Node.js.

Docker : compatibilité avec TLS

(Ajouté le 29/05/2019) Edge Microgateway exécuté dans un conteneur Docker est désormais compatible avec TLS pour les requêtes entrantes vers le serveur Edge Microgateway (requêtes Northbound) et pour les requêtes sortantes d'Edge Microgateway vers une application cible (requêtes Southbound).

Les exemples suivants expliquent en détail comment configurer ces configurations TLS :

• Exemple de configuration TLS en amont
• Exemple de configuration TLS en aval

Dans ces exemples, vous verrez comment utiliser le point de montage du conteneur /opt/apigee/.edgemicro pour charger les certificats, qui sont ensuite référencés dans le fichier de configuration Edge Microgateway.

Docker : compatibilité avec le proxy de requête

(Ajouté le 27/05/2022) Si vous exécutez Edge Microgateway dans un conteneur Docker, vous pouvez utiliser ces options pour contrôler le comportement du proxy lorsque la passerelle est exécutée derrière un pare-feu :

• HTTP_PROXY
• HTTPS_PROXY
• NO_PROXY

Pour en savoir plus, consultez Exécuter Edge Micro en tant que conteneur Docker.

Docker : instructions mises à jour pour le plug-in

(Ajouté le 25/05/2027) Si vous exécutez Edge Microgateway dans un conteneur Docker, vous disposez désormais de deux options pour déployer des plug-ins. Une option utilisant un point de montage Docker est nouvelle. L'autre option existait auparavant et est restée pratiquement inchangée. Toutefois, le fichier Dockerfile a été mis à jour. Pour en savoir plus, consultez les liens suivants :

• Option A : Installer le répertoire des plug-ins sur un volume (nouveau)
• Option B : Intégrer les plug-ins au conteneur (mise à jour)

Nouvelle compatibilité avec les jetons OAuth pour la commande de mise à niveau KVM

(Ajouté le 27/05/2022) Vous pouvez utiliser un jeton OAuth avec la commande upgradekvm. Pour en savoir plus, consultez Mettre à niveau la KVM.

Séparer les API dans Edge Analytics

(Ajouté le 26/05/2022) Les nouveaux indicateurs de plug-in d'analyse vous permettent de séparer un chemin d'API spécifique afin qu'il apparaisse comme un proxy distinct dans les tableaux de bord Edge Analytics. Par exemple, vous pouvez séparer les API de vérification de l'état pour éviter de les confondre avec les appels d'API réels. Pour en savoir plus, consultez Exclure des chemins d'accès des analyses.

Configurer un proxy local

(Ajouté le 25/05/2022) Avec un proxy local, vous n'avez pas besoin de créer manuellement un proxy compatible avec la passerelle Microgateway sur Apigee Edge. Le microgateway utilisera plutôt le chemin de base du proxy local. Pour en savoir plus, consultez Utiliser le mode proxy local.

Utiliser le mode autonome

(Ajouté le 25/05/2023) Vous pouvez exécuter Edge Microgateway complètement déconnecté de toute dépendance Apigee Edge. Ce scénario, appelé mode autonome, vous permet d'exécuter et de tester Edge Microgateway sans connexion Internet. Pour en savoir plus, consultez Exécuter Edge Microgateway en mode autonome.

Révoquer des clés

(Ajouté le 25/01/2019) Une nouvelle commande CLI a été ajoutée pour révoquer les identifiants de clé et de secret pour une configuration Edge Microgateway.

edgemicro revokekeys -o [organization] -e [environment] -u [username] -k [key] -s [secret]

Compatibilité avec Docker

(Ajouté le 25/01/2019) Vous pouvez désormais télécharger la dernière version d'Edge Microgateway en tant qu'image Docker :

docker pull gcr.io/apigee-microgateway/edgemicro:latest

Compatibilité avec Kubernetes

(Ajouté le 25/05/2019) Vous pouvez déployer Edge Microgateway en tant que service ou en tant que passerelle side-car devant les services déployés dans un cluster Kubernetes. Consultez Présentation de l'intégration d'Edge Microgateway à Kubernetes.

Prise en charge de l'option TCP nodelay

(Ajouté dans la version 2.5.16) Un nouveau paramètre de configuration, nodelay, a été ajouté à la configuration Edge Micro.

Par défaut, les connexions TCP utilisent l'algorithme de Nagle pour mettre en mémoire tampon les données avant de les envoyer. Définir nodelay sur true désactive ce comportement (les données sont immédiatement envoyées chaque fois que socket.write() est appelé). Pour en savoir plus, consultez également la documentation Node.js.

Pour activer nodelay, modifiez le fichier de configuration Edge Micro comme suit :

edgemicro:
  nodelay: true
  port: 8000
  max_connections: 1000
  config_change_poll_interval: 600
  logging:
    level: error
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24

Nouvelles options de CLI pour la surveillance Forever

(Ajouté dans la version 2.5.12) De nouveaux paramètres ont été ajoutés à la commande edgemicro forever. Ces paramètres vous permettent de spécifier l'emplacement du fichier forever.json et de démarrer ou d'arrêter le processus d'arrière-plan Forever. Voir aussi Surveillance continue

Exemples :

Pour commencer à utiliser Forever :

edgemicro forever -f ~/mydir/forever.json -a start

Pour arrêter Forever :

edgemicro forever -a stop

Rotation des clés JWT

Une nouvelle fonctionnalité a été ajoutée. Elle vous permet d'alterner les paires de clés publique/privée utilisées pour générer les jetons JWT utilisés pour la sécurité OAuth sur Edge Microgateway. Consultez Alterner les clés JWT.

Filtrer les proxys d'API téléchargés

Par défaut, Edge Microgateway télécharge tous les proxys de votre organisation Edge qui commencent par le préfixe de dénomination "edgemicro_". Vous pouvez modifier cette valeur par défaut pour télécharger les proxys dont les noms correspondent à un modèle. Consultez Filtrer les proxys téléchargés.

Spécifier des produits sans proxys d'API

Dans Apigee Edge, vous pouvez créer un produit d'API qui ne contient aucun proxy d'API. Cette configuration de produit permet à une clé API associée à ce produit de fonctionner avec n'importe quel proxy déployé dans votre organisation. À partir de la version 2.5.4, Edge Microgateway est compatible avec cette configuration de produit.

Assistance pour la surveillance continue

Edge Microgateway dispose d'un fichier forever.json que vous pouvez configurer pour contrôler le nombre de redémarrages d'Edge Microgateway et les intervalles entre eux. Ce fichier configure un service appelé forever-monitor, qui gère Forever de manière programmatique. Consultez Surveillance continue.

Gestion centralisée du fichier de configuration Edge Micro

Si vous exécutez plusieurs instances Edge Microgateway, vous pouvez gérer leurs configurations à partir d'un seul emplacement. Pour ce faire, spécifiez un point de terminaison HTTP à partir duquel Edge Micro peut télécharger son fichier de configuration. Consultez Spécifier un point de terminaison de fichier de configuration.

Prise en charge de l'option CLI "forever"

(Ajouté dans la version 2.5.8) Utilisez la commande edgemicro forever [package.json] pour spécifier l'emplacement du fichier forever.json. Avant l'ajout de cette commande, le fichier de configuration devait se trouver dans le répertoire racine Edge Microgateway.

Exemple :

edgemicro forever ~/mydir/forever.json

Ajout de l'option configUrl à la commande de rechargement

(Ajouté dans la version 2.5.8) Vous pouvez désormais utiliser l'option --configUrl ou -u avec la commande edgemicro reload.

Délai de grâce pour les écarts de temps JWT

(Ajouté dans la version 2.5.7) Un attribut gracePeriod dans la configuration OAuth permet d'éviter les erreurs causées par de légères différences entre l'horloge de votre système et les heures "Not Before" (nbf) ou "Issued At" (iat) spécifiées dans le jeton d'autorisation JWT. Définissez cet attribut sur le nombre de secondes à autoriser pour ces écarts. Consultez Attributs OAuth.

(Ajouté dans la version 2.5.7) Un attribut gracePeriod dans la configuration OAuth permet d'éviter les erreurs causées par de légères différences entre l'horloge de votre système et les heures "Not Before" (nbf) ou "Issued At" (iat) spécifiées dans le jeton d'autorisation JWT. Définissez cet attribut sur le nombre de secondes à autoriser pour ces écarts. Consultez Attributs OAuth.

Bugs résolus dans la version 2.5.x

• (Problème 236) Correction d'une faute de frappe dans la section sur la suppression du cache.
• (Problème 234) Les rechargements plantent pour Edge Microgateway 2.5.35.
• (Problème 135) Erreur de référence d'hôte virtuel non valide "secure" lors de l'utilisation de l'option -v. Ce correctif modifie le proxy edgemicro-auth avant le déploiement pour s'assurer que les hôtes virtuels correspondent exactement à ce qui est spécifié dans l'indicateur "-v". De plus, vous pouvez spécifier n'importe quel nombre et n'importe quel nom pour l'hôte virtuel (il n'est plus limité à "default" et "secure").
• (Problème 141) La commande edgemicro reload n'est pas compatible avec l'option de fichier de configuration -c. Ce problème a été résolu.
• (Problème 142) Edge Microgateway se plaint de la crypto obsolète lors de l'installation. Ce problème a été résolu.
• (Problème 145) Le quota ne fonctionne pas avec Edge Microgateway. Ce problème a été résolu.
• (Problème de la communauté Apigee : https://community.apigee.com/questions/33149/emg-jwt-token-validated-against-both-api-proxies-a.html#answer-33336) Jeton JWT validé par rapport aux URI de proxy d'API et de ressources dans OAUTH. Ce problème a été résolu.
• (Problème de la communauté Apigee : https://community.apigee.com/questions/47846/microgateway-not-working-with-oauth.html) La passerelle Microgateway ne fonctionne pas avec OAuth. Ce problème a été résolu.
• Correction de pidPath sous Windows.
• (Problème #157) Le problème qui entraînait le message d'erreur suivant a été résolu : ReferenceError: deployProxyWithPassword n'est pas défini.
• (Problème 169) Mettre à jour les dépendances Node.js (npm audit)
• Le proxy edgemicro-auth utilise désormais les règles JWT Edge. Le proxy ne dépend plus de Node.js pour fournir la compatibilité JWT.

Version 2.4.x

Nouvelles fonctionnalités et améliorations v.2.4.x

1. Définir un alias personnalisé pour le proxy edgemicro-auth (PR 116)

Vous pouvez modifier le chemin de base par défaut du proxy edgemicro-auth. Par défaut, le chemin de base est /edgemicro-auth. Pour le modifier, utilisez l'option -x sur la commande edgemicro configure.

Exemple :

edgemicro configure -x /mypath …

2. Gestion des caractères génériques pour les chemins de base (PR 77)

Vous pouvez utiliser un ou plusieurs caractères génériques * dans le chemin de base d'un proxy edgemicro_*. Par exemple, un chemin de base de /team/*/members permet aux clients d'appeler https://[host]/team/blue/members et https://[host]/team/green/members sans que vous ayez besoin de créer de proxys d'API pour gérer les nouvelles équipes. Notez que /**/ n'est pas accepté.

3. Chemin de configuration personnalisé ajouté à la CLI pour la configuration Private Cloud (PR 99)

Par défaut, le fichier de configuration de la passerelle microgateway se trouve dans ./config/config.yaml. Sur les commandes init, configure et start, vous pouvez désormais spécifier un chemin de configuration personnalisé sur la ligne de commande à l'aide des indicateurs -c ou --configDir. Correction d'un problème qui empêchait la reconnaissance d'un répertoire de configuration personnalisé pour les installations Private Cloud.

Exemple :

edgemicro start -o docs -e test -k abc123 -s xyz456 -c /home/microgateway/config

4. Respecter les variables *_PROXY (PR 61)

Si Edge Microgateway est installé derrière un pare-feu et ne peut pas communiquer avec Apigee Edge dans le cloud public, deux options sont possibles :

Option 1 :

La première option consiste à définir l'option edgemicro: proxy_tunnel sur "true" dans le fichier de configuration de la micro-passerelle :

edge_config:
   proxy: http://10.224.16.85:3128
   proxy_tunnel: true

Lorsque proxy_tunnel est défini sur true, Edge Microgateway utilise la méthode HTTP CONNECT pour tunneliser les requêtes HTTP sur une seule connexion TCP. (Il en va de même si les variables d'environnement pour configurer le proxy sont compatibles avec TLS.)

Option 2 :

La deuxième option consiste à spécifier un proxy et à définir proxy_tunnel sur false dans le fichier de configuration du microgateway. Exemple :

edge_config:
   proxy: http://10.224.16.85:3128
   proxy_tunnel: false

Dans ce cas, vous pouvez définir les variables suivantes pour contrôler les hôtes de chaque proxy HTTP que vous souhaitez utiliser, ou les hôtes qui ne doivent pas gérer les proxys Edge Microgateway : HTTP_PROXY, HTTPS_PROXY et NO_PROXY. Vous pouvez définir NO_PROXY comme une liste de domaines séparés par une virgule vers lesquels Edge Microgateway ne doit pas rediriger le trafic. Exemple :

export HTTP_PROXY='http://localhost:3786'
export HTTPS_PROXY='https://localhost:3786'

Pour en savoir plus sur ces variables, consultez les ressources suivantes :

https://www.npmjs.com/package/request#controlling-proxy-behaviour-using-environment-variables

5. Définir un délai avant expiration personnalisé pour les requêtes cibles (PR 57)

Vous pouvez définir un délai avant expiration personnalisé pour les requêtes cibles avec cette configuration :

edgemicro:
    request_timeout: 10

Le délai avant expiration est défini en secondes. En cas de délai avant expiration, Edge Microgateway répond avec un code d'état 504.

6. Respecter les messages d'état HTTP personnalisés dans la réponse cible (PR 53)

Edge Microgateway respecte les messages d'état HTTP personnalisés définis dans la réponse cible. Dans les versions précédentes, les messages d'état envoyés depuis la cible étaient remplacés par les valeurs par défaut de Node.js.

7. L'en-tête X-Forwarded-For peut définir client_ip pour les données analytiques.

Si l'en-tête X-Forwarded-For est présent, il définit la variable client_ip qui est signalée dans Edge Analytics. Cette fonctionnalité vous permet de connaître l'adresse IP du client qui a envoyé une requête à Edge Microgateway.

8. Modifications apportées au plug-in OAuth

Le plug-in OAuth est compatible avec la validation des clés API et des jetons d'accès OAuth. Avant cette modification, le plug-in acceptait les deux formes de sécurité. Cette modification vous permet de n'autoriser qu'un seul de ces modèles de sécurité (tout en conservant la rétrocompatibilité).

Le plug-in OAuth ajoute deux nouveaux indicateurs :

• allowOAuthOnly : si la valeur est définie sur true, chaque API doit comporter un en-tête d'autorisation avec un jeton d'accès Bearer.

• allowAPIKeyOnly : si la valeur est définie sur true, chaque API doit comporter un en-tête x-api-key (ou un emplacement personnalisé) avec une clé API.

Vous définissez ces indicateurs dans le fichier de configuration Edge Microgateway comme suit :

oauth:
    allowNoAuthorization: false
    allowInvalidAuthorization: false
    keep-authorization-header: false
    allowOAuthOnly: false
    allowAPIKeyOnly: false

9. Amélioration du proxy edgemicro-auth (PR 40)

Des améliorations ont été apportées au proxy edgemicro-auth. Avant ces modifications, le proxy stockait les clés dans Edge Secure Store, un coffre-fort chiffré. Le proxy stocke désormais les clés dans le mappage clé-valeur (KVM) chiffré d'Edge.

10. Réécriture de l'URL cible par défaut dans un plug-in (PR 74)

Vous pouvez également remplacer le port du point de terminaison cible et choisir entre HTTP et HTTPS. Modifiez ces variables dans le code de votre plug-in : req.targetPort et req.targetSecure. Pour choisir HTTPS, définissez req.targetSecure sur true. Pour HTTP, définissez-le sur false. Si vous définissez req.targetSecure sur "true", consultez ce fil de discussion pour en savoir plus.

11. Prise en charge initiale de l'authentification par jeton OAuth (PR 125)

Vous pouvez configurer Edge Microgateway pour qu'il utilise un jeton OAuth pour l'authentification au lieu d'un nom d'utilisateur et d'un mot de passe. Pour utiliser un jeton OAuth, utilisez le paramètre suivant sur la commande edgemicro configure :

-t, --token <token>

Exemple :

edgemicro configure -o docs -e test -t <your token>

Bugs résolus dans la version 2.4.3

• Correction d'un problème qui nécessitait une organisation payante pour exécuter correctement le proxy edgemicro-auth. Désormais, vous pouvez également utiliser Edge Microgateway avec les organisations d'essai. (PR 5)
• Correction d'un problème qui entraînait l'exécution des gestionnaires de fin alors que le flux n'avait pas terminé de traiter les données. Cela a entraîné l'envoi d'une réponse partielle. (PR 71)
• Correction d'un problème qui empêchait la reconnaissance d'un répertoire de configuration personnalisé pour les installations Private Cloud. (PR 110)
• Correction d'un problème lié au protocole SSL bidirectionnel entre le client et Edge Microgateway. (PR 70)
• Correction d'un problème qui nécessitait une barre oblique de fin sur le chemin de base du proxy pour que la validation de la clé API fonctionne correctement. Désormais, une barre oblique de fin n'est plus nécessaire à la fin du chemin de base. (PR 48)

Version 2.3.5

Nouvelles fonctionnalités et améliorations v.2.3.5

Filtrage des proxys

Vous pouvez filtrer les proxys compatibles avec les microgateways qu'une instance Edge Microgateway traitera. Lorsque Edge Microgateway démarre, il télécharge tous les proxys compatibles avec Microgateway dans l'organisation à laquelle il est associé. Utilisez la configuration suivante pour limiter les proxys que la passerelle microtraitera. Par exemple, cette configuration limite à trois le nombre de proxys que la micro-passerelle traitera : edgemicro_proxy-1, edgemicro_proxy-2 et edgemicro_proxy-3 :

proxies:
  - edgemicro_proxy-1
  - edgemicro_proxy-2
  - edgemicro_proxy-3

Masquage des données Analytics

Une nouvelle configuration vous permet d'empêcher l'affichage des informations sur le chemin d'accès aux requêtes dans les données analytiques Edge. Ajoutez les éléments suivants à la configuration du microgateway pour masquer l'URI et/ou le chemin de la requête. Notez que l'URI se compose des parties nom d'hôte et chemin d'accès de la requête.

analytics:
  mask_request_uri: 'string_to_mask'
  mask_request_path: 'string_to_mask'

Version 2.3.3

Nouvelles fonctionnalités et améliorations v.2.3.3

Voici les nouvelles fonctionnalités et améliorations apportées à cette version.

Désactiver l'interrogation automatique des modifications

Vous pouvez désactiver l'interrogation automatique des modifications en définissant cet attribut dans la configuration du microgateway :

disabled_config_poll_interval: true

Par défaut, l'interrogation périodique détecte toutes les modifications apportées à Edge (modifications des produits, des proxys compatibles avec la passerelle Microgateway, etc.), ainsi que les modifications apportées au fichier de configuration local. L'intervalle d'interrogation par défaut est de 600 secondes (cinq minutes).

Réécrire les URL cibles dans les plug-ins

Vous pouvez remplacer l'URL cible par défaut de manière dynamique dans un plug-in en modifiant les variables req.targetHostname et req.targetPath dans le code de votre plug-in.

Nouvelle signature de fonction de plug-in

Une nouvelle signature de fonction de plug-in a été ajoutée. Elle fournit la réponse cible en tant qu'argument. Cela permet aux plug-ins d'accéder plus facilement à la réponse cible.

function(sourceRequest, sourceResponse, targetResponse, data, cb)

Sortie de journalisation par défaut simplifiée

Par défaut, le service de journalisation omet désormais le JSON des proxys, des produits et des JWT téléchargés. Vous pouvez définir la sortie de ces objets par défaut en définissant DEBUG=* lorsque vous démarrez Edge Microgateway. Exemple :

DEBUG=* edgemicro start -o docs -e test -k abc123 -s xyz456

Chemin de configuration personnalisé ajouté à la CLI

Par défaut, le fichier de configuration de la passerelle est situé dans ./config/config.yaml. Vous pouvez désormais spécifier un chemin de configuration personnalisé sur la ligne de commande pour les commandes init, configure et start. Exemple :

edgemicro start -o docs -e test -k abc123 -s xyz456 -c /home/microgateway/config

Bugs résolus dans la version 2.3.3

• Correction d'une fuite de mémoire qui se produisait lors de requêtes/réponses volumineuses.
• L'ordre d'exécution des plug-ins a été corrigé. Il se comporte désormais comme indiqué dans la documentation.
• Le plug-in accumulate-request ne se bloque plus pour les requêtes GET.
• Un problème a été résolu dans le plug-in accumulate-response, où l'absence de corps de réponse entraînait des erreurs.

Version 2.3.1

Remarque sur l'installation

Certaines versions précédentes d'Edge Microgateway vous permettent d'installer le logiciel en téléchargeant un fichier ZIP. Ces fichiers ZIP ne sont plus acceptés. Pour installer Edge Microgateway, vous devez utiliser :

npm install -g edgemicro

Pour en savoir plus, consultez la page sur l'installation.

Nouvelles fonctionnalités et améliorations v.2.3.1

Voici les nouvelles fonctionnalités et améliorations apportées à cette version.

Filtrer les proxys

Une nouvelle configuration vous permet de filtrer les proxys qu'Edge Microgateway chargera au démarrage. Auparavant, la microgateway chargeait tous les proxys compatibles avec la microgateway (proxys nommés edgemicro_*) extraits de l'organisation/de l'environnement Edge que vous avez spécifiés dans la commande edgemicro configure. Cette nouvelle fonctionnalité vous permet de filtrer cette liste de proxys afin qu'Edge Microgateway ne charge que ceux que vous spécifiez. Il vous suffit d'ajouter l'élément "proxies" au fichier de configuration de microgateway, comme suit :

edge micro:
proxies:
    - edgemicro_[name]
    - edgemicro_[name]
    ...

Par exemple, supposons que vous disposiez de 50 proxys edgemicro_* dans votre organisation/environnement Edge, y compris ceux nommés edgemicro_foo et edgemicro_bar. Vous pouvez indiquer au microgateway d'utiliser uniquement ces deux proxys comme suit :

edge micro:
proxies:
    - edgemicro_foo
    - edgemicro_bar

Au démarrage, la microgateway ne pourra appeler que les proxys spécifiés. Toute tentative d'appel d'autres proxys compatibles avec la micro-passerelle téléchargés à partir de l'organisation/de l'environnement Edge entraînera une erreur.

Définir les en-têtes de requête cibles dans les plug-ins

Il existe deux modèles de base à prendre en compte si vous souhaitez ajouter ou modifier des en-têtes de requête cible : l'un où la requête entrante contient des données (comme dans une requête POST) et l'autre où elle n'en contient pas (comme dans une simple requête GET).

Prenons le cas où la requête entrante contient des données et où vous souhaitez définir des en-têtes de requête sur la requête cible. Dans les versions précédentes d'Edge Microgateway, il n'était pas possible de définir des en-têtes cibles de manière fiable dans ce cas.

La clé de ce modèle est d'abord d'accumuler toutes les données entrantes du client. Ensuite, dans la fonction onend_request(), utilisez la nouvelle fonction request.setOverrideHeader(name, value) pour personnaliser les en-têtes.

Voici un exemple de code de plug-in montrant comment procéder. Les en-têtes définis dans onend_request sont envoyés à la cible :

module.exports.init = function(config, logger, stats) {


  function accumulate(req, data) {
    if (!req._chunks) req._chunks = [];
    req._chunks.push(data);
  }

  return {

    ondata_request: function(req, res, data, next) {
      if (data && data.length > 0) accumulate(req, data);
      next(null, null);
    },

    onend_request: function(req, res, data, next) {
      if (data && data.length > 0) accumulate(req, data);
      var content = Buffer.concat(req._chunks);
      delete req._chunks;
      req.setOverrideHeader('foo', 'bar');
      req.setOverrideHeader('content-length', content.length);
      next(null, content);
    },


    onerror_request: function(req, res, data, next) {
      next(null, null);
    }

  };

}

Si la requête n'inclut pas de données, vous pouvez définir des en-têtes cibles dans le gestionnaire onrequest(). Ce modèle n'est pas nouveau. Il a déjà été documenté et utilisé dans les plug-ins exemples fournis avec Edge Microgateway.

onrequest: function(req, res, next) {
      debug('plugin onrequest');
      req.headers['x-foo-request-id'] = "bar";
      req.headers['x-foo-request-start'] = Date.now();
      next();
    }

Fonctionnalité de rechargement sans temps d'arrêt

Après avoir modifié la configuration d'Edge Microgateway, vous pouvez charger la configuration sans perdre de messages. Avec ce changement, Edge Microgateway démarre toujours en mode cluster, et l'option --cluster a été supprimée de la commande edgemicro start.

De plus, trois nouvelles commandes CLI ont été ajoutées. Vous devez exécuter ces commandes à partir du même répertoire que celui depuis lequel la commande de démarrage edgemicro a été exécutée :

• edgemicro status : vérifie si Edge Microgateway est en cours d'exécution.
• edgemicro stop : arrête le cluster Edge Microgateway.
• edgemicro reload : recharge la configuration Edge Microgateway sans temps d'arrêt.

Rechargement automatique de la configuration sans temps d'arrêt

Edge Microgateway charge régulièrement une nouvelle configuration et exécute un rechargement en cas de modification. L'interrogation détecte toutes les modifications apportées à Edge (modifications des produits, des proxys compatibles avec la passerelle de microservices, etc.) ainsi que celles apportées au fichier de configuration local. L'intervalle d'interrogation par défaut est de 600 secondes (cinq minutes). Vous pouvez modifier la valeur par défaut dans le fichier de configuration du microgateway comme suit :

edgemicro:
    config_change_poll_interval: [seconds]

Ajout d'informations sur la version à la CLI

Un indicateur --version a été ajouté à la CLI. Pour obtenir la version actuelle d'Edge Microgateway, utilisez la commande suivante :

edgemicro --version

Nouvelles options SSL pour le serveur Edge Microgateway

Edge Microgateway est désormais compatible avec les options SSL de serveur suivantes en plus de key et cert :

Envoyer les fichiers journaux vers stdout

Vous pouvez envoyer des données de journaux vers la sortie standard avec un nouveau paramètre de configuration :

edgemicro:
  logging:
    to_console: true  

Consultez Gérer les fichiers journaux.

Version 2.1.2

Voici les nouvelles fonctionnalités et améliorations apportées à cette version.

Autoriser un point de terminaison d'API personnalisé pour la configuration

De nouveaux points de terminaison configurables sont disponibles pour le proxy d'autorisation. Ils permettent d'utiliser un service d'authentification personnalisé. Voici ces points de terminaison :

• edgeconfig:verify_api_key_url
• edgeconfig:products

Pour en savoir plus, consultez Utiliser un service d'authentification personnalisé.

Version 2.1.1

Voici les nouvelles fonctionnalités et améliorations apportées à cette version.

Déployer un proxy d'authentification compatible multiplate-forme

Une amélioration a été apportée afin que la commande utilisée pour déployer le proxy d'autorisation Edge Microgateway sur Edge soit compatible avec les systèmes Windows.

Version 2.1.0

Nouvelles fonctionnalités et améliorations v.21.0

Voici les nouvelles fonctionnalités et améliorations :

Spécifier les options SSL/TLS du client

Vous pouvez spécifier des options client pour les connexions SSL/TLS aux cibles à l'aide d'un nouvel ensemble d'options de configuration. Consultez Utiliser les options SSL/TLS du client.

Version 2.0.11

Note d'installation v2.0.11

Certaines versions précédentes d'Edge Microgateway vous permettent d'installer le logiciel en téléchargeant un fichier ZIP. Ces fichiers ZIP ne sont plus acceptés. Pour installer Edge Microgateway, vous devez utiliser :

npm install -g edgemicro

Pour en savoir plus, consultez la page sur l'installation.

Nouvelles fonctionnalités et améliorations v.2.0.11

Voici les nouvelles fonctionnalités et améliorations :

Spécifier un port au démarrage

La commande de démarrage vous permet de spécifier un numéro de port pour remplacer celui indiqué dans le fichier de configuration. Vous pouvez également spécifier un numéro de port à l'aide de la variable d'environnement PORT. Pour en savoir plus, consultez la commande start.

Conserver les en-têtes d'authentification (facultatif)

Un nouveau paramètre de configuration, keepAuthHeader, vous permet de conserver l'en-tête d'autorisation envoyé dans la requête. Si la valeur est définie sur "true", l'en-tête d'authentification est transmis à la cible. Consultez la section Attributs OAuth.

Possibilité d'utiliser un service d'autorisation personnalisé

Si vous souhaitez utiliser votre propre service personnalisé pour gérer l'authentification, modifiez la valeur authUri dans le fichier de configuration Edge Microgateway pour qu'elle pointe vers votre service. Pour en savoir plus, consultez Utiliser un service d'authentification personnalisé.

Version 2.0.4

Edge Microgateway v.2.0.4 a été publié le 25 mai 2016.

Nouvelles fonctionnalités et améliorations v2.0.4

Voici les nouvelles fonctionnalités et améliorations apportées à cette version.

Prise en charge des chemins d'accès aux ressources dans les produits

Edge Microgateway est désormais compatible avec les chemins de ressources dans les produits. Les chemins de ressources vous permettent de limiter l'accès aux API en fonction du suffixe du chemin de proxy. Pour savoir comment créer des produits et configurer des chemins de ressources, consultez Créer des produits d'API.

Assistance pour l'installation globale de npm

Vous pouvez désormais installer Edge Microgateway à l'aide de l'option npm -g (globale). Pour en savoir plus sur cette option, consultez la documentation npm.

Version 2.0.0

Edge Microgateway v2.0.0 a été publié le 18 avril 2016.

Nouvelles fonctionnalités et améliorations v.2.0.0

Voici les nouvelles fonctionnalités et améliorations apportées à cette version.

Serveur de processus unique

Edge Microgateway est désormais un serveur de processus unique. Il n'utilise plus de modèle à deux processus où un processus (anciennement appelé "agent") lance Edge Microgateway, le deuxième processus. La nouvelle architecture facilite l'automatisation et la conteneurisation.

Fichiers de configuration avec espace de noms

Les fichiers de configuration sont désormais associés à un espace de noms utilisant l'organisation et l'environnement, ce qui permet d'exécuter plusieurs instances Microgateway sur le même hôte. Vous trouverez les fichiers de configuration dans ~/.edgemicro après avoir exécuté la commande de configuration Edge Microgateway.

Nouvelles variables d'environnement

Il existe désormais quatre variables d'environnement : EDGEMICRO_ORG, EDGEMICRO_ENV, EDGEMICRO_KEY et EDGEMICRO_SECRET. Si vous définissez ces variables sur votre système, vous n'avez pas à spécifier leurs valeurs lorsque vous utilisez l'interface de ligne de commande (CLI) pour configurer et démarrer Edge Microgateway.

Configuration mise en cache

Edge Microgateway utilise un fichier de configuration mis en cache s'il redémarre sans connexion à Apigee Edge .

Cluster mode (Mode du cluster)

Il existe désormais des options permettant de démarrer Edge Microgateway en mode cluster. Le mode cluster vous permet de profiter des systèmes multicœurs. La micro-passerelle utilise le module de cluster Node.js pour cette fonctionnalité. Pour en savoir plus, consultez la documentation Node.js.

Bugs résolus v2.0.0

Le cycle de vie des événements de plug-in gère désormais correctement le code asynchrone contenant du code avec un nouveau rappel.

Version 1.1.2

Edge Microgateway v. 1.1.2 a été publié le 14 mars 2016.

Nouvelles fonctionnalités et améliorations v.1.1.2

Voici les nouvelles fonctionnalités et améliorations apportées à cette version.

Amélioration des performances

Edge Microgateway utilise désormais correctement l'agent HTTP Node.js pour un meilleur regroupement de connexions. Cette amélioration permet d'améliorer les performances et la stabilité globale en cas de charge élevée.

Compatibilité avec le débogueur à distance

Vous pouvez configurer Edge Microgateway pour qu'il s'exécute avec un débogueur à distance, comme node-inspector.

Nouvel emplacement du fichier de configuration

Lorsque vous configurez Edge Microgateway, le fichier agent/config/default.yaml est désormais copié dans ~./edgemicro/config.yaml.

Rotation des fichiers journaux

Un nouvel attribut de configuration vous permet de spécifier un intervalle de rotation pour les journaux Edge Microgateway.

Bugs corrigés v1.1.2

Les bugs suivants sont résolus dans la version 1.1.2.