Notes de version d'Edge MicroGate

Vous consultez la documentation Apigee Edge.
Accéder à la documentation d'Apigee X en savoir plus

Version 3.3.x

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

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 chaque composant étant 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 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.2. Notez que chaque composant étant 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 chaque composant étant 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 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.0. Notez que chaque composant étant 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 chaque composant étant 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 chaque composant étant 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 chaque composant étant 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 répertorie les numéros de version des projets de composants individuels associés à Edge Microgateway 3.2.0. Notez que chaque composant étant 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 chaque composant étant 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 chaque composant étant 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 chaque composant étant 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 chaque composant étant 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 a été résolu dans la version 3.1.3. La version 3.1.3 a été marquée comme obsolète dans le dépôt npm. Sinon, toutes les corrections de bugs et améliorations décrites dans la note 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 chaque composant étant 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 entraînant des fuites de mémoire dans le module de débogage Node.js a été résolu. Le problème existe dans les versions 3.1.0, 3.1.1 et 3.1.2.
• 153509313 - Correction d'un problème entraînant l'affichage du même ID de message pour deux transactions différentes dans la sortie de journalisation.
• 151673570 – Edge Microgateway n'était pas mis à jour pour utiliser les nouvelles API KVM Apigee. Ce problème a été résolu. 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 son traitement du mappage des chemins d'accès aux ressources corresponde à celui d'Apigee Edge. Dans cette version, un problème a été résolu : le schéma /literal_string/* n'était pas géré correctement. Exemple : /*/2/*. Consultez également la section Configurer le comportement d'un chemin d'accès à la ressource "/", /* et /**.
• 152005003 - Des modifications ont été apportées pour activer les identifiants à l'échelle de l'organisation et de l'environnement pour les quotas.
• 152005003 - Des modifications ont été apportées pour activer les identifiants à l'échelle de l'organisation et de l'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 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 chaque composant étant 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 à la prise en charge du proxy HTTP pour le trafic entre Edge Microgateway et les cibles backend. En outre, des problèmes ont été résolus concernant la compatibilité du proxy HTTP existant entre Edge Microgateway et Apigee Edge. Pour en savoir plus, consultez les pages suivantes :
  • Utiliser un proxy HTTP pour communiquer avec Apigee Edge
  • Utiliser un proxy HTTP pour la communication cible
• 149101890 - Le code de notification de journal pour les cas où le serveur cible ou l'équilibreur de charge ferme sa connexion a été modifié de ERROR à INFO.
• 150746985 – La commande edgemicro verify ne fonctionnait pas correctement si redisBasedConfigCache: true ou quotaUri: https://%s-%s.apigee.net/edgemicro-auth étaient présents dans le fichier de configuration. Ce problème a été résolu.
• 151284716 : amélioration permettant de fermer les connexions au serveur plus rapidement lors du redémarrage des nœuds de calcul lors d'un rechargement.
• 151588764 - Passez à la version 12 de Node.js dans l'image Docker utilisée pour exécuter Edge Microgateway dans un conteneur Docker, car Node.js v8 est obsolète.
• 151306049 : une mise à jour de la documentation a été apportée pour répertorier les API de gestion Apigee Edge utilisées par les commandes CLI Edge Microgateway. Consultez la section Quelles API de gestion utilise Edge Microgateway ?.

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 chaque composant étant un projet distinct, les numéros de version peuvent ne pas correspondre à la version principale du produit:

Correction de bugs et améliorations:

• 146069701 – Le module microgateway-core ne respectait pas les variables d'environnement HTTP_PROXY et HTTPS_PROXY. Ce problème a été résolu. Avec cette modification, les paramètres 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 paramètre de configuration, edgemicro.headers_timeout. Cet attribut limite le temps (en millisecondes) que doit attendre l'analyseur HTTP avant 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 pour les requêtes. (Valeur par défaut: 5 secondes de plus que le temps défini avec edgemicro.keep_alive_timeout. Ce paramètre par défaut empêche les équilibreurs de charge ou les proxys de supprimer la connexion par erreur.)

• 149278885 - Une nouvelle fonctionnalité a été ajoutée qui vous permet de définir le délai d'expiration de l'API cible au niveau du proxy d'API au lieu d'utiliser un paramètre de délai d'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 avant expiration spécifiques au point de terminaison cible. Si ce paramètre n'est pas appliqué, Edge Microgateway utilise le délai avant expiration global spécifié avec edgemicro.request_timeout.

3.1.0

Le mardi 21 janvier, 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.0. Notez que chaque composant étant 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 nouvel événement de niveau "WARN" est consigné lorsque l'indicateur quotas.failOpen est déclenché. Cet indicateur est déclenché si une erreur de traitement du quota se produit ou si la demande « quota appliqué » à Edge ne parvient pas à mettre à jour les compteurs de quota distants. Dans ce cas, le quota ne sera traité en fonction de la comptabilisation locale que jusqu'à la prochaine synchronisation à distance du quota. Auparavant, cet événement n'était consigné 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 – Un problème a été résolu dans lequel des transactions en cours ou nouvelles en cours de transfert étaient affectées chaque fois qu'Edge Microgateway détecte une modification dans un proxy d'API. Désormais, lorsqu'une modification est apportée à un proxy, Edge Microgateway actualise le cache et redémarre les nœuds de calcul. Ce changement n'a aucune incidence sur les transactions en cours de transfert et les nouveaux appels d'API envoyés à la microgateway.
• 146378327 - Le niveau de journalisation de sourceRequest, targetRequest et targetResponse est passé au niveau INFO.
• 146019878 - L'écart entre la latence calculée pour les "performances du proxy d'API" dans l'analyse Edge et les événements de journal sourceResponse/targetResponse d'Edge Microgateway a été corrigé. Désormais, la latence de l'analyse Edge et des événements de journaux Microgateway est alignée.
• Modifications liées à la logique de correspondance de structure :
  • 147027862 - Le plug-in OAuth a été mis à jour pour accepter les formats de correspondance de chemin d'accès aux ressources suivants, comme spécifié dans la section "Produits d'API" :
    • /{literal}**
    • /{literal}*
    • Toute combinaison des deux modèles ci-dessus

    Avec cette modification, le plug-in Edge Microgateway suit désormais le même schéma qu'Apigee Edge, comme expliqué dans la section Configurer le comportement d'un chemin d'accès à une ressource "/", /*' et /**'.

  • 145644205 - Mise à jour de la logique de correspondance de format du plug-in apiKeys pour qu'elle corresponde au plug-in OAuth.
• 143488312 - Correction d'un problème entraînant le vide de la liste de produits JWT lors de la création de la liste de produits JWT pour les requêtes de jeton OAuth et de clé API, grâce aux espaces de début ou de fin dans le paramètre d'ID client.
• 145640807 et 147579179 : une nouvelle fonctionnalité a été ajoutée. Elle permet à une instance Edge Microgateway spéciale appelée "le 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 micropasserelle de démarrer et de fonctionner sans avoir à 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 chaque composant étant 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 de ressources utilisés dans les produits d'API pour Edge Microgateway s'aligne désormais sur celle utilisée par Apigee Edge, comme décrit dans la section Configurer le comportement d'un chemin de ressource "/", /*' 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 de développement du proxy, comme illustré dans la capture d'écran suivante:

  

  Remarque: La propriété de configuration features.isSingleForwardSlashBlockingEnabled, comme décrit dans la section Configurer le comportement d'un chemin d'accès à une ressource "/", /* et /**, n'est pas compatible avec Edge Microgateway.

• 143740696 : la structure de configuration quotas a été modifiée (consultez également les notes de version pour la version 3.0.9). La propriété quotas permet de configurer le plug-in de quota. Ce changement de structure a été apporté pour améliorer la clarté des éléments de configuration. Pour configurer le plug-in de quota, utilisez la configuration YAML suivante. Notez que la propriété de configuration est appelée quotas. Pour en savoir plus sur les propriétés de configuration quotas individuelles, consultez la section 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é vous permettant d'utiliser Redis comme magasin de sauvegarde de quota a été ajoutée. Si useRedis est "true", le module volos-quota-redis est utilisé. Lorsque la valeur est "true", le quota est limité aux seules instances Edge Microgateway qui se connectent à Redis. Si la valeur est "false", le module volos-quota-apigee est utilisé comme magasin de sauvegarde et le compteur de quota est global. Pour en savoir plus, consultez la section Options de configuration des 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 assurer la compatibilité avec les organisations sur lesquelles SAML est activé, 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/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 répertorie les numéros de version des projets de composants individuels associés à Edge Microgateway 3.0.9. Notez que chaque composant étant 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é de "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 demande de "quota appliqué" à Edge ne parvient pas à mettre à jour les compteurs de quota distants, le quota est traité sur la base des décomptes 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 la requête.

  Pour activer la fonctionnalité de "fail open" de quota, définissez la configuration suivante:

  quotas :
   failOpen : true

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

• 142093764 : modification de la configuration du 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 aux quotas. 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 consigné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 chaque composant étant 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é de type "fail open" a été ajoutée. Cette fonctionnalité permet de poursuivre le traitement de l'API si un jeton JWT expiré ne peut pas être actualisé en raison d'une erreur de connexion qui empêche l'appel de validation de clé API au proxy edgemicro-auth.

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

  Pour configurer la nouvelle fonctionnalité "fail open", procédez comme suit:

  1. Définissez les propriétés suivantes dans le bloc 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 est renvoyée.

• 141168968 - Mise à jour pour inclure correlation_id dans la sortie du journal du plug-in. De plus, les niveaux de journalisation de certains journaux ont été définis sur error, si nécessaire.
• 140193349 : une mise à jour a été apportée au proxy edgemicro-auth pour exiger que la clé et le secret Edge Microgateway doivent être vérifiés à chaque requête de vérification de clé API. Edge Microgateway a été mis à jour de manière à toujours envoyer la clé et le code secret à chaque requête Verify API Key. Cette modification empêche les clients d'obtenir un jeton JWT avec uniquement une clé API.
• 140090250 : mise à jour visant à ajouter le journal de diagnostic pour le traitement des quotas. Avec cette modification, il est maintenant possible de corréler la sortie du journal quoto 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 répertorie les numéros de version des projets de composants individuels associés à Edge Microgateway 3.0.7. Notez que chaque composant étant un projet distinct, les numéros de version peuvent ne pas correspondre à la version principale du produit:

Correction de bugs et améliorations:

• 140075602 - Mise à jour du plug-in OAuth permettant de renvoyer un code d'état 5xx, le cas échéant. Auparavant, le plug-in ne renvoyait que les codes d'état 4xx dans tous les cas autres que 200. Désormais, pour toute réponse de message qui n'est pas un état 200, le code 4xx ou 5xx exact est 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 a été ajoutée, quota.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://%s-%s.apigee.net/edgemicro-auth

  Dans la version 3.0.7, 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 l'authentification. En outre, le proxy edgemicro-auth a été modifié afin de supprimer "organisation" de l'identifiant de quota. Étant donné que le point de terminaison du quota se trouve dans l'organisation du client, l'identifiant de quota n'est plus nécessaire.
• 140823165 - Le nom de propriété suivant :

  edgemicro:
      keepAliveTimeout

  n'a pas été documenté correctement dans la version 3.0.6. Le nom de propriété correct est:

  edgemicro:
      keep_alive_timeout

• 139526406 - Un bug qui empêchait un nombre incorrect de compter lorsqu'une application de développement comportait plusieurs produits a été corrigé. Le quota est désormais appliqué correctement pour chaque produit dans 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 correctifs et améliorations suivants pour Edge Microgateway.

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

  Exemple :

  edgemicro:
    keep_alive_timeout: 600

• 140090623 – Ajout d'une 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 propriété de configuration, stack_trace. Cette propriété vous permet de contrôler si les traces de la pile apparaissent ou non dans les fichiers journaux. Exemple :

  stack_trace: false

  Si stack_trace est défini sur true, la trace de la pile est imprimée dans les journaux. Si elle est définie sur false, la trace de la pile n'est 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 empêchant la commande edgemicro status de renvoyer le nombre approprié 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 les niveaux de journalisation trace et debug pour les événements et les journaux système. Pour l'instant, seule la possibilité d'ajouter ces niveaux de journalisation 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 journalisation de la console. Les instructions de journalisation de la console incluent désormais les attributs suivants:
• Code temporel
• Nom du composant
• ID du processus
• Message du journal de la console

• 138413755 - Amélioration des messages de journal liés aux secrets et aux clés JWT pour les commandes CLI: cert, Verify, upgradekvm, jeton, genkeys, révocations, rotationkey et configure.

• 138413577 - Ajout et amélioration de la gestion des erreurs pour les délais avant expiration du service de backend.
• 138413303 - Ajouter et améliorer la gestion des erreurs pour les délais avant expiration de réponse et de socket.
• 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 de l'authentification interne Edge Microgateway.
• 137582169 – Correction d'un problème entraînant le démarrage de processus indésirables Ces processus supplémentaires entraînaient l'actualisation des plug-ins et utilisaient une mémoire excessive. Edge Microgateway maintient désormais le nombre de processus dans la limite prévue.
• 137768774 - Améliorations des messages de journal :
  • Journaux de transactions (requête) nettoyés
  • Ajout d'autres messages de journal si nécessaire.
  • Déplacement des messages de journal de transaction (requête) de la sortie de la console vers le fichier journal approprié.
  • 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 de quota.

3.0.3

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

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

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

  L'exemple suivant illustre le format du journal:

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

  (137770055)

• Performance: les produits d'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 : la qualité du code a été examinée, et des modifications ont été apportées au code afin de répondre aux normes de qualité demandées par les utilisateurs. Nous avons traité les erreurs et les avertissements liés à la qualité du code issus de JSHint. En conséquence, certaines erreurs de code réelles 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 dont la qualité du code a été modifiée 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 de Node.js compatibles pour Edge Microgateway
  (versions compatibles avec Node.js: 8 et 12 ; les versions 7, 9 et 11 sont expérimentales)
• 134751883 - Edge Microgateway plante lors du rechargement en charge
• 134518428 - Le point de terminaison du produit pour Edge Microgateway renvoie 5XX si le format 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 - Le calcul du délai de grâce dans OAuth n'est pas correct
• Utilisez le module mémo fourni avec l'installation d'Edge Microgateway
• 135367906 - Audit de sécurité

Version 2.5.x

Nouvelles fonctionnalités et améliorations v2.5.x

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

Un format de jeton JWT incorrect peut 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 de 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 la page Gérer les certificats.

(Ajout de la version 2.5.35) Prise en charge du débogage d'Edge Microgateway à l'aide de edgemicroctl.

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

(Ajouté la version 2.5.35) Activez un build Windows pour edgemicroctl.

(Ajout de la version 2.5.31) Nouvelle API Edgemicro-auth/token

Ajout d'une nouvelle API Edgemicro-auth/token qui vous permet de transmettre le client/code secret en tant qu'en-tête d'autorisation de base encodé en base64 et le paramètre "grant_type" comme paramètre de formulaire. Consultez la section Obtenir directement des jetons de support.

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

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

Docker: prise en charge de l'utilisation de certificats autosignés

(Ajouté la version 2.5.29) Si vous utilisez une autorité de certification 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 de la version 2.5.29) Edge Microgateway s'exécutant dans un conteneur Docker est désormais compatible avec TLS pour les requêtes entrantes adressées au serveur Edge Microgateway (requêtes vers le nord) et pour les requêtes sortantes depuis Edge Microgateway vers une application cible (requêtes Sud).

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

• Exemple de configuration de TLS pour la liaison nord
• Exemple de configuration de la liaison TLS vers le sud

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

Docker: compatibilité avec la transmission de requêtes par proxy

(Ajouté la version 2.5.27) Si vous exécutez Edge Microgateway dans un conteneur Docker, vous pouvez utiliser ces options pour contrôler le comportement du proxy lorsque la microgateway s'exécute 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 de mise à jour du plug-in

(Ajouté la version 2.5.27) Si vous exécutez Edge Microgateway dans un conteneur Docker, vous avez désormais deux options pour déployer des plug-ins. Une nouvelle option consiste à utiliser un point d'installation Docker. L'autre option existait auparavant. Toutefois, le Dockerfile a été mis à jour. Pour en savoir plus, consultez les liens suivants:

• Option A: Installer le répertoire de plug-ins sur un volume (nouveau)
• Option B: Créer les plug-ins dans le conteneur (mise à jour)

Prise en charge des jetons OAuth pour la commande de mise à niveau KVM

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

Ségrégation des API dans Edge Analytics

(Ajouté 2.5.26) De 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 des appels d'API réels. Pour en savoir plus, consultez la section Exclure des chemins d'analyse.

Configurer un proxy local

(Ajouté la version 2.5.25) Avec un proxy local, vous n'avez pas besoin de créer manuellement un proxy compatible avec les micropasserelles sur Apigee Edge. À la place, la micropasserelle utilise le chemin de base du proxy local. Pour en savoir plus, consultez la section Utiliser le mode proxy local.

Utiliser le mode autonome

(Ajouté la version 2.5.25) 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. Consultez la section Exécuter Edge Microgateway en mode autonome.

Révocation de clés

(Ajouté la version 2.5.19) Une nouvelle commande CLI qui révoque les identifiants de clé et de secret pour une configuration Edge Microgateway a été ajoutée.

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

Compatibilité avec Docker

(Ajouté la version 2.5.19) Vous pouvez maintenant 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é la version 2.5.19) 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 la présentation de l'intégration d'Edge Microgateway dans Kubernetes.

Compatibilité avec l'option de configuration de nœuds TCP

(Ajouté 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 Nagle pour mettre les données en mémoire tampon avant de les envoyer. Définir nodelay sur true désactive ce comportement (les données sont immédiatement déclenché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 une surveillance permanente

(Ajout de 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 permanent en arrière-plan. Voir aussi Surveillance permanente.

Exemples :

Pour lancer l'application indéfiniment:

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

Pour arrêter définitivement:

edgemicro forever -a stop

Rotation des clés JWT

Nous avons ajouté une nouvelle fonctionnalité qui 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 la section Faire pivoter des 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 commençant par le préfixe de nom "edgemicro_". Vous pouvez modifier cette valeur par défaut pour télécharger des proxys dont le nom correspond à un modèle. Consultez la section Filtrer les proxys téléchargés.

Spécifier des produits sans proxy 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. Depuis la version 2.5.4, Edge Microgateway est compatible avec cette configuration de produit.

Prise en charge d'une surveillance permanente

Edge Microgateway comporte un fichier forever.json que vous pouvez configurer pour contrôler le nombre de redémarrages et l'intervalle d'intervalle nécessaires. Ce fichier configure un service appelé forever-monitor, qui gère Forever de manière automatisée. Consultez la section Surveillance ininterrompue.

Gestion centrale 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 dans lequel Edge Micro peut télécharger son fichier de configuration. Consultez la section Spécifier un point de terminaison de fichier de configuration.

Prise en charge de l'option de CLI Always

(Ajouté 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 d'Edge Microgateway.

Exemple :

edgemicro forever ~/mydir/forever.json

Ajout de l'option "configUrl" pour actualiser la commande

(Ajout de 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 en cas d'échec du délai JWT

(Ajout de 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 votre horloge système et les dates Nbf (Pas avant) ou Émission (IAt) spécifiées dans le jeton d'autorisation JWT. Définissez cet attribut sur le nombre de secondes pour permettre ces écarts. Consultez la section Attributs OAuth.

(Ajout de 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 votre horloge système et les dates Nbf (Pas avant) ou Émission (IAt) spécifiées dans le jeton d'autorisation JWT. Définissez cet attribut sur le nombre de secondes pour permettre ces écarts. Consultez la section Attributs OAuth.

Bugs corrigés dans la version 2.5.x

• (Problème 236) Correction d'une faute de frappe lors de la suppression du cache.
• (Problème 234) Le rechargement plante pour Edge Microgateway 2.5.35.
• (Problème 135) Erreur de référence d'hôte virtuel "secure" non valide lors de l'utilisation de l'option -v. Ce correctif modifie le proxy Edgemicro-auth avant le déploiement pour garantir 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é aux paramètres par défaut et sécurisés).
• (Problème n° 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 signale l'abandon des cryptomonnaies au moment 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- two-api-proxies-a.html#answer-33336) Jeton JWT validé par rapport aux proxys d'API et à l'URI de ressource 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) Microgateway ne fonctionne pas avec OAuth. Ce problème a été résolu.
• Correction du 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) Mise à jour des dépendances Node.js (audit npm)
• Le proxy edgemicro-auth utilise désormais les stratégies JWT Edge. Le proxy ne dépend plus de Node.js pour assurer la compatibilité avec les jetons JWT.

Version 2.4.x

Nouvelles fonctionnalités et améliorations v2.4.x

1. Définissez 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 la modifier, utilisez l'indicateur -x dans la commande edgemicro configure.

Exemple :

edgemicro configure -x /mypath …

2. Prise en charge 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 avoir à créer de nouveaux proxys d'API pour prendre en charge les nouvelles équipes. Notez que /**/ n'est pas accepté.

3. Chemin de configuration personnalisé ajouté à la CLI pour la configuration d'un cloud privé (PR 99)

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

Exemple :

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

4. Respectez 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, vous pouvez envisager deux options:

Option 1 :

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

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 via une seule connexion TCP. Il en va de même si le protocole TLS est activé dans les variables d'environnement permettant de configurer le proxy.

Option 2 :

La deuxième option consiste à spécifier un proxy et à définir proxy_tunnel sur false dans le fichier de configuration de 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 ceux qui ne doivent pas gérer les proxys Edge Microgateway : HTTP_PROXY, HTTPS_PROXY et NO_PROXY. Vous pouvez définir NO_PROXY en tant que liste de domaines séparés par une virgule vers lesquels Edge Microgateway ne doit pas utiliser de proxy. Exemple :

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

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

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

5. Définition d'un délai d'inactivité personnalisé pour les requêtes cibles (PR 57)

Vous pouvez définir un délai d'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 d'expiration du délai, Edge Microgateway répond avec un code d'état 504.

6. Respect des messages d'état HTTP personnalisés sur la réponse cible (PR 53)

Edge Microgateway respecte les messages d'état HTTP personnalisés définis sur la réponse cible. Dans les versions précédentes, les messages d'état envoyés par 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 le client_ip pour l'analyse

Si elle est présente, l'en-tête X-Forwarded-For définit la variable client_ip 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 l'une ou l'autre des formes de sécurité. Avec ce changement, vous ne pouvez autoriser qu'un seul de ces modèles de sécurité (tout en maintenant la rétrocompatibilité).

Les plug-ins OAuth ajoutent deux nouveaux indicateurs:

• allowOAuthOnly : si ce paramètre est défini sur true, chaque API doit comporter un en-tête d'autorisation avec un jeton d'accès de support.

• allowAPIKeyOnly : si la valeur est 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)

Le proxy edgemicro-auth a été amélioré. Avant ces modifications, le proxy stockait des clés dans Edge Secure Store, un coffre-fort chiffré. À présent, le proxy stocke les clés dans le mappage clé-valeur (KVM) chiffré d'Edge.

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

Vous pouvez également ignorer le port du point de terminaison cible et choisir entre HTTP et HTTPS. Modifiez les variables suivantes 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 plus d'informations.

11. Compatibilité initiale avec l'authentification par jeton OAuth (PR 125)

Vous pouvez configurer Edge Microgateway afin d'utiliser un jeton OAuth pour l'authentification au lieu du nom d'utilisateur/mot de passe. Pour utiliser un jeton OAuth, utilisez le paramètre suivant dans la commande edgemicro configure:

-t, --token <token>

Exemple :

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

Bugs corrigés 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 des organisations d'essai. (PR 5)
• Correction d'un problème dans lequel le flux n'était pas terminé de traiter les données, mais les gestionnaires de fin s'exécutaient malgré tout. Cela entraînait l'envoi d'une réponse partielle. (PR 71)
• Correction d'un problème qui empêchait de reconnaître un répertoire de configuration personnalisé pour les installations de Private Cloud. (PR 110)
• Correction d'un problème de SSL bidirectionnel entre le client et Edge Microgateway. (PR 70)
• Correction d'un problème où une barre oblique finale était requise sur le chemin de base du proxy pour que la vérification de la clé API fonctionne correctement. Il n'est plus nécessaire de disposer d'une barre oblique à la fin du chemin de base. (PR 48)

Version 2.3.5

Nouvelles fonctionnalités et améliorations v2.3.5

Filtrage proxy

Vous pouvez filtrer les proxys compatibles avec la micro-passerelle qu'une instance Edge Microgateway traitera. Lorsque Edge Microgateway démarre, il télécharge tous les proxys compatibles avec les micro-passerelles dans l'organisation à laquelle il est associé. Utilisez la configuration suivante pour limiter les proxys traités par la micropasserelle. Par exemple, cette configuration limite le nombre de proxys que la micropasserelle traitera à trois: 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 de chemin de requête dans les analyses Edge. Ajoutez le code suivant à la configuration de la micro-passerelle 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 v2.3.3

Vous trouverez ci-dessous les nouvelles fonctionnalités et améliorations de cette version.

Désactiver la détection des modifications automatiques

Vous pouvez désactiver la détection automatique des modifications en définissant cet attribut dans la configuration de la microgateway:

disabled_config_poll_interval: true

Par défaut, l'interrogation périodique récupère toutes les modifications apportées sur Edge (modifications apportées aux produits, aux proxys compatibles avec les micropasserelles, 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 suivantes dans le code de celui-ci: req.targetHostname et req.targetPath.

Signature de la nouvelle fonction du plug-in

Une nouvelle signature de fonction de plug-in a été ajoutée. Elle fournit la réponse cible en tant qu'argument. Cet ajout 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 utiliser la valeur par défaut pour générer ces objets 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 microgateway se trouve dans ./config/config.yaml. Dans les commandes init, configure et start, vous pouvez désormais spécifier un chemin d'accès à la configuration personnalisé sur la ligne de commande. Exemple :

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

Bugs corrigés 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 du plug-in a été corrigé. Il se comporte désormais comme expliqué dans la documentation.
• Le plugin "cumul-request" ne se bloque plus pour les requêtes GET.
• Un problème a été résolu dans le plug-in d'accumulation de réponses : l'absence de corps de réponse provoquait des erreurs.

Version 2.3.1

Remarque concernant 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 rubrique d'installation.

Nouvelles fonctionnalités et améliorations v2.3.1

Vous trouverez ci-dessous les nouvelles fonctionnalités et améliorations de cette version.

Filtrer les proxys

Une nouvelle configuration vous permet de filtrer les proxys qu'Edge Microgateway charge au démarrage. Auparavant, la microgateway charge tous les proxys compatibles avec la micro-passerelle (proxys nommés Edgemicro_*) extraits de l'organisation/de l'environnement Edge que vous avez spécifiés dans la commande de configuration Edgemicro. Cette nouvelle fonctionnalité vous permet de filtrer cette liste de proxys afin qu'Edge Microgateway ne charge que ceux que vous spécifiez. Ajoutez simplement l'élément "proxys" au fichier de configuration de microgateway comme suit:

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

Par exemple, supposons que vous ayez 50 proxys edgemicro_* dans votre organisation/env Edge, y compris ceux nommés edgemicro_foo et edgemicro_bar. Vous pouvez indiquer à la micropasserelle 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 ou de l'environnement Edge entraînera une erreur.

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

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

Examinons un 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, dans ce cas, il n'était pas possible de définir des en-têtes cibles de manière fiable.

La clé de ce modèle consiste d'abord à 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 a été utilisé dans les exemples de plug-ins 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é d'actualisation sans temps d'arrêt

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

En outre, trois nouvelles commandes CLI ont été ajoutées. Vous devez exécuter les commandes suivantes à partir du répertoire dans 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 ou non.
• edgemicro stop : arrête le cluster Edge Microgateway.
• edgemicro reload : recharge la configuration Edge Microgateway sans temps d'arrêt.

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

Edge Microgateway charge régulièrement une nouvelle configuration et effectue une actualisation en cas de changement. L'interrogation récupère toutes les modifications apportées à Edge (modifications apportées aux produits, aux proxys compatibles avec la micropasserelle, 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). Vous pouvez modifier la valeur par défaut dans le fichier de configuration de la microgateway comme suit:

edgemicro:
    config_change_poll_interval: [seconds]

Ajout d'informations de version à la CLI

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

edgemicro --version

Nouvelles options SSL du 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 à stdout

Un nouveau paramètre de configuration vous permet d'envoyer des données de journal vers la sortie standard:

edgemicro:
  logging:
    to_console: true  

Consultez la section Gérer les fichiers journaux.

Version 2.1.2

Vous trouverez ci-dessous les nouvelles fonctionnalités et améliorations de cette version.

Autoriser le point de terminaison de l'API personnalisé pour la configuration

Il existe de nouveaux points de terminaison configurables pour le proxy d'autorisation qui permettent d'utiliser un service d'authentification personnalisé. Ces points de terminaison sont:

• edgeconfig:verify_api_key_url
• edgeconfig:products

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

Version 2.1.1

Vous trouverez ci-dessous les nouvelles fonctionnalités et améliorations de cette version.

Déployer un proxy d'authentification compatible avec plusieurs plates-formes

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/TSL aux cibles à l'aide d'un nouvel ensemble d'options de configuration. Consultez la section Utiliser les options SSL/TSL 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 rubrique d'installation.

Nouvelles fonctionnalités et améliorations v2.0.11

Voici les nouvelles fonctionnalités et améliorations:

Spécifier un port au démarrage

La commande start vous permet d'indiquer un numéro de port pour remplacer celui spécifié dans le fichier de configuration. Vous pouvez également spécifier un numéro de port à l'aide de la variable d'environnement PORT. Consultez la section Commande start pour plus de détails.

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. S'il est défini sur "true", l'en-tête Auth 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ée le 25 mai 2016.

Nouvelles fonctionnalités et améliorations v2.0.4

Vous trouverez ci-dessous les nouvelles fonctionnalités et améliorations de cette version.

Compatibilité avec les 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 d'accès aux ressources vous permettent de limiter l'accès aux API en fonction du suffixe du chemin d'accès du proxy. Pour plus d'informations sur la création de produits et la configuration des chemins d'accès aux ressources, consultez la page Créer des produits API.

Compatibilité avec npm global install

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

Version 2.0.0

La version 2.0.0 d'Edge Microgateway a été publiée le 18 avril 2016.

Nouvelles fonctionnalités et améliorations v2.0.0

Vous trouverez ci-dessous les nouvelles fonctionnalités et améliorations de cette version.

Serveur à processus unique

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

Fichiers de configuration en espace de noms

Les fichiers de configuration sont désormais associés à un espace de noms à l'aide de l'organisation et de l'environnement, ce qui permet à plusieurs instances Microgateway peuvent s'exécuter sur le même hôte. Vous pouvez trouver 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 besoin de spécifier leurs valeurs lorsque vous utilisez l'interface de ligne de commande (CLI) pour configurer et démarrer Edge Microgateway.

Configuration en cache

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

Mode du cluster

Des options permettent désormais de démarrer Edge Microgateway en mode cluster. Le mode cluster vous permet de tirer parti des systèmes multicœurs. La microgateway utilise le module de cluster Node.js pour cette fonctionnalité. Pour en savoir plus, consultez la documentation Node.js.

Bugs corrigés dans la version 2.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

La version 1.1.2 d'Edge Microgateway a été publiée le 14 mars 2016.

Nouvelles fonctionnalités et améliorations v.1.1.2

Vous trouverez ci-dessous les nouvelles fonctionnalités et améliorations de cette version.

Amélioration des performances

Désormais, Edge Microgateway utilise correctement l'agent HTTP Node.js pour améliorer le regroupement des connexions. Cette amélioration améliore les performances et la stabilité globale en cas de charge élevée.

Compatibilité avec le débogueur distant

Vous pouvez configurer Edge Microgateway pour qu'il s'exécute avec un débogueur distant, tel que node-inspector.

Nouvel emplacement du fichier de configuration

Lorsque vous configurez Edge Microgateway, le fichier agent/config/default.yaml est maintenant 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 dans la version 1.1.2

Les bugs suivants ont été corrigés dans la version 1.1.2.