Edge Microgateway-Versionshinweise

Sie sehen die Dokumentation zu Apigee Edge.
Rufen Sie die Apigee X-Dokumentation auf. weitere Informationen

Version 3.3.x

Fehlerkorrekturen und Verbesserungen in Version 3.3.x

3.3.3

Am 25. April 2024 wurden die folgenden Fehlerbehebungen und Verbesserungen für Edge Microgateway veröffentlicht.

Komponentenversionen:

In der folgenden Tabelle sind die Versionsnummern für die einzelnen Komponentenprojekte aufgeführt, die mit Edge Microgateway 3.3.3 verknüpft sind. Da jede Komponente ein separates Projekt ist, stimmen die Release-Nummern möglicherweise nicht mit der Hauptproduktversion überein:

Fehlerkorrekturen und Verbesserungen:

Sicherheitsprobleme behoben

• 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

Am 18. August 2023 wurden die folgenden Fehlerbehebungen und Verbesserungen für Edge Microgateway veröffentlicht.

Komponentenversionen:

In der folgenden Tabelle sind die Versionsnummern für die einzelnen Komponentenprojekte aufgeführt, die mit Edge Microgateway 3.3.2 verknüpft sind. Da jede Komponente ein separates Projekt ist, stimmen die Release-Nummern möglicherweise nicht mit der Hauptproduktversion überein:

Fehlerkorrekturen und Verbesserungen:

Sicherheitsprobleme behoben

Keine.

3.3.1

Am 7. Juni 2022 wurden die folgenden Fehlerbehebungen und Verbesserungen für Edge Microgateway veröffentlicht.

Komponentenversionen:

In der folgenden Tabelle sind die Versionsnummern für die einzelnen Komponentenprojekte aufgeführt, die mit Edge Microgateway 3.3.1 verknüpft sind. Da jede Komponente ein separates Projekt ist, stimmen die Release-Nummern möglicherweise nicht mit der Hauptproduktversion überein:

Fehlerkorrekturen und Verbesserungen:

Sicherheitsprobleme behoben

3.3.0

Am 4. Februar 2022 wurden die folgenden Fehlerbehebungen und Verbesserungen für Edge Microgateway veröffentlicht.

Komponentenversionen:

In der folgenden Tabelle sind die Versionsnummern für die einzelnen Komponentenprojekte aufgeführt, die mit Edge Microgateway 3.3.0 verknüpft sind. Da jede Komponente ein separates Projekt ist, stimmen die Release-Nummern möglicherweise nicht mit der Hauptproduktversion überein:

Fehlerkorrekturen und Verbesserungen:

npm install apigeetool@0.15.1

Version 3.2.x

Fehlerkorrekturen und Verbesserungen in Version 3.2.x

3.2.3

Am 17. September 2021 wurden die folgenden Fehlerbehebungen und Verbesserungen für Edge Microgateway veröffentlicht.

Komponentenversionen:

In der folgenden Tabelle sind die Versionsnummern für die einzelnen Komponentenprojekte aufgeführt, die mit Edge Microgateway 3.2.3 verknüpft sind. Da jede Komponente ein separates Projekt ist, stimmen die Release-Nummern möglicherweise nicht mit der Hauptproduktversion überein:

Fehlerkorrekturen und Verbesserungen:

Sicherheitsprobleme behoben

3.2.2

Am Donnerstag, dem 15. Juli 2021, wurden die folgenden Fehlerbehebungen und Verbesserungen für Edge Microgateway veröffentlicht.

Komponentenversionen:

In der folgenden Tabelle sind die Versionsnummern für die einzelnen Komponentenprojekte aufgeführt, die mit Edge Microgateway 3.2.2 verknüpft sind. Da jede Komponente ein separates Projekt ist, stimmen die Release-Nummern möglicherweise nicht mit der Hauptproduktversion überein:

Fehlerkorrekturen und Verbesserungen:

Sicherheitsprobleme behoben

3.2.1

Am Freitag, dem 5. März 2021, wurden die folgenden Fehlerbehebungen und Verbesserungen für Edge Microgateway veröffentlicht.

Komponentenversionen:

In der folgenden Tabelle sind die Versionsnummern für die einzelnen Komponentenprojekte aufgeführt, die mit Edge Microgateway 3.2.1 verknüpft sind. Da jede Komponente ein separates Projekt ist, stimmen die Release-Nummern möglicherweise nicht mit der Hauptproduktversion überein:

Fehlerkorrekturen und Verbesserungen:

edgemicro:
 enable_GET_req_body: true

3.2.0

Am Donnerstag, dem 21. Januar 2021 wurden die folgenden Fehlerkorrekturen und Verbesserungen für Edge Microgateway veröffentlicht.

Komponentenversionen:

In der folgenden Tabelle sind die Versionsnummern für die einzelnen Komponentenprojekte aufgeführt, die mit Edge Microgateway 3.2.0 verknüpft sind. Da jede Komponente ein separates Projekt ist, stimmen die Release-Nummern möglicherweise nicht mit der Hauptproduktversion überein:

Fehlerkorrekturen und Verbesserungen:

Version 3.1.x

Fehlerkorrekturen und Verbesserungen in Version 3.1.x

3.1.8

Am Montag, dem 16. November 2020, wurden die folgenden Fehlerbehebungen und Verbesserungen für Edge Microgateway veröffentlicht.

Komponentenversionen:

In der folgenden Tabelle sind die Versionsnummern für die einzelnen Komponentenprojekte aufgeführt, die mit Edge Microgateway 3.1.8 verknüpft sind. Da jede Komponente ein separates Projekt ist, stimmen die Release-Nummern möglicherweise nicht mit der Hauptproduktversion überein:

Fehlerkorrekturen und Verbesserungen:

3.1.7

Am Donnerstag, dem 24. September 2020, wurden die folgenden Fehlerbehebungen und Verbesserungen für Edge Microgateway veröffentlicht.

Komponentenversionen:

In der folgenden Tabelle sind die Versionsnummern für die einzelnen Komponentenprojekte aufgeführt, die mit Edge Microgateway 3.1.7 verknüpft sind. Da jede Komponente ein separates Projekt ist, stimmen die Release-Nummern möglicherweise nicht mit der Hauptproduktversion überein:

Fehlerkorrekturen und Verbesserungen:

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

3.1.6

Am Donnerstag, dem 20. August 2020, wurden die folgenden Fehlerbehebungen und Verbesserungen für Edge Microgateway veröffentlicht.

Komponentenversionen:

In der folgenden Tabelle sind die Versionsnummern für die einzelnen Komponentenprojekte aufgeführt, die mit Edge Microgateway 3.1.6 verknüpft sind. Da jede Komponente ein separates Projekt ist, stimmen die Release-Nummern möglicherweise nicht mit der Hauptproduktversion überein:

Fehlerkorrekturen und Verbesserungen:

3.1.5

Am Freitag, dem 26. Juni 2020, wurden die folgenden Fehlerbehebungen und Verbesserungen für Edge Microgateway veröffentlicht.

Komponentenversionen:

In der folgenden Tabelle sind die Versionsnummern für die einzelnen Komponentenprojekte aufgeführt, die mit Edge Microgateway 3.1.5 verknüpft sind. Da jede Komponente ein separates Projekt ist, stimmen die Release-Nummern möglicherweise nicht mit der Hauptproduktversion überein:

Fehlerkorrekturen und Verbesserungen:

3.1.4

Am Freitag, dem 23. April 2020, wurde die folgende Fehlerbehebung für Edge Microgateway veröffentlicht.

Fehlerbehebung:

Ein Abhängigkeitsproblem in Version 3.1.3 wurde behoben. Version 3.1.3 wurde im npm-Repository als eingestellt gekennzeichnet. Andernfalls gelten alle in den Release-Hinweisen von Version 3.1.3 beschriebenen Fehlerkorrekturen und Verbesserungen für diese Version.

3.1.3

Am Mittwoch, dem 15. April 2020, wurden die folgenden Fehlerbehebungen und Verbesserungen für Edge Microgateway veröffentlicht.

Komponentenversionen:

In der folgenden Tabelle sind die Versionsnummern für die einzelnen Komponentenprojekte aufgeführt, die mit Edge Microgateway 3.1.3 verknüpft sind. Da jede Komponente ein separates Projekt ist, stimmen die Release-Nummern möglicherweise nicht mit der Hauptproduktversion überein:

Fehlerkorrekturen und Verbesserungen:

• 153509313 – Ein Problem wurde behoben, bei dem das Node.js-Debug-Modul zu Speicherlecks führte. Das Problem tritt in den Versionen 3.1.0, 3.1.1 und 3.1.2 auf.
• 153509313: Ein Problem wurde behoben, bei dem dieselbe Nachrichten-ID für zwei verschiedene Transaktionen in der Logging-Ausgabe ausgegeben wurde.
• 151673570 – Ein Problem wurde behoben, bei dem Edge Microgateway nicht für die Verwendung neuer Apigee KVM APIs aktualisiert wurde. Edge Microgateway verwendet jetzt die neuen Befehle zum Hinzufügen und Aktualisieren der KVM-Werte.
• 152822846 – In früheren Releases wurde Edge Microgateway aktualisiert, sodass die Verarbeitung der Ressourcenpfadzuordnung mit der von Apigee Edge übereinstimmt. In diesem Release wurde ein Problem behoben, bei dem das Muster /literal_string/* nicht korrekt verarbeitet wurde. Beispiel: /*/2/*. Siehe auch Verhalten eines Ressourcenpfads von '/', '/*' und '/**' konfigurieren.
• 152005003: Es wurden Änderungen vorgenommen, um organisations- und umgebungsbezogene Kennungen für Kontingente zu ermöglichen.
• 152005003: Es wurden Änderungen vorgenommen, um organisations- und umgebungsbezogene Kennungen für Kontingente zu ermöglichen. Die Kombination aus „org + env + appName + productName“ wird als Kontingent-ID verwendet.

3.1.2

Am Montag, dem 16. März 2020, wurden die folgenden Fehlerbehebungen und Verbesserungen für Edge Microgateway veröffentlicht.

Komponentenversionen:

In der folgenden Tabelle sind die Versionsnummern für die einzelnen Komponentenprojekte aufgeführt, die mit Edge Microgateway 3.1.3 verknüpft sind. Da jede Komponente ein separates Projekt ist, stimmen die Release-Nummern möglicherweise nicht mit der Hauptproduktversion überein:

Fehlerkorrekturen und Verbesserungen:

• 151285018: Es wurde eine Featureerweiterung vorgenommen, um HTTP-Proxy-Unterstützung für Traffic zwischen Edge Microgateway und Back-End-Zielen hinzuzufügen. Darüber hinaus wurden Probleme bei der vorhandenen HTTP-Proxy-Unterstützung zwischen Edge Microgateway und Apigee Edge behoben. Weitere Informationen finden Sie unter:
  • HTTP-Proxy für die Kommunikation mit Apigee Edge verwenden
  • HTTP-Proxy für die Zielkommunikation verwenden
• 149101890: Der Logbenachrichtigungscode für Fälle, in denen der Zielserver oder Load-Balancer seine Verbindung schließt, wurde von ERROR in INFO geändert.
• 150746985: Ein Problem wurde behoben, bei dem der Befehl edgemicro verify nicht ordnungsgemäß funktionierte, wenn redisBasedConfigCache: true oder quotaUri: https://%s-%s.apigee.net/edgemicro-auth in der Konfigurationsdatei vorhanden war.
• 151284716: Eine Verbesserung wurde vorgenommen, um Serververbindungen schneller zu schließen, wenn Worker während eines Neuladevorgangs neu gestartet werden.
• 151588764: Aktualisieren Sie die Node.js-Version im Docker-Image, das zum Ausführen von Edge Microgateway in einem Docker-Container verwendet wird, auf 12, da Node.js v8 verworfen wurde.
• 151306049: Die Dokumentation wurde aktualisiert, um die Apigee Edge-Verwaltungs-APIs aufzulisten, die von Edge Microgateway-Befehlszeilenbefehlen verwendet werden. Weitere Informationen finden Sie unter Welche Verwaltungs-APIs verwendet Edge Microgateway?.

3.1.1

Am Donnerstag, dem 20. Februar wurden die folgenden Fehlerbehebungen und Verbesserungen für Edge Microgateway veröffentlicht.

Komponentenversionen:

In der folgenden Tabelle sind die Versionsnummern für die einzelnen Komponentenprojekte aufgeführt, die mit Edge Microgateway 3.1.1 verknüpft sind. Da jede Komponente ein separates Projekt ist, stimmen die Release-Nummern möglicherweise nicht mit der Hauptproduktversion überein:

Fehlerkorrekturen und Verbesserungen:

• 146069701: Ein Problem wurde behoben, bei dem das Modul microgateway-core die Umgebungsvariablen HTTP_PROXY und HTTPS_PROXY nicht berücksichtigte. Durch diese Änderung werden Proxyeinstellungen in der YAML-Konfigurationsdatei, sofern angegeben, jetzt ignoriert. Nur die Umgebungsvariablen werden zur Angabe des Proxys verwendet.

  Wenn Sie in der Konfigurationsdatei eine Proxykonfiguration angeben möchten, müssen Sie auch eine HTTP_PROXY-Variable angeben, in der dieselbe Proxy-URL wie in der Konfigurationsdatei angegeben ist. Angenommen, Sie geben die folgende Konfiguration an:

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

  Außerdem müssen Sie diese Umgebungsvariable angeben:

  HTTP_PROXY=http://10.128.0.20:3128

• 146320620: Der neue Konfigurationsparameter edgemicro.headers_timeout wurde hinzugefügt. Dieses Attribut begrenzt die Zeit (in Millisekunden), die der HTTP-Parser auf den Empfang der vollständigen HTTP-Header wartet. Beispiel:

  edgemicro:
  keep_alive_timeout: 6000
  headers_timeout: 12000

  Intern legt der Parameter das Node.js-Attribut Server.headersTimeout für Anfragen fest. (Standardeinstellung: 5 Sekunden mehr als die mit edgemicro.keep_alive_timeout festgelegte Zeit. Diese Standardeinstellung verhindert, dass Load-Balancer oder Proxys die Verbindung fälschlicherweise trennen.)

• 149278885: Es wurde eine neue Funktion hinzugefügt, mit der Sie das Ziel-API-Zeitlimit auf API-Proxy-Ebene festlegen können, anstatt eine globale Zeitüberschreitungseinstellung zu verwenden.

  Wenn Sie im API-Proxy das Attribut „TargetEndpoint“ io.timeout.millis festlegen, kann Edge Microgateway dieses Attribut abrufen und zielendpunktspezifische Zeitlimits anwenden. Wenn dieser Parameter nicht angewendet wird, verwendet Edge Microgateway das mit edgemicro.request_timeout angegebene globale Zeitlimit.

3.1.0

Am Dienstag, dem 21. Januar wurden die folgenden Fehlerbehebungen und Verbesserungen für Edge Microgateway veröffentlicht.

Komponentenversionen:

In der folgenden Tabelle sind die Versionsnummern für die einzelnen Komponentenprojekte aufgeführt, die mit Edge Microgateway 3.1.0 verknüpft sind. Da jede Komponente ein separates Projekt ist, stimmen die Release-Nummern möglicherweise nicht mit der Hauptproduktversion überein:

Fehlerkorrekturen und Verbesserungen:

• 144187500 – Ein neues Ereignis auf WARN-Ebene wird protokolliert, wenn das Flag quotas.failOpen ausgelöst wird. Dieses Flag wird ausgelöst, wenn ein Fehler bei der Kontingentverarbeitung auftritt oder wenn die Anfrage zum Anwenden von Kontingenten an Edge keine Remote-Kontingentzähler aktualisieren kann. In diesem Fall wird das Kontingent nur bis zur nächsten erfolgreichen Remote-Kontingentsynchronisierung basierend auf lokalen Zählungen verarbeitet. Bisher wurde dieses Ereignis nur protokolliert, wenn die Logebene auf DEBUG festgelegt wurde.

  Beispiel:

  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: Ein Problem wurde behoben, bei dem laufende oder neue Transaktionen betroffen waren, wenn Edge Microgateway eine Änderung an einem API-Proxy erkannte. Wenn jetzt eine Änderung an einem Proxy vorgenommen wird, aktualisiert Edge Microgateway den Cache und die Worker-Knoten werden neu gestartet. Von dieser Änderung sind laufende Transaktionen und neue API-Aufrufe, die an das Mikrogateway gesendet werden, nicht betroffen.
• 146378327: Die Logebene von sourceRequest, targetRequest und targetResponse wurde zur Ebene INFO geändert.
• 146019878 – Eine Diskrepanz zwischen der Latenz, die für „API-Proxy-Leistung“ in Edge-Analysen und Edge Microgateway-sourceResponse/targetResponse-Logereignissen berechnet wurde, wurde behoben. Jetzt ist die Latenz in Edge Analytics- und Microgateway-Logereignissen ausgerichtet.
• Logische Änderungen bezüglich des Musterabgleichs:
  • 147027862 – Das OAuth-Plug-in wurde aktualisiert, um die folgenden in API-Produkten angegebenen Abgleichsmustern für Ressourcenpfade zu unterstützen:
    • /{literal}**
    • /{literal}*
    • Beliebige Kombination aus den beiden oben genannten Mustern

    Mit dieser Änderung folgt das Edge Microgateway-Plug-in jetzt demselben Musterabgleich wie Apigee Edge, wie unter Verhalten eines Ressourcenpfads von „/“, „/*“ und „/**“ konfigurieren“ erläutert wird.

  • 145644205 – Logik für den Musterabgleich des apiKeys-Plug-ins so aktualisieren, dass es dem OAuth-Plug-in entspricht.
• 143488312: Ein Problem wurde behoben, bei dem voran- oder nachgestellte Leerzeichen im Client-ID-Parameter dazu führten, dass die Erstellung der JWT-Produktliste für OAuth-Token- und API-Schlüsselanfragen leer war.
• 145640807 und 147579179: Eine neue Funktion wurde hinzugefügt, mit der eine spezielle Edge Microgateway-Instanz namens „der Synchronisierer“ Konfigurationsdaten von Apigee Edge abrufen und in eine lokale Redis-Datenbank schreiben kann. Andere Mikrogateway-Instanzen können dann so konfiguriert werden, dass sie ihre Konfigurationsdaten aus der Datenbank lesen. Dieses Feature erhöht die Ausfallsicherheit von Edge Microgateway. Damit können Mikrogateway-Instanzen gestartet und ausgeführt werden, ohne mit Apigee Edge kommunizieren zu müssen. Weitere Informationen finden Sie unter Synchronisierung verwenden.

  Die Synchronisierungsfunktion wird derzeit für Redis 5.0.x unterstützt.

Version 3.0.x

Fehlerkorrekturen und Verbesserungen in Version 3.0.x

3.0.10

Am Freitag, dem 8. November, wurden die folgenden Fehlerbehebungen und Verbesserungen für Edge Microgateway veröffentlicht.

Komponentenversionen:

In der folgenden Tabelle sind die Versionsnummern für die einzelnen Komponentenprojekte aufgeführt, die mit Edge Microgateway 3.0.10 verknüpft sind. Da jede Komponente ein separates Projekt ist, stimmen die Release-Nummern möglicherweise nicht mit der Hauptproduktversion überein:

Fehlerkorrekturen und Verbesserungen:

• 142677575: Es wurde eine Featureaktualisierung vorgenommen, damit der Musterabgleich für Ressourcenpfade in API-Produkten für Edge Microgateway jetzt mit dem von Apigee Edge verwendeten Ressourcenpfadmusterabgleich übereinstimmt, wie unter Verhalten eines Ressourcenpfads von '/', '/*' und '/**' konfigurieren beschrieben.

  Hinweis: Wenn Sie ein zusammengesetztes Ressourcenmuster wie /*/2/** verwenden, muss der edgemicro_auth-Proxy einem eigenständigen API-Produkt hinzugefügt werden. Anschließend müssen Sie dieses Produkt in die Entwickler-App des Proxys einfügen, wie im folgenden Screenshot dargestellt:

  

  Hinweis: Das Konfigurationsattribut features.isSingleForwardSlashBlockingEnabled, wie unter Verhalten eines Ressourcenpfads von „/“, „/*“ und „/**“ konfigurieren beschrieben, wird für Edge Microgateway nicht unterstützt.

• 143740696: Die Konfigurationsstruktur von quotas hat sich geändert (siehe auch die Versionshinweise zu Version 3.0.9). Mit dem Attribut quotas wird das Kontingent-Plug-in konfiguriert. Durch diese Änderung der Struktur wurde die Klarheit der Konfigurationselemente verbessert. Verwenden Sie die folgende YAML-Konfiguration, um das Kontingent-Plug-in zu konfigurieren. Das Konfigurationsattribut heißt quotas. Weitere Informationen zu den einzelnen quotas-Konfigurationsattributen finden Sie unter Konfigurationsoptionen für Kontingente.

  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: Ein neues Feature wurde hinzugefügt, mit dem Sie Redis als Speicher zur Kontingentsicherung verwenden können. Wenn useRedis auf „true“ gesetzt ist, wird das Modul volos-quota-redis verwendet. Wenn dieser Wert auf „true“ gesetzt ist, wird das Kontingent auf die Edge Microgateway-Instanzen beschränkt, die eine Verbindung zu Redis herstellen. Bei „false“ wird das Modul volos-quota-apigee als Sicherungsspeicher verwendet und der Kontingentzähler ist global. Weitere Informationen finden Sie unter Konfigurationsoptionen für Kontingente. Beispiel:

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

• 140574210: Die Standardablaufzeit für Tokens, die vom edgemicro-auth-Proxy generiert wurden, wurde von 108.000 Millisekunden (1,8 Minuten) zu 1800 Sekunden (30 Minuten) geändert.
• 143551282: Zur Unterstützung von SAML-fähigen Organisationen wurde der Befehl edgemicro genkeys aktualisiert und enthält nun einen ‑‑token-Parameter. Mit diesem Parameter können Sie anstelle von Nutzername/Passwort ein OAuth-Token zur Authentifizierung verwenden. Weitere Informationen finden Sie unter Schlüssel generieren.

3.0.9

Am Freitag, dem 11. Oktober, wurden die folgenden Fehlerbehebungen und Verbesserungen für Edge Microgateway veröffentlicht.

Komponentenversionen:

In der folgenden Tabelle sind die Versionsnummern für die einzelnen Komponentenprojekte aufgeführt, die mit Edge Microgateway 3.0.9 verknüpft sind. Da jede Komponente ein separates Projekt ist, stimmen die Release-Nummern möglicherweise nicht mit der Hauptproduktversion überein:

Fehlerkorrekturen und Verbesserungen:

• 141989374: Für das Kontingent-Plug-in wurde die neue Funktion "Fail-Open" hinzugefügt. Wenn diese Funktion aktiviert ist und ein Fehler bei der Kontingentverarbeitung auftritt oder wenn die Anfrage zum Anwenden von Kontingenten Remote-Kontingentzähler nicht aktualisieren kann, wird das Kontingent nur auf der Grundlage lokaler Zählungen verarbeitet, bis die nächste erfolgreiche Remote-Kontingentsynchronisierung erfolgt. In beiden Fällen wird im Anfrageobjekt das Flag quota-failed-open festgelegt.

  Legen Sie die folgende Konfiguration fest, um das Kontingent über die Fail-Open-Funktion zu aktivieren:

  quotas :
   failOpen : true

  Hinweis: Darüber hinaus wurde der Name des fail-open-Anfrageobjekt-Flags des OAuth-Plug-ins in oauth-failed-open geändert.

• 142093764: Am edgemicro-auth-Proxy wurde eine Konfigurationsänderung vorgenommen, um Kontingentüberschreitungen zu verhindern. Als Änderung wird der Kontingenttyp auf calendar festgelegt. Wenn du diese Verbesserung nutzen möchtest, musst du edgemicro-auth auf Version 3.0.7 oder höher aktualisieren.
• 142520568: Eine neue Funktion wurde hinzugefügt, um das Logging der MP-ID (Message Processor) in Kontingentantworten zu ermöglichen. Wenn Sie diese Funktion verwenden möchten, müssen Sie den edgemicro-auth-Proxy auf Version 3.0.7 oder höher aktualisieren und die folgende Konfiguration festlegen:

  quotas:
    useDebugMpId: true

  Wenn useDebugMpId festgelegt ist, enthalten Kontingentantworten von Edge die MP-ID und werden von Edge Microgateway protokolliert. Beispiel:

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

3.0.8

Am Donnerstag, dem 26. September wurden die folgenden Fehlerbehebungen und Verbesserungen für Edge Microgateway veröffentlicht.

Komponentenversionen:

In der folgenden Tabelle sind die Versionsnummern für die einzelnen Komponentenprojekte aufgeführt, die mit Edge Microgateway 3.0.8 verknüpft sind. Da jede Komponente ein separates Projekt ist, stimmen die Release-Nummern möglicherweise nicht mit der Hauptproduktversion überein:

Fehlerkorrekturen und Verbesserungen:

• 140025210: Die neue Funktion "Fail-Open" wurde hinzugefügt. Mit diesem Feature kann die API-Verarbeitung fortgesetzt werden, wenn ein abgelaufenes JWT-Token aufgrund eines Verbindungsfehlers, der einen erfolgreichen Aufruf der API-Schlüsselüberprüfung an den edgemicro-auth-Proxy verhindert, nicht aktualisiert werden kann.

  Mit diesem Feature können Sie einen Kulanzzeitraum festlegen, in dem das alte Token im Cache verbleibt und bis zum Ablauf des Kulanzzeitraums wiederverwendet wird. Diese Funktion ermöglicht es Edge Microgateway, Anfragen bei einem temporären Verbindungsfehler weiter zu verarbeiten. Wenn die Verbindung wiederhergestellt wird und ein erfolgreicher Aufruf des API-Schlüssels durchlaufen wird, wird ein neues JWT abgerufen, das das alte JWT im Cache ersetzt.

  So konfigurieren Sie die neue Funktion "Fail-Open":

  1. Legen Sie die folgenden Attribute in der Stanza oauth in der Konfigurationsdatei von Edge Microgateway fest:

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

     Beispiel:

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

     In diesem Beispiel wird das alte Token 5 Sekunden lang verwendet, wenn es aufgrund eines Verbindungsproblems nicht aktualisiert werden kann. Nach fünf Sekunden wird ein Authentifizierungsfehler zurückgegeben.

• 141168968: Es wurde eine Aktualisierung durchgeführt, um correlation_id in alle Plug-in-Logausgaben aufzunehmen. Außerdem wurden die Logebenen für einige Logs bei Bedarf in error geändert.
• 140193349: Der edgemicro-auth-Proxy wurde aktualisiert, dass der Edge Microgateway-Schlüssel und das Secret bei jeder Anfrage zum Überprüfen des API-Schlüssels verifiziert werden müssen. Edge Microgateway wurde aktualisiert, um den Schlüssel und das Secret bei jeder Anfrage zum Überprüfen des API-Schlüssels zu senden. Durch diese Änderung wird verhindert, dass Clients ein JWT nur mit einem API-Schlüssel abrufen.
• 140090250: Es wurde eine Aktualisierung durchgeführt, um eine Diagnoseprotokollierung für die Kontingentverarbeitung hinzuzufügen. Mit dieser Änderung ist es jetzt möglich, die Logausgabe von Quotō mit den übrigen Edge Microgateway-Logs zu korrelieren.

3.0.7

Am Donnerstag, dem 12. September wurden die folgenden Fehlerbehebungen und Verbesserungen für Edge Microgateway veröffentlicht.

Komponentenversionen:

In der folgenden Tabelle sind die Versionsnummern für die einzelnen Komponentenprojekte aufgeführt, die mit Edge Microgateway 3.0.7 verknüpft sind. Da jede Komponente ein separates Projekt ist, stimmen die Release-Nummern möglicherweise nicht mit der Hauptproduktversion überein:

Fehlerkorrekturen und Verbesserungen:

• 140075602: Das OAuth-Plug-in wurde aktualisiert, sodass gegebenenfalls ein 5xx-Statuscode zurückgegeben wird. Bisher hat das Plug-in nur 4xx-Statuscodes in allen Fällen zurückgegeben, die nicht 200 sind. Jetzt wird für jede Nachrichtenantwort, die keinen 200-Status hat, der genaue 4xx- oder 5xx-Code zurückgegeben, je nach Fehler.

  Diese Funktion ist standardmäßig deaktiviert. Fügen Sie der Edge Microgateway-Konfiguration das Attribut oauth.useUpstreamResponse: true hinzu, um dieses Feature zu aktivieren. Beispiel:

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

• 140090623 – In Version 3.0.6 wurde die neue Konfigurationseigenschaft quota.quotaUri hinzugefügt. Legen Sie dieses Konfigurationsattribut fest, wenn Sie Kontingente über den edgemicro-auth-Proxy verwalten möchten, der in Ihrer Organisation bereitgestellt wird. Wenn dieses Attribut nicht festgelegt ist, wird als Kontingentendpunkt standardmäßig der interne Edge Microgateway-Endpunkt verwendet. Beispiel:

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

  In Version 3.0.7 wurde edgemicro-auth zur Übernahme dieser neuen Konfiguration aktualisiert. Wenn Sie das Attribut quotaUri verwenden möchten, müssen Sie ein Upgrade auf den neuesten edgemicro-auth-Proxy durchführen. Weitere Informationen finden Sie unter Upgrade des Edgemicro-auth-Proxys.

• 140470888: Zur Authentifizierung wurde ein Autorisierungsheader zu Kontingentaufrufen hinzugefügt. Außerdem wurde der edgemicro-auth-Proxy geändert, um „Organisation“ aus der Kontingent-ID zu entfernen. Da sich der Kontingentendpunkt in der Organisation des Kunden befindet, wird die Kontingent-ID nicht mehr benötigt.
• 140823165 – Der folgende Property-Name:

  edgemicro:
      keepAliveTimeout

  wurde in Version 3.0.6 falsch dokumentiert. Der richtige Attributname lautet:

  edgemicro:
      keep_alive_timeout

• 139526406: Ein Fehler wurde behoben, bei dem eine falsche Kontingentzahl auftrat, wenn eine Entwickler-App mehrere Produkte enthielt. Das Kontingent wird jetzt für jedes Produkt in einer App mit mehreren Produkten korrekt erzwungen. Die Kombination aus „appName + productName“ wird als Kontingent-ID verwendet.

3.0.6

Am Donnerstag, dem 29. August, wurden die folgenden Fehlerbehebungen und Verbesserungen für Edge Microgateway veröffentlicht.

• 138633700 – Neues Konfigurationsattribut hinzugefügt: keepAliveTimeout. Mit diesem Attribut können Sie das Edge Microgateway-Zeitlimit (in Millisekunden) festlegen. (Standardeinstellung: 5.000 Millisekunden)

  Beispiel:

  edgemicro:
    keep_alive_timeout: 600

• 140090623 – Das neue Konfigurationsattribut „quotaUri“ wurde hinzugefügt. Legen Sie dieses Konfigurationsattribut fest, wenn Sie Kontingente über den edgemicro-auth-Proxy verwalten möchten, der in Ihrer Organisation bereitgestellt wird. Wenn dieses Attribut nicht festgelegt ist, wird als Kontingentendpunkt standardmäßig der interne Edge Microgateway-Endpunkt verwendet. Beispiel:

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

  Damit Sie dieses Feature verwenden können, müssen Sie zuerst die neueste Version des edgemicro-auth-Proxys in Ihrer Organisation bereitstellen. Weitere Informationen finden Sie unter Upgrade des Edgemicro-auth-Proxys ausführen.

• 138722809 – Das neue Konfigurationsattribut „stack_trace“ wurde hinzugefügt. Mit dieser Eigenschaft können Sie festlegen, ob Stacktraces in Protokolldateien angezeigt werden. Beispiel:

  stack_trace: false

  Wenn stack_trace auf true gesetzt ist, wird der Stacktrace in Logs ausgegeben. Wenn false festgelegt ist, wird der Stacktrace nicht in Logs ausgegeben.

3.0.5

Am Donnerstag, dem 15. August, wurden die folgenden Fehlerbehebungen und Verbesserungen für Edge Microgateway veröffentlicht.

• 139005279: Ein Problem wurde behoben, bei dem der Befehl edgemicro status nicht die richtige Anzahl von Worker-Prozessen zurückgibt.
• 138437710: In der Klasse "ExitCounter" wurde ein Problem behoben, das verhindert, dass das richtige Log geschrieben werden konnte.

• 139064652: Möglichkeit zum Hinzufügen der Logging-Ebenen trace und debug für Ereignis- und Systemlogs Derzeit wurde nur die Möglichkeit zum Hinzufügen dieser Protokollebenen hinzugefügt. Derzeit sind die Logebenen info, warn und error verfügbar.
• 139064616 – Die Protokollausgabe wurde für alle Konsolen-Protokollanweisungen standardisiert. Die Logging-Anweisungen in der Konsole enthalten jetzt folgende Attribute:
• Zeitstempel
• Komponentenname
• Prozess-ID
• Konsolen-Lognachricht

• 138413755 – Verbessern Sie den JWT-Schlüssel und Secret-bezogene Lognachrichten für die folgenden Befehlszeilenbefehle: cert, verify, upgradekvm, token, genkeys, capturekeys, convertkey undconfigure.

• 138413577 – Die Fehlerbehandlung für Zeitüberschreitungen von Back-End-Diensten wurde hinzugefügt und verbessert.
• 138413303 – Verbesserte Fehlerbehandlung für Antwort- und Socket-Zeitüberschreitungen.
• 138414116 – Die Fehlerbehandlung für Fehler des Typs "Verbindung verweigert" wurde hinzugefügt und verbessert.

3.0.4

Am Donnerstag, dem 1. August, wurden die folgenden Fehlerbehebungen und Verbesserungen für Edge Microgateway veröffentlicht.

• 134445926 – Verbesserungen bei der internen Edge Microgateway-Authentifizierung.
• 137582169: Ein Problem wurde behoben, bei dem unerwünschte Prozesse gestartet wurden. Die zusätzlichen Prozesse haben die Plug-ins zum Aktualisieren veranlasst und übermäßig viel Arbeitsspeicher belegt. Edge Microgateway hält jetzt die Anzahl der Prozesse innerhalb des erwarteten Limits.
• 137768774 – Verbesserungen von Lognachrichten:
  • Transaktionslogs (Anfrage) wurden bereinigt.
  • Bei Bedarf wurden weitere Logeinträge hinzugefügt.
  • Transaktions-Log-Nachrichten (Anfrage) wurden von der Konsolenausgabe in die entsprechende Log-Datei verschoben.
  • Die Konsolenlogs wurden aktualisiert, um eine zentralisierte Protokollierungsfunktion zu verwenden.
• 138321133, 138320563 – Grundlegende interne Änderung am Kontingentzwischenspeicher, um zukünftige Kontingenterweiterungen zu ermöglichen.

3.0.3

Am Dienstag, dem 23. Juli, wurden die folgenden Fehlerbehebungen und Verbesserungen für Edge Microgateway veröffentlicht.

• Verbesserungen bei der Protokollierung: Für vorhandene Laufzeitlogs wird eine neue eventLog()-Funktion verwendet, mit der Laufzeitdaten in einem einheitlichen Format erfasst und protokolliert werden. Zu den Loginformationen gehören:
  • Zeitstempel (ISO 8601: JJJJ-MM-TTTHH:mm:ss.sssZ).
  • Logebene (Fehler, Warnung oder Info).
  • Hostname: Der anfragende Hostname aus dem Anfrage-Header.
  • Process ID: Wenn Sie einen Cluster von Node.js-Prozessen ausführen, ist dies die ID des Prozesses, in dem das Logging erfolgte.
  • Name der Apigee-Organisation.
  • Name der Umgebung in der Organisation.
  • API-Proxy-Name.
  • IP-Adresse des Clients.
  • Client-ID.
  • Korrelations-ID (derzeit nicht festgelegt).
  • Name der Edge Microgateway-Komponente.
  • Benutzerdefinierte Meldung: Einige Objekte geben möglicherweise zusätzliche Informationen aus, die an diese Fehlereigenschaft übergeben werden.
  • Anfragemethode (bei HTTP-Anfrage).
  • Statuscode der Antwort (bei HTTP-Anfrage).
  • Eine Nachricht zu einem Fehler.
  • Fehlercode: Wenn ein Objekt einen Fehlercode enthält, wird er in dieser Eigenschaft ausgegeben.
  • Benötigte Zeit.
  • Markierung für das Zeilenende des Betriebssystems.

  Null-Property-Werte führen zu leeren Klammern: [].

  Das folgende Beispiel zeigt das Logformat:

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

  137770055

• Leistung: API-Produkte wurden nicht nach Umgebung gefiltert. Dieses Problem wurde behoben. 135038879
• Verschiedene Funktionstests und Verbesserungen der Codequalität.

3.0.2

Am Mittwoch, dem 3. Juli 2019, wurden die folgenden Fehlerbehebungen und Verbesserungen für Edge Microgateway veröffentlicht.

Codequalität: Der Code wurde auf seine Qualität überprüft und Änderungen am Code vorgenommen, um die von Nutzern geforderten Qualitätsstandards zu erfüllen. Wir haben Fehler und Warnungen bezüglich der Codequalität in Bezug auf JSHint behandelt. Dadurch wurden einige tatsächliche Codefehler identifiziert und behoben. Alle Apigee Edge Microgateway-Module wurden diesen Prozess durchlaufen. Siehe die Commits vom 28. Juni und 2. Juli für microgateway-config, microgateway-core, microgateway-plugins und microgateway. Alle Module mit Änderungen der Codequalität wurden mit internen Tools getestet, die die Ausführung von Edge Microgateway für Kundenanwendungsfälle prüfen.

3.0.1

Am Freitag, dem 21. Juni 2019, wurden die folgenden Fehlerbehebungen und Verbesserungen für Edge Microgateway veröffentlicht.

• 134834551 – Unterstützte Node.js-Versionen für Edge Microgateway ändern
  (Von Node.js unterstützte Versionen: 8 und 12; Versionen 7, 9 und 11 sind experimentell)
• 134751883 – Edge Microgateway stürzt beim Aktualisieren unter Last ab.
• 134518428 – Produktendpunkt für Edge Microgateway gibt 5XX zurück, wenn das Filtermuster falsch ist
• 135113408 – Worker sollten neu gestartet werden, wenn sie unerwartet beendet werden
• 134945852 – tokenCacheSize wird im OAuth-Plug-in nicht verwendet.
• 134947757 – CacheTTL im OAuth-Plug-in festlegen
• 135445171 – Berechnung des Kulanzzeitraums in OAuth ist nicht korrekt
• Mit der Edge Microgateway-Installation bereitgestelltes Speichermodul verwenden
• 135367906 – Sicherheitsprüfung

Version 2.5.x

Neue Funktionen und Verbesserungen Version 2.5.x

(Behoben: 2.5.38, 07.06.2019)

Falsch formatierte JWTs können bei Verwendung des Token-Cache zu Abstürzen bei Workern führen. Behoben im Edge-Microgateway-Plug-in-Modul. (b/134672029)

(2.5.37 hinzugefügt) Fügen Sie die Befehlszeilenoption edgemicro-cert -t hinzu.

Mit der Option edgemicro cert -t können Sie ein OAuth-Token angeben, um Verwaltungs-APIs zu authentifizieren. Weitere Informationen finden Sie unter Zertifikate verwalten.

(2.5.35 hinzugefügt) Unterstützung für das Debuggen von Edge Microgateway mit edgemicroctl

Sie können das Flag mgdebug mit edgemicroctl verwenden. Siehe auch Kubernetes-Einbindungsaufgaben.

(2.5.35 hinzugefügt) Windows-Build für edgemicroctl aktivieren

(2.5.31 hinzugefügt) Neue Edgemicro-auth/Token API

Eine neue Edgemicro-auth/token-API wurde hinzugefügt, mit der Sie den Client/das Secret als Base64-codierten Basic Authorization-Header und den Grants_type als Formularparameter übergeben können. Weitere Informationen finden Sie unter Inhabertoken direkt abrufen.

(Behoben 2.5.31) Bei der privaten Konfiguration wird das Token-Flag nicht berücksichtigt.

Ein Problem wurde behoben, bei dem das Konfigurieren von Edge Microgateway zur Verwendung eines OAuth2-Zugriffstokens in Edge für Private Cloud nicht ordnungsgemäß funktioniert hat (das Token wurde nicht berücksichtigt).

Docker: Unterstützung für die Verwendung selbst signierter Zertifikate

(Hinzugefügt 2.5.29) Wenn Sie eine Zertifizierungsstelle verwenden, die von Node.js nicht standardmäßig als vertrauenswürdig eingestuft wird, können Sie den Parameter NODE_EXTRA_CA_CERTS beim Ausführen eines Docker-Containers mit Edge Microgateway verwenden. Weitere Informationen finden Sie unter Zertifizierungsstelle verwenden, die von Node.js nicht als vertrauenswürdig eingestuft wird.

Docker: Unterstützung für TLS

(2.5.29 hinzugefügt) Edge Microgateway, das in einem Docker-Container ausgeführt wird, unterstützt jetzt TLS für eingehende Anfragen beim Edge Microgateway-Server (northbound-Anfragen) und für ausgehende Anfragen von Edge Microgateway an eine Zielanwendung (Southbound-Anfragen).

In den folgenden Beispielen wird ausführlich erläutert, wie diese TLS-Konfigurationen eingerichtet werden:

• Beispiel für eine TLS-Konfiguration nach Norden
• Beispielkonfiguration für Southbound-TLS

In diesen Beispielen erfahren Sie, wie Sie den Containerbereitstellungspunkt /opt/apigee/.edgemicro verwenden, um die Zertifikate zu laden, auf die dann in der Konfigurationsdatei von Edge Microgateway verwiesen wird.

Docker: Unterstützung für Anfrage-Proxys

(Hinzugefügt 2.5.27) Wenn Sie Edge Microgateway in einem Docker-Container ausführen, können Sie mit diesen Optionen das Proxyverhalten steuern, wenn das Mikrogateway hinter einer Firewall ausgeführt wird:

• HTTP_PROXY
• HTTPS_PROXY
• NO_PROXY

Weitere Informationen finden Sie unter Edge Micro als Docker-Container ausführen.

Docker: Aktualisierte Plug-in-Anleitung

(Hinzugefügt: 2.5.27) Wenn Sie Edge Microgateway in einem Docker-Container ausführen, haben Sie jetzt zwei Möglichkeiten, Plug-ins bereitzustellen. Eine Möglichkeit, ein Docker-Bereitstellungspunkt, ist neu. Die andere Option, die es zuvor gab, ist im Grunde unverändert. Das Dockerfile wurde jedoch aktualisiert. Weitere Informationen finden Sie unter den folgenden Links:

• Option A: Plug-in-Verzeichnis auf einem Volume bereitstellen (Neu)
• Option B: Plug-ins in den Container einbauen (aktualisiert)

Neue Unterstützung von OAuth-Tokens für den KVM-Upgradebefehl

(2.5.27 hinzugefügt) Du kannst ein OAuth-Token mit dem Befehl upgradekvm verwenden. Weitere Informationen finden Sie unter KVM upgraden.

APIs in Edge Analytics trennen

(2.5.26 hinzugefügt) Mit neuen Analyse-Plug-in-Flags können Sie einen bestimmten API-Pfad trennen, sodass er in den Edge Analytics-Dashboards als separater Proxy angezeigt wird. Sie können beispielsweise Systemdiagnose-APIs trennen, um sie mit tatsächlichen API-Aufrufen zu verwirren. Weitere Informationen finden Sie unter Pfade aus Analysen ausschließen.

Lokalen Proxy konfigurieren

(2.5.25 hinzugefügt) Mit einem lokalen Proxy müssen Sie nicht manuell einen Microgateway-fähigen Proxy in Apigee Edge erstellen. Stattdessen verwendet das Mikrogateway den Basispfad des lokalen Proxys. Weitere Informationen finden Sie unter Lokalen Proxymodus verwenden.

Eigenständigen Modus verwenden

(2.5.25 hinzugefügt) Sie können Edge Microgateway vollständig getrennt von jeder Apigee Edge-Abhängigkeit ausführen. In diesem als eigenständigen Modus bezeichneten Szenario können Sie Edge Microgateway ohne Internetverbindung ausführen und testen. Weitere Informationen finden Sie unter Edge Microgateway im eigenständigen Modus ausführen.

Schlüssel widerrufen

(2.5.19 hinzugefügt) Es wurde ein neuer Befehl der Befehlszeile hinzugefügt, der die Schlüssel- und geheimen Anmeldedaten für eine Edge Microgateway-Konfiguration widerruft.

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

Docker-Unterstützung

(Hinzugefügt: 2.5.19) Sie können jetzt die neueste Version von Edge Microgateway als Docker-Image herunterladen:

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

Kubernetes-Unterstützung

(Hinzugefügt 2.5.19) Sie können Edge Microgateway als Dienst oder als Sidecar-Gateway vor Diensten bereitstellen, die in einem Kubernetes-Cluster bereitgestellt werden. Weitere Informationen finden Sie unter Edge Microgateway mit Kubernetes einbinden – Übersicht.

Unterstützung für TCP-Nodelay-Option

(2.5.16 hinzugefügt) Der Edge Micro-Konfiguration wurde die neue Konfigurationseinstellung nodelay hinzugefügt.

Standardmäßig verwenden TCP-Verbindungen den Nagle-Algorithmus, um Daten zu puffern, bevor sie gesendet werden. Wenn Sie nodelay auf true festlegen, wird dieses Verhalten deaktiviert. Daten werden bei jedem Aufruf von socket.write() sofort durch Daten ausgelöst. Weitere Informationen finden Sie in der Node.js-Dokumentation.

Um nodelay zu aktivieren, bearbeiten Sie die Edge Micro-Konfigurationsdatei so:

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

Neue Befehlszeilenoptionen für das dauerhafte Monitoring

(2.5.12 hinzugefügt) Dem Befehl edgemicro forever wurden neue Parameter hinzugefügt. Mit diesen Parametern können Sie den Speicherort der Datei forever.json angeben und den Hintergrundprozess „Forever“ starten oder beenden. Siehe auch Endgültiges Monitoring

Beispiele:

So startest du den Modus „Unbegrenzt“:

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

So kannst du die Einstellung „Unbegrenzt“ beenden:

edgemicro forever -a stop

JWT-Schlüsselrotation

Es wurde ein neues Feature hinzugefügt, mit dem Sie die öffentlichen/privaten Schlüsselpaare rotieren können, die zum Generieren der JWT-Tokens für die OAuth-Sicherheit in Edge Microgateway verwendet werden. Weitere Informationen finden Sie unter JWT-Schlüssel rotieren.

Heruntergeladene API-Proxys filtern

Edge Microgateway lädt standardmäßig alle Proxys in Ihrer Edge-Organisation herunter, die mit dem Namenspräfix „edgemicro_“ beginnen. Sie können diese Standardeinstellung ändern, um Proxys herunterzuladen, deren Namen einem Muster entsprechen. Weitere Informationen finden Sie unter Heruntergeladene Proxys filtern.

Produkte ohne API-Proxys angeben

In Apigee Edge können Sie ein API-Produkt erstellen, das keine API-Proxys enthält. Bei dieser Produktkonfiguration kann ein mit diesem Produkt verknüpfter API-Schlüssel mit jedem Proxy verwendet werden, der in Ihrer Organisation bereitgestellt wird. Ab Version 2.5.4 unterstützt Edge Microgateway diese Produktkonfiguration.

Unterstützung für dauerhaftes Monitoring

Edge Microgateway hat eine forever.json-Datei, mit der Sie steuern können, wie oft und in welchen Intervallen Edge Microgateway neu gestartet werden soll. Diese Datei konfiguriert einen Dienst namens „always-monitor“, der Forever programmatisch verwaltet. Weitere Informationen finden Sie unter Endgültiges Monitoring.

Zentrale Verwaltung der Edge Micro-Konfigurationsdatei

Wenn Sie mehrere Edge Microgateway-Instanzen ausführen, möchten Sie möglicherweise deren Konfigurationen von einem einzigen Standort aus verwalten. Dazu können Sie einen HTTP-Endpunkt angeben, von dem Edge Micro seine Konfigurationsdatei herunterladen kann. Weitere Informationen finden Sie unter Endpunkt für die Konfigurationsdatei angeben.

Unterstützung einer dauerhaften Befehlszeilenoption

(Version 2.5.8 hinzugefügt) Verwenden Sie den Befehl edgemicro forever [package.json], um den Speicherort der Datei forever.json anzugeben. Bevor dieser Befehl hinzugefügt wurde, musste sich die Konfigurationsdatei im Stammverzeichnis von Edge Microgateway befinden.

Beispiel:

edgemicro forever ~/mydir/forever.json

Option „configUrl“ für den Befehl zum Aktualisieren hinzugefügt

(Version 2.5.8 hinzugefügt) Sie können jetzt die Option --configUrl oder -u mit dem Befehl edgemicro reload verwenden.

Kulanzzeitraum für Abweichungen bei der JWT-Zeit

2.5.7 hinzugefügtgracePeriod Legen Sie für dieses Attribut die Anzahl von Sekunden fest, um solche Abweichungen zu berücksichtigen. Siehe OAuth-Attribute.

2.5.7 hinzugefügtgracePeriod Legen Sie für dieses Attribut die Anzahl von Sekunden fest, um solche Abweichungen zu berücksichtigen. Siehe OAuth-Attribute.

Fehlerkorrekturen in Version 2.5.x

• Problem Nr. 236: Tippfehler beim Leeren des Cache wurden behoben.
• (Problem Nr. 234) Abstürze bei Edge Microgateway 2.5.35 neu laden.
• Problem 135: Fehler "Ungültige virtuelle Hostreferenz" bei Verwendung der Option -v. Durch diese Fehlerkorrektur wird der Edgemicro-auth-Proxy vor der Bereitstellung geändert, damit die virtuellen Hosts genau dem entsprechen, was im Flag "-v" angegeben ist. Darüber hinaus können Sie eine beliebige Anzahl und einen beliebigen Namen für den virtuellen Host angeben (nicht mehr auf „Standard“ und „sicher“).
• (Problem 141) Der Befehl edgemicrorefresh unterstützt die Konfigurationsdateioption -c nicht. Dieses Problem wurde inzwischen behoben.
• (Problem Nr. 142) Edge Microgateway beschwert sich über eine veraltete Kryptowährung bei der Installation. Dieses Problem wurde inzwischen behoben.
• Problem 145: Kontingent funktioniert nicht mit Edge Microgateway. Dieses Problem wurde inzwischen behoben.
• (Apigee-Community-Problem: https://community.apigee.com/questions/33149/emg-jwt-token-validd-against-Bot-api-proxies-a.html#answer-33336) JWT-Token wurde anhand von API-Proxys und dem Ressourcen-URI in OAUTH validiert. Dieses Problem wurde behoben.
• (Apigee-Community-Problem: https://community.apigee.com/questions/47846/microgateway-not-working-with-oauth.html) Microgateway funktioniert nicht mit OAuth. Dieses Problem wurde inzwischen behoben.
• Beheben Sie das Problem mit pidPath unter Windows.
• Problem 157: Das Problem, das zur folgenden Fehlermeldung führte, wurde behoben: ReferenceError: deployProxyWithPassword ist nicht definiert.
• Problem 169: Node.js-Abhängigkeiten aktualisieren (npm-Audit)
• Der edgemicro-auth-Proxy verwendet jetzt die Edge-JWT-Richtlinien. Der Proxy ist zur Bereitstellung von JWT-Unterstützung nicht mehr von Node.js abhängig.

Version 2.4.x

Neue Funktionen und Verbesserungen Version 2.4.x

1. Benutzerdefinierten Alias für den Edgemicro-auth-Proxy (PR 116) festlegen

Sie können den Standardbasispfad für den Proxy edgemicro-auth ändern. Standardmäßig ist der Basispfad /edgemicro-auth. Verwenden Sie das Flag -x im Befehl edgemicro config, um dies zu ändern.

Beispiel:

edgemicro configure -x /mypath …

2. Unterstützung von Platzhaltern für Basispfade (PR 77)

Sie können einen oder mehrere „*“-Platzhalter im Basispfad eines edgemicro_*-Proxys verwenden. Der Basispfad /team/*/members ermöglicht es Clients beispielsweise, https://[host]/team/blue/members und https://[host]/team/green/members aufzurufen, ohne neue API-Proxys zur Unterstützung neuer Teams erstellen zu müssen. Beachten Sie, dass /**/ nicht unterstützt wird.

3. Benutzerdefinierter Konfigurationspfad wurde der Befehlszeile für die Konfiguration der Private Cloud hinzugefügt (PR 99)

Die Konfigurationsdatei des Mikrogateways befindet sich standardmäßig in ./config/config.yaml. Für die Befehle „init“, „Konfigurieren“ und „Starten“ können Sie jetzt mit den Flags -c oder --configDir einen benutzerdefinierten Konfigurationspfad in der Befehlszeile angeben. Ein Problem wurde behoben, bei dem ein benutzerdefiniertes Konfigurationsverzeichnis für Private Cloud-Installationen nicht erkannt wurde.

Beispiel:

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

4. *_PROXY-Variablen respektieren (PR 61)

Wenn Edge Microgateway hinter einer Firewall installiert ist und in der öffentlichen Cloud nicht mit Apigee Edge kommunizieren kann, sollten Sie zwei Optionen berücksichtigen:

Option 1:

Die erste Möglichkeit besteht darin, die Option „edgemicro: proxy_tunnel“ in der Konfigurationsdatei des Microgateways auf „true“ zu setzen:

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

Wenn proxy_tunnel auf true gesetzt ist, verwendet Edge Microgateway die Methode HTTP CONNECT zum Tunneln von HTTP-Anfragen über eine einzelne TCP-Verbindung. Dasselbe gilt, wenn die Umgebungsvariablen zum Konfigurieren des Proxys TLS aktiviert sind.

Option 2:

Die zweite Möglichkeit besteht darin, einen Proxy anzugeben und proxy_tunnel in der Konfigurationsdatei des Microgateways auf false zu setzen. Beispiel:

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

In diesem Fall können Sie die folgenden Variablen festlegen, um die Hosts für jeden HTTP-Proxy zu steuern, den Sie verwenden möchten, oder um die Hosts, die keine Edge Microgateway-Proxys verarbeiten sollen, zu steuern: HTTP_PROXY, HTTPS_PROXY und NO_PROXY. Sie können NO_PROXY als durch Kommas getrennte Liste von Domains festlegen, an die Edge Microgateway nicht weitergeleitet werden soll. Beispiel:

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

Weitere Informationen zu diesen Variablen finden Sie unter:

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

5. Benutzerdefiniertes Zeitlimit für Zielanfragen festlegen (PR 57)

Mit dieser Konfiguration können Sie ein benutzerdefiniertes Zeitlimit für Zielanfragen festlegen:

edgemicro:
    request_timeout: 10

Das Zeitlimit wird in Sekunden festgelegt. Wenn ein Zeitlimit auftritt, antwortet Edge Microgateway mit einem 504-Statuscode.

6. Benutzerdefinierte HTTP-Statusmeldungen für die Zielantwort berücksichtigen (PR 53)

Edge Microgateway respektiert benutzerdefinierte HTTP-Statusnachrichten, die für die Zielantwort festgelegt wurden. In früheren Releases wurden vom Ziel gesendete Statusmeldungen mit Node.js-Standardeinstellungen überschrieben.

7. Mit dem X-Forwarded-For-Header kann „client_ip“ für Analysen festgelegt werden.

Falls vorhanden, legt der Header X-Forwarded-For die Variable client_ip fest, die in Edge Analytics gemeldet wird. Dieses Feature informiert Sie über die IP-Adresse des Clients, der eine Anfrage an Edge Microgateway gesendet hat.

8. Änderungen am OAuth-Plug-in

Das OAuth-Plug-in unterstützt die Überprüfung von API-Schlüsseln und OAuth-Zugriffstokens. Vor dieser Änderung akzeptierte das Plug-in beide Sicherheitsformen. Mit dieser Änderung können Sie nur eines dieser Sicherheitsmodelle zulassen (unter Aufrechterhaltung der Abwärtskompatibilität).

Den OAuth-Plug-ins werden zwei neue Flags hinzugefügt:

• allowOAuthOnly: Wenn diese Richtlinie auf true gesetzt ist, muss jede API einen Autorisierungsheader mit einem Zugriffstoken für Inhaber enthalten.

• allowAPIKeyOnly: Bei Einstellung auf true muss jede API einen x-api-key-Header (oder einen benutzerdefinierten Speicherort) mit einem API-Schlüssel enthalten.

Sie legen diese Flags in der Konfigurationsdatei von Edge Microgateway so fest:

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

9. Verbesserter Edgemicro-Auth-Proxy (PR 40)

Der edgemicro-auth-Proxy wurde verbessert. Vor diesen Änderungen hat der Proxy Schlüssel im Edge Secure Store, einem verschlüsselten Tresor, gespeichert. Jetzt speichert der Proxy Schlüssel in der verschlüsselten Schlüssel/Wert-Zuordnung (KVM) von Edge.

10. Standard-Ziel-URL in einem Plug-in umschreiben (PR 74)

Sie können auch den Port des Zielendpunkts überschreiben und zwischen HTTP und HTTPS auswählen. Ändern Sie die folgenden Variablen im Plug-in-Code: req.targetPort und req.targetSecure. Um HTTPS auszuwählen, setzen Sie req.targetSecure auf true und für HTTP auf false. Wenn Sie „req.targetSecure“ auf „true“ setzen, finden Sie in diesem Diskussionsthread weitere Informationen.

11. Erste Unterstützung der OAuth-Token-Authentifizierung (PR 125)

Sie können Edge Microgateway so konfigurieren, dass anstelle von Nutzername und Passwort ein OAuth-Token für die Authentifizierung verwendet wird. Verwenden Sie den folgenden Parameter im Befehl edgemicro config, um ein OAuth-Token zu verwenden:

-t, --token <token>

Beispiel:

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

Fehlerkorrekturen in Version 2.4.3

• Es wurde ein Problem behoben, bei dem eine kostenpflichtige Organisation den Edgemicro-auth-Proxy ordnungsgemäß ausführen musste. Jetzt können Sie Edge Microgateway auch mit Testorganisationen verwenden. (PR 5)
• Ein Problem wurde behoben, bei dem die Verarbeitung der Daten des Streams nicht abgeschlossen war, End-Handler aber trotzdem ausgeführt wurden. Dies hat dazu geführt, dass eine Teilantwort gesendet wurde. (PR 71)
• Ein Problem wurde behoben, bei dem ein benutzerdefiniertes Konfigurationsverzeichnis für Private Cloud-Installationen nicht erkannt wurde. (PR 110)
• Ein Problem mit bidirektionalem SSL zwischen dem Client und Edge Microgateway wurde behoben. (PR 70)
• Es wurde ein Problem behoben, bei dem auf dem Proxy-Basispfad ein abschließender Schrägstrich erforderlich war, damit die Überprüfung des API-Schlüssels ordnungsgemäß funktionierte. Jetzt ist ein abschließender Schrägstrich am Ende des Basispfads nicht mehr erforderlich. (PR 48)

Version 2.3.5

Neue Funktionen und Verbesserungen v2.3.5

Proxyfilter

Sie können filtern, welche Microgateway-fähigen Proxys eine Edge Microgateway-Instanz verarbeiten. Beim Start von Edge Microgateway werden alle Proxys, die auf Mikrogateways reagieren, in der Organisation heruntergeladen, der es zugeordnet ist. Mit der folgenden Konfiguration können Sie einschränken, welche Proxys das Mikrogateway verarbeitet. Diese Konfiguration beschränkt die Proxys, die das Mikrogateway verarbeitet, auf drei: edgemicro_proxy-1, edgemicro_proxy-2 und edgemicro_proxy-3:

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

Analytics-Datenmaskierung

Mit einer neuen Konfiguration können Sie verhindern, dass Anfragepfadinformationen in Edge-Analysen angezeigt werden. Fügen Sie der Mikrogateway-Konfiguration Folgendes hinzu, um den Anfrage-URI und/oder den Anfragepfad zu maskieren. Der URI besteht aus dem Hostnamen und dem Pfadteil der Anfrage.

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

Version 2.3.3

Neue Funktionen und Verbesserungen v2.3.3

Im Folgenden finden Sie die neuen Funktionen und Verbesserungen in dieser Version.

Automatische Änderungsumfrage deaktivieren

Sie können automatische Änderungsabfragen deaktivieren, indem Sie dieses Attribut in der Mikrogateway-Konfiguration festlegen:

disabled_config_poll_interval: true

Standardmäßig werden bei regelmäßigen Abfragen alle Änderungen erfasst, die an Edge vorgenommen wurden (Änderungen an Produkten, Proxys, die auf Mikrogateways ausgerichtet sind usw.) sowie an der lokalen Konfigurationsdatei. Das standardmäßige Abfrageintervall beträgt 600 Sekunden (fünf Minuten).

Ziel-URLs in Plug-ins umformulieren

Sie können die Standard-Ziel-URL dynamisch in einem Plug-in überschreiben, indem Sie die folgenden Variablen in Ihrem Plug-in-Code ändern: req.targetHostname und req.targetPath.

Neue Plug-in-Funktionssignatur

Es wurde eine neue Plug-in-Funktionssignatur hinzugefügt, die die Zielantwort als Argument bereitstellt. Durch diese Ergänzung können Plug-ins leichter auf die Zielantwort zugreifen.

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

Vereinfachte Standard-Logging-Ausgabe

Standardmäßig lässt der Logging-Dienst jetzt den JSON-Code heruntergeladener Proxys, Produkte und JWT weg. Sie können zur Standardausgabe dieser Objekte wechseln. Legen Sie dazu DEBUG=* fest, wenn Sie Edge Microgateway starten. Beispiel:

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

Benutzerdefinierter Konfigurationspfad wurde der Befehlszeile hinzugefügt

Die Konfigurationsdatei des Mikrogateways befindet sich standardmäßig in ./config/config.yaml. Bei den Befehlen „Init“, „Konfigurieren“ und „Start“ können Sie jetzt einen benutzerdefinierten Konfigurationspfad in der Befehlszeile angeben. Beispiel:

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

Fehlerkorrekturen in Version 2.3.3

• Ein Speicherleck wurde behoben, das bei umfangreichen Anfragen/Antworten aufgetreten ist.
• Die Ausführungsreihenfolge des Plug-ins wurde korrigiert. Sie verhält sich jetzt so, wie in der Dokumentation erläutert.
• Das Plug-in „Akkumulierungsanfrage“ bleibt bei GET-Anfragen nicht mehr hängen.
• Im Akkumulierungs-Plug-in wurde ein Problem behoben, bei dem ein fehlender Antworttext zu Fehlern führte.

Version 2.3.1

Installationshinweis

In einigen früheren Versionen von Edge Microgateway können Sie die Software durch Herunterladen einer ZIP-Datei installieren. Diese ZIP-Dateien werden nicht mehr unterstützt. Zum Installieren von Edge Microgateway müssen Sie Folgendes verwenden:

npm install -g edgemicro

Weitere Informationen finden Sie im Installationsthema.

Neue Funktionen und Verbesserungen v2.3.1

Im Folgenden finden Sie die neuen Funktionen und Verbesserungen in dieser Version.

Proxys filtern

Mit einer neuen Konfiguration können Sie filtern, welche Proxys, die Edge Microgateway beim Start laden, wird gefiltert. Zuvor hat das Mikrogateway alle Proxys mit Mikrogateway-Erkennung (Proxys mit dem Namen „edgemicro_*“) geladen, die aus der Edge-Organisation/-Umgebung abgerufen wurden, die Sie im Edgemicro-Konfigurationsbefehl angegeben haben. Mit diesem neuen Feature können Sie diese Liste von Proxys so filtern, dass Edge Microgateway nur die von Ihnen angegebenen Proxys lädt. Fügen Sie das Proxy-Element einfach so zur Mikrogateway-Konfigurationsdatei hinzu:

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

Angenommen, Sie haben 50 edgemicro_*-Proxys in Ihrer Edge-Organisation/Umgebung, einschließlich der Proxys edgemicro_foo und edgemicro_bar. Sie können das Mikrogateway so anweisen, nur diese beiden Proxys zu verwenden:

edge micro:
proxies:
    - edgemicro_foo
    - edgemicro_bar

Beim Start kann das Mikrogateway nur die angegebenen Proxys aufrufen. Jeder Versuch, andere Microgateway-fähige Proxys aufzurufen, die aus der Edge-Organisation/-Umgebung heruntergeladen wurden, führen zu einem Fehler.

Zielanfrageheader in Plug-ins festlegen

Es gibt zwei grundlegende Muster zu berücksichtigen, wenn Sie Zielanfrageheader hinzufügen oder ändern möchten: eines, bei dem die eingehende Anfrage Daten enthält (wie bei einer POST-Anfrage), und eines, bei dem dies nicht der Fall ist (wie bei einer einfachen GET-Anfrage).

Betrachten wir einen Fall, bei dem die eingehende Anfrage Daten enthält und Sie Anfrageheader für die Zielanfrage festlegen möchten. In früheren Versionen von Edge Microgateway war es in diesem Fall nicht möglich, Zielheader zuverlässig festzulegen.

Der Schlüssel zu diesem Muster besteht darin, zuerst alle eingehenden Daten vom Client zu akkumulieren. Verwenden Sie dann in der Funktion onend_request() die neue Funktion request.setOverrideHeader(name, value), um die Header anzupassen.

Der folgende Beispielcode zeigt, wie dies funktioniert. Die in onend_request festgelegten Header werden an das Ziel gesendet:

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);
    }

  };

}

Wenn die Anfrage keine Daten enthält, können Sie im onrequest()-Handler Zielheader festlegen. Dieses Muster ist nicht neu – es wurde zuvor dokumentiert und wurde in den mit Edge Microgateway bereitgestellten Beispiel-Plug-ins verwendet.

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

Funktion „Neu laden ohne Ausfallzeiten“

Nachdem Sie eine Konfigurationsänderung an Edge Microgateway vorgenommen haben, können Sie die Konfiguration laden, ohne Nachrichten zu löschen. Mit dieser Änderung wird Edge Microgateway immer im Clustermodus gestartet und die Option --cluster wurde aus dem Befehl edgemicro start entfernt.

Außerdem wurden drei neue CLI-Befehle hinzugefügt. Sie müssen diese Befehle in demselben Verzeichnis ausführen, in dem der Edgemicro-Startbefehl ausgeführt wurde:

• edgemicro status – Prüft, ob das Edge Microgateway ausgeführt wird oder nicht.
• edgemicro stop – Beendet den Edge Microgateway-Cluster.
• edgemicro reload – lädt die Edge Microgateway-Konfiguration ohne Ausfallzeit neu.

Automatisches Aktualisieren der Konfiguration ohne Ausfallzeiten

Edge Microgateway lädt regelmäßig eine neue Konfiguration und führt eine Aktualisierung aus, wenn sich etwas geändert hat. Das Polling erfasst alle in Edge vorgenommenen Änderungen (Änderungen an Produkten, Proxys, die auf Mikrogateways reagieren usw.) sowie an der lokalen Konfigurationsdatei. Das standardmäßige Abfrageintervall beträgt 600 Sekunden (5 Minuten). Sie können den Standardwert in der Microgateway-Konfigurationsdatei so ändern:

edgemicro:
    config_change_poll_interval: [seconds]

Versionsinformationen zur Befehlszeile hinzugefügt

Der Befehlszeile wurde das Flag --version hinzugefügt. Verwenden Sie Folgendes, um die aktuelle Version von Edge Microgateway abzurufen:

edgemicro --version

Neue SSL-Optionen für Edge Microgateway-Server

Edge Microgateway unterstützt jetzt zusätzlich zu key und cert die folgenden Server-SSL-Optionen:

Protokolldateien an stdout senden

Mit einer neuen Konfigurationseinstellung können Sie Logdaten an die Standardausgabe senden:

edgemicro:
  logging:
    to_console: true  

Weitere Informationen finden Sie unter Logdateien verwalten.

Version 2.1.2

Im Folgenden finden Sie die neuen Funktionen und Verbesserungen in dieser Version.

Benutzerdefinierten API-Endpunkt für die Konfiguration zulassen

Es gibt neue konfigurierbare Endpunkte für den Autorisierungs-Proxy, die die Verwendung eines benutzerdefinierten Authentifizierungsdienstes unterstützen. Diese Endpunkte sind:

• edgeconfig:verify_api_key_url
• edgeconfig:products

Weitere Informationen finden Sie unter Benutzerdefinierten Authentifizierungsdienst verwenden.

Version 2.1.1

Im Folgenden finden Sie die neuen Funktionen und Verbesserungen in dieser Version.

Plattformübergreifenden Auth-Proxy bereitstellen

Es wurde eine Verbesserung vorgenommen, damit der Befehl zum Bereitstellen des Edge Microgateway-Autorisierungs-Proxys für Edge auf Windows-Systemen kompatibel ist.

Version 2.1.0

Neue Funktionen und Verbesserungen, Version 21.0

Im Folgenden finden Sie die neuen Funktionen und Verbesserungen:

SSL/TLS-Optionen für Clients angeben

Mit neuen Konfigurationsoptionen können Sie Clientoptionen für SSL/TSL-Verbindungen zu Zielen festlegen. Weitere Informationen finden Sie unter SSL/TSL-Optionen von Clients verwenden.

Version 2.0.11

Installationshinweis v2.0.11

In einigen früheren Versionen von Edge Microgateway können Sie die Software durch Herunterladen einer ZIP-Datei installieren. Diese ZIP-Dateien werden nicht mehr unterstützt. Zum Installieren von Edge Microgateway müssen Sie Folgendes verwenden:

npm install -g edgemicro

Weitere Informationen finden Sie im Installationsthema.

Neue Funktionen und Verbesserungen v2.0.11

Im Folgenden finden Sie die neuen Funktionen und Verbesserungen:

Port beim Start angeben

Mit dem Startbefehl können Sie eine Portnummer angeben, um den in der Konfigurationsdatei angegebenen Port zu überschreiben. Sie können mithilfe der Umgebungsvariable PORT auch eine Portnummer angeben. Weitere Informationen finden Sie unter Startbefehl.

Optionale Authentifizierungsheader beibehalten

Mit der neuen Konfigurationseinstellung keepAuthHeader können Sie den in der Anfrage gesendeten Autorisierungsheader beibehalten. Wenn die Richtlinie auf „true“ gesetzt ist, wird der Auth-Header an das Ziel übergeben. Siehe OAuth-Attribute.

Möglichkeit, einen benutzerdefinierten Autorisierungsdienst zu verwenden

Wenn Sie Ihren eigenen benutzerdefinierten Dienst für die Authentifizierung verwenden möchten, ändern Sie den Wert authUri in der Edge Microgateway-Konfigurationsdatei so, dass er auf Ihren Dienst verweist. Weitere Informationen finden Sie unter Benutzerdefinierten Authentifizierungsdienst verwenden.

Version 2.0.4

Edge Microgateway v2.0.4 wurde am 25.Mai 2016 veröffentlicht.

Neue Funktionen und Verbesserungen in Version 2.0.4

Im Folgenden sind die neuen Funktionen und Verbesserungen in dieser Version aufgeführt.

Unterstützung für Ressourcenpfade in Produkten

Edge Microgateway unterstützt jetzt Ressourcenpfade in Produkten. Mit Ressourcenpfaden können Sie den Zugriff auf APIs anhand des Proxy-Pfadsuffixes einschränken. Weitere Informationen zum Erstellen von Produkten und zum Konfigurieren von Ressourcenpfaden finden Sie unter API-Produkte erstellen.

Unterstützung für globale npm-Installation

Sie können Edge Microgateway jetzt mit der Option „npm -g“ (global) installieren. Weitere Informationen zu dieser Option finden Sie in der npm-Dokumentation.

Version 2.0.0

Edge Microgateway v2.0.0 wurde am 18. April 2016 veröffentlicht.

Neue Funktionen und Verbesserungen in Version 2.0.0

Im Folgenden sind die neuen Funktionen und Verbesserungen in dieser Version aufgeführt.

Einzelner Prozessserver

Edge Microgateway ist jetzt ein einzelner Prozessserver. Es wird kein Zwei-Prozessmodell mehr verwendet, bei dem ein Prozess (früher als „Agent“ bezeichnet) den zweiten Prozess Edge Microgateway startet. Die neue Architektur erleichtert Automatisierung und Containerisierung.

Konfigurationsdateien mit Namespace

Konfigurationsdateien werden jetzt mithilfe von Organisation und Umgebung mit einem Namespace versehen, sodass mehrere Microgateway-Instanzen auf demselben Host ausgeführt werden können. Sie finden die Konfigurationsdateien unter ~/.edgemicro, nachdem Sie den Konfigurationsbefehl von Edge Microgateway ausgeführt haben.

Neue Umgebungsvariablen

Es gibt jetzt vier Umgebungsvariablen: EDGEMICRO_ORG, EDGEMICRO_ENV, EDGEMICRO_KEY und EDGEMICRO_SECRET. Wenn Sie diese Variablen in Ihrem System festlegen, müssen Sie ihre Werte nicht angeben, wenn Sie Edge Microgateway über die Befehlszeile konfigurieren und starten.

Cache-Konfiguration

Edge Microgateway verwendet eine im Cache gespeicherte Konfigurationsdatei, wenn es ohne Verbindung zu Apigee Edge neu gestartet wird.

Clustermodus

Es gibt jetzt Optionen zum Starten von Edge Microgateway im Clustermodus. Mit dem Clustermodus können Sie Mehrkernsysteme nutzen. Das Mikrogateway verwendet das Node.js-Clustermodul für diese Funktion. Weitere Informationen finden Sie in der Node.js-Dokumentation.

Fehlerkorrekturen in Version 2.0.0

Der Lebenszyklus von Plug-in-Ereignissen verarbeitet asynchronen Code, der Code mit einem neuen Callback enthält, jetzt korrekt.

Version 1.1.2

Edge Microgateway Version 1. 1.2 wurde am 14.März 2016 veröffentlicht.

Neue Funktionen und Verbesserungen v.1.1.2

Im Folgenden sind die neuen Funktionen und Verbesserungen in dieser Version aufgeführt.

Leistungssteigerung

Edge Microgateway verwendet den Node.js-HTTP-Agent jetzt korrekt, um das Verbindungs-Pooling zu verbessern. Diese Verbesserung verbessert die Leistung und die Gesamtstabilität bei hoher Last.

Unterstützung für Remote-Debugger

Sie können Edge Microgateway so konfigurieren, dass es mit einem Remote-Debugger wie node-Inspector ausgeführt wird.

Speicherort der neuen Konfigurationsdatei

Wenn Sie Edge Microgateway konfigurieren, wird die Datei agent/config/default.yaml jetzt nach ~./edgemicro/config.yaml kopiert.

Protokolldateirotation

Mit einem neuen Konfigurationsattribut können Sie ein Rotationsintervall für Edge Microgateway-Logs angeben.

Fehlerkorrekturen in v1.1.2

Die folgenden Fehler wurden in Version 1.1.2 behoben.