Notes de version d'Edge MicroGate

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

Version 3.3.x

Correction de bugs et améliorations dans la version 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 de chaque projet de composant. associés avec Edge Microgateway 3.3.3. 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 correctifs et améliorations suivants pour Edge Microgateway.

Versions des composants:

Le tableau suivant répertorie les numéros de version de chaque projet de composant. associés avec Edge Microgateway 3.3.2. 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

Aucun

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 de chaque projet de composant. associés avec Edge Microgateway 3.3.1. 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 correctifs et améliorations suivants pour Edge Microgateway.

Versions des composants:

Le tableau suivant répertorie les numéros de version de chaque projet de composant. associés avec Edge Microgateway 3.3.0. 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 dans la version 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 de chaque projet de composant. associés avec Edge Microgateway 3.2.3. 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 de chaque projet de composant. associés avec Edge Microgateway 3.2.2. 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 de chaque projet de composant. associés avec Edge Microgateway 3.2.1. 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 répertorie les numéros de version de chaque projet de composant. associés avec Edge Microgateway 3.2.0. 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 dans la version 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 de chaque projet de composant. associés avec Edge Microgateway 3.1.8. 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 de chaque projet de composant. associés avec Edge Microgateway 3.1.7. 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 de chaque projet de composant. associés avec Edge Microgateway 3.1.6. 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 de chaque projet de composant. associés avec Edge Microgateway 3.1.5. 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 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 Les corrections de bugs et les améliorations décrites dans les notes de publication de la 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 de chaque projet de composant. associés avec Edge Microgateway 3.1.3. 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 entraînant des fuites de mémoire par le module de débogage Node.js Le problème se produit dans les versions 3.1.0, 3.1.1 et 3.1.2.
• 153509313 – Un problème a été résolu lorsque le même identifiant de message était utilisé pour deux transactions différentes. a été imprimée dans la sortie de journalisation.
• 151673570 - Un problème a été résolu : Edge Microgateway n'a pas été mis à jour pour utiliser la nouvelle API KVM Apigee. Edge Microgateway utilise désormais les nouvelles commandes pour ajouter et mettre à jour le KVM.
• 152822846 : dans les versions précédentes, Edge Microgateway a été mis à jour de sorte que son traitement du mappage de chemin d'accès aux ressources correspond à celui d'Apigee Edge. Dans cette version, un problème a été résolu où le format /literal_string/* n'a pas été géré correctement. Exemple : /*/2/*. Voir également Configurer le comportement d'un chemin d'accès à une 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. Combinaison de "org + env + appName + productName" est utilisé comme quota identifiant.

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 de chaque projet de composant. associés avec Edge Microgateway 3.1.3. 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 afin d'ajouter la prise en charge du proxy HTTP pour le trafic entre Edge Microgateway et les cibles backend. De plus, les problèmes liés au protocole HTTP existant proxy entre Edge Microgateway et Apigee Edge. Pour en savoir plus, consultez les pages suivantes: <ph type="x-smartling-placeholder">
  </ph>
  • Utiliser un proxy HTTP pour la communication avec Apigee Edge
  • Utiliser un proxy HTTP pour la communication cible
• 149101890 : code de notification de journal pour les cas où le serveur cible ou l'équilibreur de charge ferme sa connexion est passé de ERROR à INFO.
• 150746985 : un problème a été résolu lorsque la commande edgemicro verify n'était pas fonctionne correctement si redisBasedConfigCache: true ou quotaUri: https://%s-%s.apigee.net/edgemicro-auth étaient présentes dans le fichier de configuration.
• 151284716 : une amélioration a été apportée pour accélérer la fermeture des connexions au serveur lorsque les nœuds de calcul redémarre lors d'une actualisation.
• 151588764 - Mettre à jour la version 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é effectuée pour lister la gestion d'Apigee Edge API utilisées par les commandes CLI Edge Microgateway. Voir <ph type="x-smartling-placeholder"></ph> 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 de chaque projet de composant. associés avec Edge Microgateway 3.1.1. 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 – Un problème a été résolu concernant le module microgateway-core ne respectait pas 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é ; 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écifiez 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 – Un nouveau paramètre de configuration, edgemicro.headers_timeout, a été ajouté. Cet attribut limite la durée (en millisecondes) pendant laquelle l'analyseur HTTP doit attendre avant de recevoir la les en-têtes HTTP complets. Exemple :

  edgemicro:
  keep_alive_timeout: 6000
  headers_timeout: 12000

  En interne, le paramètre définit l'instance Node.js Server.headersTimeout dans les requêtes. (Par défaut: 5 secondes de plus que l'heure définie avec edgemicro.keep_alive_timeout. Cette valeur par défaut empêche les équilibreurs de charge ou les proxys de perdre la connexion par erreur.

• 149278885 : nous avons ajouté une fonctionnalité qui vous permet de définir le délai d'expiration cible de l'API Niveau de proxy d'API au lieu d'utiliser un seul 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 peut récupérer cette propriété et appliquer la cible des délais avant expiration spécifiques aux points de terminaison. Si ce paramètre n'est pas appliqué, Edge Microgateway utilise la 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 de chaque projet de composant. associés avec Edge Microgateway 3.1.0. 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 nouvel événement de niveau WARN est consigné lorsque l'indicateur quotas.failOpen est déclenché. Cette option est déclenchée si une erreur de traitement des quotas se produit ou si les conditions demander à Edge ne parvient pas à mettre à jour les compteurs de quota distants. Dans ce cas, le quota est traité en fonction sur les décomptes locaux uniquement jusqu'à ce que la prochaine synchronisation réussie du quota à distance se produise. Auparavant, ce 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 – Correction d'un problème affectant les nouvelles transactions en cours de transfert ou les nouvelles transactions chaque fois qu'Edge Microgateway a détecté une modification d'un proxy d'API. Maintenant, lorsqu'une modification est apportée à un proxy, Edge Microgateway actualise le cache et redémarre les nœuds de calcul. Avec ce changement, les transactions en cours de transfert et les nouveaux appels d'API envoyés à la micropasserelle ne sont pas affectés.
• 146378327 : niveau de journalisation de sourceRequest, targetRequest, et targetResponse ont été définis sur le niveau INFO.
• 146019878 – Écart entre la latence calculée pour "API Proxy Performance" dans Edge Analytics et les événements de journal sourceResponse/targetResponse Edge Microgateway a été ou corriger un problème. La latence dans les événements de journaux Edge Analytics et Microgateway est désormais alignée.
• Modifications liées à la logique de correspondance de format: <ph type="x-smartling-placeholder">
  </ph>
  • 147027862 - Le plug-in OAuth a été mis à jour pour prendre en charge le chemin d'accès à la ressource suivant modèles correspondants comme spécifié dans les produits de l'API: <ph type="x-smartling-placeholder">
    </ph>
    • /{literal}**
    • /{literal}*
    • N'importe quelle combinaison des deux formats ci-dessus

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

  • 145644205 - Mise à jour de la logique de correspondance de modèle du plug-in apiKeys pour qu'elle corresponde au plug-in OAuth.
• 143488312 – Un problème a été résolu concernant la présence d'espaces au début ou à la fin de l'ID client a entraîné le manque de création de la liste de produits JWT pour le jeton OAuth. Requêtes de clés API.
• 145640807 et 147579179 : une nouvelle fonctionnalité a été ajoutée pour permettre l'utilisation d'une passerelle Edge Microgateway spéciale. une instance nommée "the synchroniator" pour récupérer les données de configuration d'Apigee Edge et les écrire à une base de données Redis locale. D'autres instances microgateway peuvent ensuite être configurées pour lire leurs 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 à 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 dans la version 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 de chaque projet de composant. associés avec Edge Microgateway 3.0.10. 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 la fonctionnalité a été effectuée afin que la correspondance de modèle pour les chemins d'accès aux ressources utilisé dans les produits d'API pour Edge Microgateway s'aligne désormais sur la correspondance du modèle de chemin de ressource utilisé par Apigee Edge, comme décrit dans <ph type="x-smartling-placeholder"></ph> Configurer le comportement d'un chemin d'accès à une ressource "/", "/*" et '/**'.

  Remarque: Si vous utilisez un modèle de ressource composé comme /*/2/**, vous doit s'assurer que le proxy edgemicro_auth est ajouté 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 <ph type="x-smartling-placeholder"></ph> La configuration du comportement d'un chemin de ressource "/", /* et /**' n'est pas acceptée. pour Edge Microgateway.

• 143740696 : la structure de configuration quotas a changé (voir aussi les notes de publication de la version 3.0.9). quotas est utilisée pour configurer le plug-in de quota. La modification de la structure a été faite pour améliorer la clarté des éléments de configuration. Pour configurer le plug-in de quota, utilisez la configuration YAML suivante. Notez que s'appelle quotas. Pour en savoir plus sur la configuration quotas individuelle d'hébergement, 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 - Ajout d'une nouvelle fonctionnalité vous permettant d'utiliser Redis comme quota magasin de sauvegarde. Si useRedis est "true", alors volos-quota-redis utilisé. Si la valeur est "true", le quota est limité aux instances Edge Microgateway se connecter à Redis. Si la valeur est "false", le volos-quota-apigee est utilisé comme stockage de sauvegarde et le compteur de quota est global. Pour en savoir plus, consultez <ph type="x-smartling-placeholder"></ph> Options de configuration pour les quotas Exemple :

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

• 140574210 : délai d'expiration par défaut des jetons générés par edgemicro-auth est passé de 108 000 millisecondes (1,8 minute) à 1 800 secondes (30 minutes).
• 143551282 - Pour assurer la compatibilité avec les organisations où le protocole SAML est activé, la commande edgemicro genkeys a a été mis à jour pour inclure un paramètre ‑‑token. Ce paramètre vous permet d'utiliser Jeton OAuth pour l'authentification au lieu du nom d'utilisateur/mot de passe. Pour plus d'informations, voir 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 de chaque projet de composant. associés avec Edge Microgateway 3.0.9. 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 – Nouvel état "fail open" pour le plug-in de quota. Lorsque cette fonctionnalité est activée, en cas d'erreur de traitement des quotas ou si le paramètre "quota s'applique" à Edge l'échec de la mise à jour des compteurs de quota distants, le quota seront traités sur la base de décomptes locaux jusqu'au prochain quota distant réussi la synchronisation est effectuée. Dans les deux cas, un indicateur quota-failed-open est défini dans l'objet de la requête.

  Pour activer le quota de type "fail open" : définissez la configuration suivante:

  quotas :
   failOpen : true

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

• 142093764 - Une modification de la 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 agenda. 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 du MP. ID (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éfinissez la configuration suivante:

  quotas:
    useDebugMpId: true

  Lorsque useDebugMpId est défini, les réponses de quota d'Edge contiennent l'ID du MP. et sera consignée 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 de chaque projet de composant. associés avec Edge Microgateway 3.0.8. 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 - Nouvel "fail open" fonctionnalité a été ajoutée. Cette fonctionnalité permet de poursuivre le traitement de l'API 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 vers le 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 sont réutilisés jusqu'à l'expiration du délai de grâce. Cette fonctionnalité permet à Edge Microgateway pour continuer à traiter les requêtes en cas d'échec de connexion temporaire. Quand ? la connectivité est réactivée et qu'un appel de clé API Verify réussi est effectué, un nouveau jeton JWT est récupérée et remplace l'ancien JWT dans le cache.

  Pour configurer le nouveau mode "fail open" : procédez comme suit:

  1. Définissez les propriétés suivantes dans le bloc oauth d'Edge Microgateway configuration Terraform:

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

     Exemple :

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

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

• 141168968 : une mise à jour a été effectuée afin d'inclure le 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 du proxy edgemicro-auth a été effectuée pour exiger l'utilisation de Edge Microgateway clé et le secret à vérifier sur chaque requête de vérification de clé API. Edge Microgateway mis à jour pour 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 uniquement avec une clé API.
• 140090250 - Une mise à jour a été effectuée afin d'ajouter la journalisation de diagnostic pour le traitement des quotas. Grâce à cette il est désormais possible de corréler la sortie du journal quoto avec le reste d'Edge Microgateway. journaux.

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 de chaque projet de composant. associés avec Edge Microgateway 3.0.7. 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 : le plug-in OAuth a été mis à jour afin de renvoyer un code d'état 5xx où approprié. Auparavant, le plug-in ne renvoyait que des codes d'état 4xx dans tous les non-200. Maintenant, pour toute réponse à un message qui n'est pas un état 200, le mot clé exact Un code 4xx ou 5xx sera renvoyé, en fonction de l'erreur.

  Cette fonctionnalité est désactivée par défaut. Pour activer cette fonctionnalité, ajoutez 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 edgemicro-auth qui est déployé dans votre organisation. Si cette propriété n'est pas définie, le point de terminaison du quota utilise par défaut 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 à la dernier proxy edgemicro-auth. Pour plus d'informations, voir Mettre à niveau Edgemicro-auth proxy.

• 140470888 – Un en-tête "Authorization" a été ajouté aux appels de quota pour fournir une authentification. De plus, le proxy edgemicro-auth a été modifié pour supprimer "organisation" à partir de l'identifiant de quota. Comme le point de terminaison du quota se trouve dans le l'identifiant de quota n'est plus nécessaire.
• 140823165 - Le nom de propriété suivant:

  edgemicro:
      keepAliveTimeout

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

  edgemicro:
      keep_alive_timeout

• 139526406 - Correction d'un bug qui provoquait un nombre incorrect de quotas si une application de développeur avait plusieurs produits. Le quota est désormais correctement appliqué pour chaque produit dans une application. qui comporte plusieurs produits. Combinaison de "appName + productName" est utilisé 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é active 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éfinir cette configuration si vous souhaitez gérer les quotas via le proxy edgemicro-auth, déployées dans votre organisation. Si cette propriété n'est pas définie, le point de terminaison de 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 de Proxy edgemicro-auth vers votre organisation. Pour en savoir plus, consultez <ph type="x-smartling-placeholder"></ph> 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 et non les traces de la pile n'apparaissent pas dans les fichiers journaux. Exemple :

  stack_trace: false

  Si stack_trace est défini sur true, la trace de la pile être imprimés dans des journaux. Si elle est définie sur false, la pile trace dans les journaux.

3.0.5

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

</ph>
• 139005279 - Un problème a été résolu et la commande edgemicro status ne renvoyait pas le bon nombre de processus de nœud de calcul.
• 138437710 – Un problème a été résolu dans la classe ExitCounter, qui empêchait la mise à jour d'écriture du journal.

</ph>
• 139064652 : possibilité d'ajouter des 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, 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. Console Les instructions de journalisation incluent désormais les attributs suivants:
• Horodatage
• Nom du composant
• ID du processus
• Message de journal de la console

</ph>
• 138413755 - Amélioration des messages de journal liés aux clés JWT et aux secrets pour ces CLI "cert", "verify", "upgradekvm", "jeton", "genkeys", " dotée de clés révoquant les clés", "rotationkey" et "configure".

</ph>
• 138413577 - Ajout et amélioration de la gestion des erreurs pour les délais avant expiration du service 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 pour "connexion refusée" les erreurs.

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 de lancement de processus indésirables. Les processus supplémentaires entraînait l'actualisation des plug-ins et utilisait trop de mémoire. Edge Microgateway maintient désormais le nombre de processus dans la limite prévue.
• 137768774 - Améliorations des messages de journal: <ph type="x-smartling-placeholder">
  </ph>
  • Nettoyage des journaux de transactions (requêtes).
  • Ajout de messages de journal supplémentaires si nécessaire.
  • Déplacement des messages de journal de transaction (requête) de la sortie de la console vers fichier journal.
  • Mise à jour des journaux de la console pour utiliser une fonction de journalisation centralisée.
• 138321133, 138320563 – Modification interne de base du tampon de quota pour permettre à l'avenir d'augmenter les quotas.

3.0.3

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

• Améliorations de Logging: les journaux d'exécution existants utilisent un nouveau <ph type="x-smartling-placeholder"></ph> eventLog() qui capture et consigne les données d'exécution de manière cohérente . Les informations du journal incluent: <ph type="x-smartling-placeholder">
  </ph>
  • 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 à l'origine de la demande provenant de l'en-tête de la requête.
  • ID de processus : si vous exécutez un cluster de processus Node.js, il s'agit de l'ID du au cours duquel la journalisation s'est produite.
  • Nom de l'organisation Apigee.
  • Nom de l'environnement au sein de l'organisation.
  • Nom du proxy de l'API.
  • Adresse IP du client.
  • ClientId.
  • ID de corrélation (non défini pour le moment).
  • 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 (dans le cas 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 nécessaire.
  • Système d'exploitation de fin de ligne.

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

  L'exemple suivant présente 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é corrigé. (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 aux normes de qualité demandées par les utilisateurs. Nous avons traité les erreurs et les avertissements liés à la qualité du code issu de JSHint. En conséquence, certaines erreurs de code ont été identifiées et corrigées. Toutes les plateformes Apigee Edge Microgateway modules ont été passés par 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 changé ont été testés à l'aide d'outils internes qui vérifient Edge Microgateway pour les cas d'utilisation client.

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 avec Edge Microgateway
  (Versions 8 et 12 compatibles avec Node.js ; les versions 7, 9 et 11 sont expérimentales)
• 134751883 – Edge Microgateway plante lors de l'actualisation en cas de charge élevée
• 134518428 : le point de terminaison des produits pour Edge Microgateway renvoie 5XX si la règle de filtrage est incorrecte
• 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 memored fourni avec l'installation d'Edge Microgateway
• 135367906 - Audit de sécurité

Version 2.5.x

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

(Corrigé 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. Fixe dans le bord microgateway-plugins. (b/134672029).

(Ajoutée 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 et authentifier les API de gestion. Consultez également la section Gérer les certificats.

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

Vous pouvez utiliser l'indicateur mgdebug avec edgemicroctl. Voir aussi Tâches d'intégration à Kubernetes

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

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

Une nouvelle API Edgemicro-auth/token a été ajoutée pour vous permettre de transmettre le client/code secret en tant que code l'en-tête "Basic Authorization" et le paramètre "grant_type" du formulaire. Consultez Obtenir directement des jetons de support.

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

Un problème a été résolu lors de la configuration d'Edge Microgateway afin d'utiliser un jeton d'accès OAuth2 sur Edge pour Le cloud privé ne fonctionnait pas correctement (le jeton n'était pas respecté).

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

(Ajouté 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 prend désormais en charge le protocole TLS pour envoyées au serveur Edge Microgateway (demandes en liaison nord) et pour les requêtes sortantes d'Edge Microgateway vers d'une application cible (requêtes "Direction sud").

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

• Exemple de configuration TLS limitée vers le nord
• Exemple de configuration TLS "direction sud"

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

Docker: prise en charge de la transmission des requêtes par proxy

(Ajouté 2.5.27) Si vous exécutez Edge Microgateway dans un conteneur Docker, vous pouvez utiliser ces options pour contrôler le proxy lorsque la micropasserelle s'exécute derrière un pare-feu:

• HTTP_PROXY
• HTTPS_PROXY
• NO_PROXY

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

Docker: mise à jour des instructions du plug-in

(Ajouté 2.5.27) Si vous exécutez Edge Microgateway dans un conteneur Docker, vous disposez désormais de deux options pour déployer des plug-ins. Une nouvelle option consiste à utiliser un point d'installation Docker. L'autre option existait auparavant, reste essentiellement le même ; Cependant, le 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 (nouvelle version)
• Option B: Créer les plug-ins dans le conteneur (mise à jour)

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

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

Séparation des API dans Edge Analytics

(Ajout de la version 2.5.26) Les nouveaux indicateurs de plug-in d'analyse vous permettent de séparer un chemin d'accès spécifique à l'API 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 de véritables appels d'API. Pour en savoir plus, consultez Exclure des chemins d'Analytics :

Configurer un proxy local

(Ajoutée vers la version 2.5.25) Avec un proxy local, vous n'avez pas besoin créer manuellement un proxy compatible avec la micropasserelle sur Apigee Edge. La micropasserelle utilise à la place le chemin d'accès de base du proxy local. Pour en savoir plus, consultez la section Utiliser le mode proxy local.

Utiliser le mode autonome

(Ajoutée vers la version 2.5.25) Vous pouvez exécuter Edge Microgateway sans connexion 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ée 2.5.19) Une nouvelle commande CLI révoque la clé et les identifiants secrets d'une Configuration d'Edge Microgateway.

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

Compatibilité avec Docker

(Ajoutée 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

Assistance Kubernetes

(Ajouté 2.5.19) Vous pouvez déployer Edge Microgateway en tant que service ou en tant que passerelle side-car devant déployés dans un cluster Kubernetes. Voir: Présentation de l'intégration d'Edge Microgateway dans Kubernetes

Compatibilité avec l'option de déploiement de nœuds TCP

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

Par défaut, les connexions TCP utilisent le protocole Nagle algorithme 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 se déclenchent immédiatement socket.write() est appelé). Reportez-vous également à la documentation Node.js dans la documentation.

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 permanente

(Ajoutée 2.5.12) De nouveaux paramètres ont été ajoutés à la commande edgemicro forever. Ces paramètres vous permettent spécifier l'emplacement du fichier forever.json et vous permettre de démarrer ou d'arrêter en arrière-plan. Consultez également Surveillance permanente.

Exemples :

Pour lancer l'application définitivement:

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

Pour arrêter définitivement:

edgemicro forever -a stop

Rotation des clés JWT

Une nouvelle fonctionnalité a été ajoutée 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. Voir <ph type="x-smartling-placeholder"></ph> Effectuer une rotation 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 "edgemicro_". Vous pouvez modifier cette valeur par défaut pour télécharger des proxys dont les noms correspondent à un modèle. Voir <ph type="x-smartling-placeholder"></ph> 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 au produit de fonctionner avec n'importe quelle déployé dans votre organisation. Depuis la version 2.5.4, Edge Microgateway est compatible avec ce produit configuration.

Compatibilité avec une surveillance permanente

Edge Microgateway dispose d'un fichier forever.json que vous pouvez configurer pour contrôler le nombre et les intervalles de redémarrage d'Edge Microgateway. Ce fichier configure un service appelé "always-monitor", qui gère Forever de manière programmatique. Voir <ph type="x-smartling-placeholder"></ph> Surveillance permanente.

Gestion centralisée du fichier de configuration Edge Micro

Si vous exécutez plusieurs instances Edge Microgateway, vous pouvez gérer leur des configurations à partir d'un même emplacement. Vous pouvez le faire en spécifiant un point de terminaison HTTP où Edge Micro peut télécharger son fichier de configuration. Voir <ph type="x-smartling-placeholder"></ph> Spécifier un point de terminaison de fichier de configuration

Prise en charge de l'option de CLI indéfiniment

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

Exemple :

edgemicro forever ~/mydir/forever.json

Ajout de l'option configUrl à la commande d'actualisation.

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

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

(Ajoutée 2.5.7) L'attribut gracePeriod dans la configuration OAuth permet d'éviter les erreurs causées par de légers écarts entre votre horloge système et les données (iat) spécifié dans le jeton d'autorisation JWT. Définissez cet attribut sur le nombre de secondes pour permettre de tels écarts. Voir <ph type="x-smartling-placeholder"></ph> Attributs OAuth

(Ajoutée 2.5.7) L'attribut gracePeriod dans la configuration OAuth permet d'éviter les erreurs causées par de légers écarts entre votre horloge système et les données (iat) spécifié dans le jeton d'autorisation JWT. Définissez cet attribut sur le nombre de secondes pour permettre de tels écarts. Voir <ph type="x-smartling-placeholder"></ph> Attributs OAuth

Bugs corrigés dans la version 2.5.x

• (Problème 236) Correction d'une faute de frappe lors du nettoyage du cache.
• (Problème n° 234) Rechargez les plantages d'Edge Microgateway 2.5.35.
• (Problème 135) Référence d'hôte virtuel "secure" non valide lors de l'utilisation -v. Ce correctif modifie le proxy Edgemicro-auth avant le déploiement sur vérifier que les hôtes virtuels correspondent exactement à ce qui est spécifié dans "-v" . De plus, vous pouvez spécifier n'importe quel nombre et n'importe quel nom pour l'hôte virtuel (qui n'est plus restreint par défaut et sécurisé).
• (Problème 141) La commande edgemicro reload ne prend pas en charge l'option -c du fichier de configuration. Ce problème a été résolu.
• (Problème n° 142) Edge Microgateway signale que les cryptomonnaies sont obsolètes au moment de l'installation. Ce problème a été résolu.
• (Problème n° 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 proxys d'API et à l'URI de ressource dans OAuth. Ce problème a été résolu ou corriger un problème.
• (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 de pidPath sous Windows.
• (Problème 157) Le problème à l'origine du message d'erreur suivant a été résolu: ReferenceError: deployProxyWithPassword non défini.
• (Problème n° 169) Mettre à jour les dépendances Node.js (audit npm)
• Le proxy edgemicro-auth utilise désormais les règles JWT Edge. Le proxy ne dépend plus Node.js pour assurer la compatibilité avec les jetons JWT.

Version 2.4.x

Nouvelles fonctionnalités et améliorations version 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 la modifier, utilisez l'indicateur -x. sur 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 "*" dans le chemin de base d'une edgemicro_*. Par exemple, un chemin d'accès de base pour /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 nouveaux proxys d'API pour soutenir de nouvelles équipes. Notez que /**/ n'est pas compatibles.

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

Par défaut, le fichier de configuration de la micropasserelle se trouve dans le fichier ./config/config.yaml. Sur les commandes init, configure et start, vous pouvez maintenant spécifier un chemin d'accès de configuration personnalisé sur la à l'aide des indicateurs -c ou --configDir. Problème résolu où aucun répertoire de configuration personnalisé pour les installations de cloud privé n'a été reconnu.

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 de périphérie dans le cloud public, deux options s'offrent à vous:

Option 1 :

La première consiste à définir l'option Edgemicro: proxy_tunnel sur "true" dans la micropasserelle. de configuration:

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

Lorsque proxy_tunnel est défini sur true, Edge Microgateway utilise la CONNECT afin de tunneliser les requêtes HTTP via une seule connexion TCP. Il en va de même si pour la configuration du proxy si TLS est activé).

Option 2 :

La deuxième option consiste à spécifier un proxy et à définir proxy_tunnel sur false dans le fichier de configuration de la 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 liste de domaines séparés par une virgule que Edge Microgateway doit sans passer par un 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éfinir un délai d'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 d'expiration du délai, Edge Microgateway renvoie un code 504 code d'état.

6. Respectez les 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 depuis la cible étaient remplacés par Node.js valeurs par défaut.

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

S'il est présent, l'en-tête X-Forwarded-For définit le client_ip indiquée dans Edge Analytics. Cette fonctionnalité vous permet connaître l'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 après cette modification, le plug-in acceptait les deux formes de sécurité. Avec cette modification, vous ne pouvez autoriser l'un de ces modèles de sécurité (tout en maintenant la rétrocompatibilité).

Les plug-ins OAuth ajoutent deux options:

• allowOAuthOnly : si la valeur est true, chaque API doit transmettre un en-tête Authorization avec un jeton d'accès de support.

• allowAPIKeyOnly : si la valeur est true, chaque API doit transmettre 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 de la manière suivante:

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 a stocké les clés dans Edge Secure Store, un coffre-fort chiffré. Le proxy stocke les clés dans le mappage clé-valeur chiffré (KVM) d'Edge.

10. Réécriture de 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. Modifier ces 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 cette discussion 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 afin d'utiliser un jeton OAuth pour l'authentification au lieu de nom d'utilisateur/mot de passe. Pour utiliser un jeton OAuth, spécifiez le paramètre suivant sur la couche 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 empêchait une organisation payante de pouvoir exécuter correctement le proxy Edgemicro-auth. Maintenant, vous pouvez également utiliser Edge Microgateway avec des organisations d'essai. (PR 5)
• Correction d'un problème où le flux n'avait pas fini de traiter les données, alors que les gestionnaires finaux étaient s’exécuter quoi qu’il en soit. Cela a entraîné l'envoi d'une réponse partielle. (PR 71)
• Correction d'un problème qui empêchait de créer un répertoire de configuration personnalisé pour les installations de cloud privé reconnue. (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 où une barre oblique finale était requise pour le chemin de base du proxy pour la clé API la vérification pour qu'elle fonctionne correctement. Désormais, une barre oblique finale n'est plus nécessaire à la fin du chemin de base. (PR 48)

Version 2.3.5

Nouvelles fonctionnalités et améliorations version 2.3.5

Filtrage proxy

Vous pouvez filtrer les proxys compatibles avec la micropasserelle qu'une instance Edge Microgateway traitera. Au démarrage d'Edge Microgateway, il télécharge tous les proxys compatibles avec la micropasserelle du organisation à laquelle il est associé. Utilisez la configuration suivante pour limiter les proxys que microgateway traitera. Par exemple, cette configuration limite les proxys de la micropasserelle traitera trois éléments: 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 de la requête dans Edge analyse. Ajoutez le code suivant à la configuration de la microgateway pour masquer l'URI de la requête et/ou dans le chemin de la requête. Notez que l'URI se compose des parties de la requête (nom d'hôte et chemin d'accès).

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

Version 2.3.3

Nouvelles fonctionnalités et améliorations version 2.3.3

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

Désactiver la vérification automatique des modifications

Vous pouvez désactiver la vérification automatique des modifications en définissant cet attribut dans la micropasserelle configuration:

disabled_config_poll_interval: true

Par défaut, l'interrogation périodique détecte toutes les modifications apportées sur Edge (modifications des produits, proxy compatibles avec les micro-passerelles, etc.), ainsi que les modifications apportées au fichier de configuration local. La valeur par défaut l'intervalle d'interrogation est de 600 secondes (cinq minutes).

Réécriture des 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 ces variables dans le code de votre plug-in: req.targetHostname. 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 sous forme de . 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 jetons JWT téléchargés. Vous pouvez passer aux valeurs 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 d'accès à la configuration personnalisé ajouté à la CLI

Par défaut, le fichier de configuration microgateway se trouve dans ./config/config.yaml. Sur l'initialisation, configurer et démarrer des commandes, 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

• Une fuite de mémoire survenant lors de requêtes/réponses volumineuses a été corrigée.
• L'ordre d'exécution du plug-in a été corrigé. Il se comporte à présent tel qu'indiqué dans l'article dans la documentation Google Cloud.
• Le plug-in d'accumulation de requête du plug-in ne se bloque plus pour les requêtes GET.
• Correction d'un problème dans le plug-in d'accumulation de réponse qui provoquait un manque de corps de réponse les erreurs.

Version 2.3.1

Note d'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

Consultez la rubrique d'installation pour en savoir plus plus de détails.

Nouvelles fonctionnalités et améliorations version 2.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 sur lesquels Edge Microgateway sera chargé au démarrage. Auparavant, la micropasserelle chargeait tous les proxys compatibles avec la micropasserelle (les proxys nommés Edgemicro_*) extrait de l'organisation/de l'environnement Edge que vous avez spécifié dans la fonction Edgemicro configure. Cette nouvelle fonction vous permet de filtrer cette liste de proxies afin que Edge Microgateway ne charge que celles que vous spécifiez. Ajoutez simplement l'élément proxy à la micropasserelle de configuration comme ceci:

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

Par exemple, supposons que vous ayez 50 proxys edgemicro_* dans votre Edge org/env, y compris ceux nommés edgemicro_foo et edgemicro_bar. Vous pouvez indiquez à la micropasserelle de n'utiliser que ces deux proxys, comme ceci:

edge micro:
proxies:
    - edgemicro_foo
    - edgemicro_bar

Au démarrage, la micropasserelle ne pourra appeler que les proxys spécifiés. Toutes les tentatives pour appeler d'autres proxys compatibles avec les micro-passerelles téléchargés depuis l'organisation/l'environnement Edge peut entraîner une erreur.

Définir des en-têtes de requêtes 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 cibles: un où la requête entrante contient des données (comme dans une requête POST) et une où ce n'est pas le cas (comme dans une simple demande GET).

Prenons l'exemple d'une requête entrante contenant des données, et vous voulez définir une requête sur la requête cible. Dans les versions précédentes d'Edge Microgateway, dans ce cas, définissez des en-têtes cibles de manière fiable.

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

Voici un exemple de code de plug-in qui montre 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 fichier 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 charger la configuration sans perdre de message. Avec cette modification, Edge Microgateway démarre toujours en mode cluster, L'option --cluster a été supprimée du edgemicro start. .

Trois nouvelles commandes CLI ont également été ajoutées. Vous devez exécuter ces commandes le répertoire dans lequel la commande de démarrage Edgemicro a été exécutée:

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

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

Edge Microgateway charge régulièrement une nouvelle configuration et effectue une actualisation le cas échéant modifié. Le sondage récupère toutes les modifications apportées sur Edge (modifications des produits, compatibles avec les micro-passerelles proxys, etc.), ainsi que les modifications apportées au fichier de configuration local. L'intervalle d'interrogation par défaut est 600 secondes (cinq minutes) Vous pouvez modifier la valeur par défaut dans le fichier de configuration de la micropasserelle comme suit : ce qui suit:

edgemicro:
    config_change_poll_interval: [seconds]

Ajout d'informations de version dans la CLI

Une option --version a été ajoutée à la CLI. 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 des fichiers journaux à stdout

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

edgemicro:
  logging:
    to_console: true  

Voir <ph type="x-smartling-placeholder"></ph> 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 personnalisé de l'API pour la configuration

Il existe de nouveaux points de terminaison configurables pour le proxy d'autorisation, qui prennent en charge l'utilisation d'un service d'authentification personnalisé. Ces points de terminaison sont les suivants:

• edgeconfig:verify_api_key_url
• edgeconfig:products

Pour plus d'informations, voir 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 de sorte que la commande utilisée pour déployer l'autorisation Edge Microgateway a été vers Edge est compatible avec les systèmes Windows.

Version 2.1.0

Nouvelles fonctionnalités et améliorations version 21.0

Voici les nouvelles fonctionnalités et améliorations:

Spécifier les options SSL/TLS du client

Vous pouvez spécifier les options du client pour les connexions SSL/TSL aux cibles à l'aide d'un nouvel ensemble de options. Voir <ph type="x-smartling-placeholder"></ph> 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

Consultez la rubrique d'installation pour en savoir plus plus de détails.

Nouvelles fonctionnalités et améliorations version 2.0.11

Voici les nouvelles fonctionnalités et améliorations:

Spécifier un port au démarrage

La commande "start" vous permet de spécifier un numéro de port qui remplace le port spécifié dans fichier de configuration. Vous pouvez également spécifier un numéro de port à l'aide de la variable d'environnement PORT. Voir start pour plus de détails.

Conserver éventuellement les en-têtes d'authentification

Un nouveau paramètre de configuration, keepAuthHeader, vous permet de conserver En-tête d'autorisation envoyé dans la requête. S'il est défini sur "true", l'en-tête Auth est transmis au cible. Voir <ph type="x-smartling-placeholder"></ph> attributs OAuth.

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

Si vous souhaitez utiliser votre propre service personnalisé pour gérer l'authentification, modifiez authUri dans le fichier de configuration Edge Microgateway pour pointer vers votre service. Pour détails, voir 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 version 2.0.4

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

Compatibilité avec les chemins de ressources dans les produits

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

Compatibilité avec l'installation globale npm

Vous pouvez maintenant installer Edge Microgateway à l'aide de l'option npm -g (global). Pour en savoir plus à ce sujet, reportez-vous à la commande npm documentation.

Version 2.0.0

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

Nouvelles fonctionnalités et améliorations version 2.0.0

Vous trouverez ci-dessous les nouvelles fonctionnalités et améliorations de 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 "agent") lance Edge Microgateway, l'autre 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 à des espaces de noms à l'aide de l'organisation et de l'environnement, de sorte que plusieurs Les instances Microgateway peuvent s'exécuter sur le même hôte. Les fichiers de configuration se trouvent dans ~/.edgemicro après avoir exécuté la commande de configuration Edge Microgateway.

Nouvelles variables d'environnement

Il existe maintenant quatre variables d'environnement: EDGEMICRO_ORG, EDGEMICRO_ENV, EDGEMICRO_KEY, EDGEMICRO_SECRET. Si vous définissez ces variables sur votre système, il n'est pas nécessaire de spécifier leur 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 en cas de redémarrage sans à Apigee Edge.

Mode du cluster

Des options permettent désormais de démarrer Edge Microgateway en mode cluster. Le mode Cluster vous permet d'effectuer des systèmes multicœurs. La micropasserelle 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-ins gère désormais correctement le code asynchrone contenant du code avec un nouveau .

Version 1.1.2

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

Nouvelles fonctionnalités et améliorations version 1.1.2

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

Amélioration des performances

Edge Microgateway utilise désormais correctement l'agent HTTP Node.js pour améliorer le regroupement des connexions. Ce améliore les performances et la stabilité globale en cas de charges importantes.

Compatibilité avec les débogueurs à distance

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 Edge Microgateway journaux.

Bugs corrigés dans la version 1.1.2

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