Notas de lançamento do Edge Microgateway

Você está lendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. info

Versão 3.3.x

Correções de bugs e melhorias v.3.3.x

3.3.7

Em 17 de julho de 2025, lançamos as seguintes correções e melhorias no Edge Microgateway.

Correções de bugs e melhorias:

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

Problemas de segurança corrigidos

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

3.3.6

Em 16 de abril de 2025, lançamos as seguintes correções e melhorias no Edge Microgateway.

Versões dos componentes:

A tabela a seguir lista os números de versão dos projetos de componentes individuais associados ao Edge Microgateway 3.3.6. Como cada componente é um projeto separado, os números de lançamento podem não corresponder à versão principal do produto:

Problemas de segurança corrigidos

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

3.3.5

Na sexta-feira, 20 de dezembro de 2024, lançamos as seguintes correções e melhorias no Edge Microgateway.

Versões dos componentes:

A tabela a seguir lista os números de versão dos projetos de componentes individuais associados ao Edge Microgateway 3.3.5. Como cada componente é um projeto separado, os números de lançamento podem não corresponder à versão principal do produto:

Correções de bugs e melhorias:

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

You are using a version of NodeJS that is not supported

Problemas de segurança corrigidos

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

3.3.4

Em 18 de setembro de 2024, lançamos as seguintes correções e melhorias no Edge Microgateway.

Versões dos componentes:

A tabela a seguir lista os números de versão dos projetos de componentes individuais associados ao Edge Microgateway 3.3.4. Como cada componente é um projeto separado, os números de lançamento podem não corresponder à versão principal do produto:

Correções de bugs e melhorias:

Problemas de segurança corrigidos

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

3.3.3

Em 25 de abril de 2024, lançamos as seguintes correções e melhorias no Edge Microgateway.

Versões dos componentes:

A tabela a seguir lista os números de versão dos projetos de componentes individuais associados ao Edge Microgateway 3.3.3. Como cada componente é um projeto separado, os números de lançamento podem não corresponder à versão principal do produto:

Correções de bugs e melhorias:

Problemas de segurança corrigidos

• 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

Em 18 de agosto de 2023, lançamos as seguintes correções e melhorias no Edge Microgateway.

Versões dos componentes:

A tabela a seguir lista os números de versão dos projetos de componentes individuais associados ao Edge Microgateway 3.3.2. Como cada componente é um projeto separado, os números de lançamento podem não corresponder à versão principal do produto:

Correções de bugs e melhorias:

Problemas de segurança corrigidos

Nenhum.

3.3.1

Em 7 de junho de 2022, lançamos as seguintes correções e melhorias no Edge Microgateway.

Versões dos componentes:

A tabela a seguir lista os números de versão dos projetos de componentes individuais associados ao Edge Microgateway 3.3.1. Como cada componente é um projeto separado, os números de lançamento podem não corresponder à versão principal do produto:

Correções de bugs e melhorias:

Problemas de segurança corrigidos

3.3.0

Em 4 de fevereiro de 2022, lançamos as seguintes correções e melhorias no Edge Microgateway.

Versões dos componentes:

A tabela a seguir lista os números de versão dos projetos de componentes individuais associados ao Edge Microgateway 3.3.0. Como cada componente é um projeto separado, os números de lançamento podem não corresponder à versão principal do produto:

Correções de bugs e melhorias:

npm install apigeetool@0.15.1

Versão 3.2.x

Correções de bugs e melhorias v.3.2.x

3.2.3

Em 17 de setembro de 2021, lançamos as seguintes correções e melhorias no Edge Microgateway.

Versões dos componentes:

A tabela a seguir lista os números de versão dos projetos de componentes individuais associados ao Edge Microgateway 3.2.3. Como cada componente é um projeto separado, os números de lançamento podem não corresponder à versão principal do produto:

Correções de bugs e melhorias:

Problemas de segurança corrigidos

3.2.2

Em 15 de julho de 2021, lançamos as seguintes correções e melhorias no Edge Microgateway.

Versões dos componentes:

A tabela a seguir lista os números de versão dos projetos de componentes individuais associados ao Edge Microgateway 3.2.2. Como cada componente é um projeto separado, os números de lançamento podem não corresponder à versão principal do produto:

Correções de bugs e melhorias:

Problemas de segurança corrigidos

3.2.1

Na sexta-feira, 5 de março de 2021, lançamos as seguintes correções e melhorias no Edge Microgateway.

Versões dos componentes:

A tabela a seguir lista os números de versão dos projetos de componentes individuais associados ao Edge Microgateway 3.2.1. Como cada componente é um projeto separado, os números de lançamento podem não corresponder à versão principal do produto:

Correções de bugs e melhorias:

edgemicro:
 enable_GET_req_body: true

3.2.0

Na quinta-feira, 21 de janeiro de 2021, lançamos as seguintes correções e melhorias no Edge Microgateway.

Versões dos componentes:

A tabela a seguir lista os números de versão dos projetos de componentes individuais associados ao Edge Microgateway 3.2.0. Como cada componente é um projeto separado, os números de lançamento podem não corresponder à versão principal do produto:

Correções de bugs e melhorias:

Versão 3.1.x

Correções de bugs e melhorias v.3.1.x

3.1.8

Na segunda-feira, 16 de novembro de 2020, lançamos as seguintes correções e melhorias no Edge Microgateway.

Versões dos componentes:

A tabela a seguir lista os números de versão dos projetos de componentes individuais associados ao Edge Microgateway 3.1.8. Como cada componente é um projeto separado, os números de lançamento podem não corresponder à versão principal do produto:

Correções de bugs e melhorias:

3.1.7

Na quinta-feira, 24 de setembro de 2020, lançamos as seguintes correções e melhorias no Edge Microgateway.

Versões dos componentes:

A tabela a seguir lista os números de versão dos projetos de componentes individuais associados ao Edge Microgateway 3.1.7. Como cada componente é um projeto separado, os números de lançamento podem não corresponder à versão principal do produto:

Correções de bugs e melhorias:

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

3.1.6

Na quinta-feira, 20 de agosto de 2020, lançamos as seguintes correções e melhorias no Edge Microgateway.

Versões dos componentes:

A tabela a seguir lista os números de versão dos projetos de componentes individuais associados ao Edge Microgateway 3.1.6. Como cada componente é um projeto separado, os números de lançamento podem não corresponder à versão principal do produto:

Correções de bugs e melhorias:

3.1.5

Na sexta-feira, 26 de junho de 2020, lançamos as seguintes correções e melhorias no Edge Microgateway.

Versões dos componentes:

A tabela a seguir lista os números de versão dos projetos de componentes individuais associados ao Edge Microgateway 3.1.5. Como cada componente é um projeto separado, os números de lançamento podem não corresponder à versão principal do produto:

Correções de bugs e melhorias:

3.1.4

Na sexta-feira, 23 de abril de 2020, lançamos a seguinte correção para o Edge Microgateway.

Correção de bug:

Um problema de dependência na versão 3.1.3 foi corrigido. A versão 3.1.3 foi marcada como descontinuada no repositório npm. Caso contrário, todas as correções de bugs e melhorias descritas na nota da versão 3.1.3 se aplicam a esta versão.

3.1.3

Na quarta-feira, 15 de abril de 2020, lançamos as seguintes correções e melhorias no Edge Microgateway.

Versões dos componentes:

A tabela a seguir lista os números de versão dos projetos de componentes individuais associados ao Edge Microgateway 3.1.3. Como cada componente é um projeto separado, os números de lançamento podem não corresponder à versão principal do produto:

Correções de bugs e melhorias:

• 153509313: correção de um problema em que o módulo de depuração do Node.js resultava em vazamentos de memória. O problema existe nas versões v3.1.0, v3.1.1 e 3.1.2.
• 153509313: correção de um problema em que o mesmo ID de mensagem para duas transações diferentes era impresso na saída de registro.
• 151673570: foi corrigido um problema em que o Edge Microgateway não era atualizado para usar as novas APIs KVM da Apigee. O Edge Microgateway agora usa os novos comandos para adicionar e atualizar os valores de KVM.
• 152822846: em versões anteriores, o Edge Microgateway foi atualizado para que o processamento do mapeamento de caminhos de recursos corresponda ao do Apigee Edge. Nesta versão, corrigimos um problema em que o padrão /literal_string/* não era processado corretamente. Por exemplo, /*/2/*. Consulte também Como configurar o comportamento de um caminho de recurso "/", "/*" e "/**".
• 152005003 - Mudanças foram feitas para ativar identificadores no escopo da organização e do ambiente para cotas.
• 152005003 - Mudanças foram feitas para ativar identificadores no escopo da organização e do ambiente para cotas. A combinação de "org + env + appName + productName" é usada como o identificador de cota.

3.1.2

Na segunda-feira, 16 de março de 2020, lançamos as seguintes correções e melhorias no Edge Microgateway.

Versões dos componentes:

A tabela a seguir lista os números de versão dos projetos de componentes individuais associados ao Edge Microgateway 3.1.3. Como cada componente é um projeto separado, os números de lançamento podem não corresponder à versão principal do produto:

Correções de bugs e melhorias:

• 151285018: foi feita uma melhoria de recurso para adicionar suporte a proxy HTTP para tráfego entre o Edge Microgateway e destinos de back-end. Além disso, foram corrigidos problemas com o suporte a proxy HTTP entre o Edge Microgateway e o Apigee Edge. Para mais detalhes, consulte:
  • Usar um proxy HTTP para comunicação com o Apigee Edge
  • Usar um proxy HTTP para comunicação de destino
• 149101890: o código de notificação de registro para casos em que o servidor de destino ou o balanceador de carga fecha a conexão foi alterado de ERROR para INFO.
• 150746985: foi corrigido um problema em que o comando edgemicro verify não funcionava corretamente se redisBasedConfigCache: true ou quotaUri: https://%s-%s.apigee.net/edgemicro-auth estivessem presentes no arquivo de configuração.
• 151284716: foi feita uma melhoria para fechar as conexões do servidor mais rapidamente quando os workers são reiniciados durante uma recarga.
• 151588764: atualize a versão do Node.js na imagem do Docker usada para executar o Edge Microgateway em um contêiner do Docker para a versão 12, porque o Node.js v8 está descontinuado.
• 151306049: uma atualização na documentação foi feita para listar as APIs de gerenciamento do Apigee Edge usadas pelos comandos da CLI do Edge Microgateway. Consulte Quais APIs de gerenciamento o Edge Microgateway usa?.

3.1.1

Na quinta-feira, 20 de fevereiro, lançamos as seguintes correções e melhorias no Edge Microgateway.

Versões dos componentes:

A tabela a seguir lista os números de versão dos projetos de componentes individuais associados ao Edge Microgateway 3.1.1. Como cada componente é um projeto separado, os números de lançamento podem não corresponder à versão principal do produto:

Correções de bugs e melhorias:

• 146069701: foi corrigido um problema em que o módulo microgateway-core não respeitava as variáveis de ambiente HTTP_PROXY e HTTPS_PROXY. Com essa mudança, as configurações de proxy no arquivo de configuração YAML, se especificadas, agora são ignoradas. Somente as variáveis de ambiente são usadas para especificar o proxy.

  Se você quiser especificar a configuração de proxy no arquivo de configuração, também será necessário especificar uma variável HTTP_PROXY que mencione o mesmo URL de proxy especificado no arquivo de configuração. Por exemplo, se você especificar a seguinte configuração:

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

  Você também precisa especificar esta variável de ambiente:

  HTTP_PROXY=http://10.128.0.20:3128

• 146320620: um novo parâmetro de configuração, edgemicro.headers_timeout, foi adicionado. Esse atributo limita a quantidade de tempo (em milissegundos) que o analisador HTTP aguardará para receber os cabeçalhos HTTP completos. Exemplo:

  edgemicro:
  keep_alive_timeout: 6000
  headers_timeout: 12000

  Internamente, o parâmetro define o atributo Server.headersTimeout do Node.js nas solicitações. O padrão é 5 segundos a mais do que o tempo definido com edgemicro.keep_alive_timeout. Essa configuração padrão impede que balanceadores de carga ou proxies descartem a conexão por engano.

• 149278885: um novo recurso foi adicionado para permitir que você defina o tempo limite da API de destino no nível do proxy de API em vez de usar uma configuração de tempo limite global.

  Se você definir a propriedade TargetEndpoint io.timeout.millis no proxy de API, o Edge Microgateway poderá recuperar essa propriedade e aplicar tempos limite específicos do endpoint de destino. Se esse parâmetro não for aplicado, o Edge Microgateway usará o tempo limite global especificado com edgemicro.request_timeout.

3.1.0

Na terça-feira, 21 de janeiro, lançamos as seguintes correções e melhorias no Edge Microgateway.

Versões dos componentes:

A tabela a seguir lista os números de versão dos projetos de componentes individuais associados ao Edge Microgateway 3.1.0. Como cada componente é um projeto separado, os números de lançamento podem não corresponder à versão principal do produto:

Correções de bugs e melhorias:

• 144187500: um novo evento de nível WARN será registrado quando a flag quotas.failOpen for acionada. Essa flag é acionada se ocorrer um erro no processamento da cota ou se a solicitação "aplicar cota" ao Edge não atualizar os contadores de cota remotos. Nesse caso, a cota será processada com base apenas nas contagens locais até a próxima sincronização remota bem-sucedida. Antes, esse evento só era registrado quando o nível de registro era definido como DEBUG.

  Exemplo:

  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: foi corrigido um problema em que transações em andamento ou novas eram afetadas sempre que o Edge Microgateway detectava uma mudança em um proxy de API. Agora, quando uma mudança é feita em um proxy, o Edge Microgateway atualiza o cache e os nós de trabalho são reiniciados. Com essa mudança, as transações em andamento e as novas chamadas de API enviadas ao microrrecurso não serão afetadas.
• 146378327: o nível de registro de sourceRequest, targetRequest e targetResponse foi alterado para INFO.
• 146019878: foi corrigida uma discrepância entre a latência calculada para "Performance do proxy de API" na análise do Edge e os eventos de registro sourceResponse/targetResponse do Edge Microgateway. Agora, a latência nos eventos de registro do Microgateway e da análise do Edge está alinhada.
• Mudanças relacionadas à lógica de correspondência de padrões:
  • 147027862: o plug-in oauth foi atualizado para oferecer suporte aos seguintes padrões de correspondência de caminho de recurso, conforme especificado em produtos de API:
    • /{literal}**
    • /{literal}*
    • Qualquer combinação dos dois padrões acima

    Com essa mudança, o plug-in do Edge Microgateway agora segue a mesma correspondência de padrões do Apigee Edge, conforme explicado em Configurar o comportamento de um caminho de recurso de '/', '/*' e '/**'.

  • 145644205: atualiza a lógica de correspondência de padrões do plug-in apiKeys para corresponder ao plug-in oauth.
• 143488312: foi corrigido um problema em que espaços à esquerda ou à direita no parâmetro de ID do cliente faziam com que a criação da lista de produtos JWT ficasse vazia para solicitações de token OAuth e chave de API.
• 145640807 e 147579179: um novo recurso foi adicionado para permitir que uma instância especial do Edge Microgateway, chamada de "sincronizador", recupere dados de configuração do Apigee Edge e os grave em um banco de dados Redis local. Outras instâncias do microrreceptáculo podem ser configuradas para ler os dados de configuração do banco de dados. Esse recurso adiciona um nível de capacidade de recuperação ao Edge Microgateway. Ele permite que as instâncias do microgateway sejam iniciadas e funcionem sem precisar se comunicar com o Apigee Edge. Para mais detalhes, consulte Usar o sincronizador.

  No momento, o recurso de sincronização é compatível com o Redis 5.0.x.

Versão 3.0.x

Correções de bugs e melhorias v.3.0.x

3.0.10

Na sexta-feira, 8 de novembro, lançamos as seguintes correções e melhorias no Edge Microgateway.

Versões dos componentes:

A tabela a seguir lista os números de versão dos projetos de componentes individuais associados ao Edge Microgateway 3.0.10. Como cada componente é um projeto separado, os números de lançamento podem não corresponder à versão principal do produto:

Correções de bugs e melhorias:

• 142677575: uma atualização de recurso foi feita para que a correspondência de padrões para caminhos de recursos usados em produtos de API para o Edge Microgateway agora se alinhe com a correspondência de padrões de caminhos de recursos usada pelo Apigee Edge, conforme descrito em Configurar o comportamento de um caminho de recurso de '/', '/*' e '/**'.

  Observação: se você usar um padrão de recurso composto como /*/2/**, verifique se o proxy edgemicro_auth foi adicionado a um produto de API independente. Em seguida, inclua esse produto no app do desenvolvedor do proxy, conforme ilustrado na captura de tela a seguir:

  

  Observação: a propriedade de configuração features.isSingleForwardSlashBlockingEnabled, conforme descrito em Configurar o comportamento de um caminho de recurso de '/', '/*' e '/**', não é compatível com o Edge Microgateway.

• 143740696: a estrutura de configuração quotas mudou. Consulte também as notas da versão 3.0.9. A propriedade quotas é usada para configurar o plug-in de cota. A mudança na estrutura foi feita para melhorar a clareza dos elementos de configuração. Para configurar o plug-in de cota, use a seguinte configuração YAML. A propriedade de configuração é chamada de quotas. Para detalhes sobre as propriedades de configuração individuais do quotas, consulte Opções de configuração para cota.

  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: um novo recurso foi adicionado para permitir o uso do Redis como o armazenamento de apoio de cota. Se useRedis for verdadeiro, o módulo volos-quota-redis será usado. Quando verdadeiro, a cota é restrita apenas às instâncias do Edge Microgateway que se conectam ao Redis. Se for "false", o módulo volos-quota-apigee será usado como o armazenamento de apoio, e o contador de cota será global. Para mais detalhes, consulte Opções de configuração de cota. Exemplo:

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

• 140574210: o prazo de validade padrão dos tokens gerados pelo proxy edgemicro-auth foi alterado de 108.000 milissegundos (1,8 minuto) para 1.800 segundos (30 minutos).
• 143551282: para oferecer suporte a organizações ativadas para SAML, o comando edgemicro genkeys foi atualizado para incluir um parâmetro ‑‑token. Com ele, é possível usar um token OAuth para autenticação em vez de nome de usuário/senha. Para mais detalhes, consulte Como gerar chaves.

3.0.9

Na sexta-feira, 11 de outubro, lançamos as seguintes correções e melhorias no Edge Microgateway.

Versões dos componentes:

A tabela a seguir lista os números de versão dos projetos de componentes individuais associados ao Edge Microgateway 3.0.9. Como cada componente é um projeto separado, os números de lançamento podem não corresponder à versão principal do produto:

Correções de bugs e melhorias:

• 141989374: um novo recurso de "abertura em caso de falha" foi adicionado ao plug-in de cota. Quando esse recurso está ativado, se ocorrer um erro de processamento de cota ou se a solicitação "aplicar cota" ao Edge não atualizar os contadores de cota remota, a cota será processada com base apenas nas contagens locais até a próxima sincronização remota de cota. Em ambos os casos, uma flag quota-failed-open é definida no objeto de solicitação.

  Para ativar o recurso de cota "abrir em caso de falha", defina a seguinte configuração:

  quotas :
   failOpen : true

  Observação: além disso, o nome da flag do objeto de solicitação fail-open do plug-in OAuth foi mudado para oauth-failed-open.

• 142093764 - Uma mudança de configuração foi feita no proxy edgemicro-auth para evitar estouros de cota. A mudança é definir o tipo de cota como calendar. Para usar essa melhoria, atualize seu edgemicro-auth para a versão 3.0.7 ou mais recente.
• 142520568: um novo recurso foi adicionado para ativar o registro do ID do MP (processador de mensagens) em respostas de cota. Para usar esse recurso, atualize seu proxy edgemicro-auth para a versão 3.0.7 ou mais recente e defina a seguinte configuração:

  quotas:
    useDebugMpId: true

  Quando useDebugMpId é definido, as respostas de cota do Edge contêm o ID do MP e são registradas pelo Edge Microgateway. Exemplo:

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

3.0.8

Na quinta-feira, 26 de setembro, lançamos as seguintes correções e melhorias no Edge Microgateway.

Versões dos componentes:

A tabela a seguir lista os números de versão dos projetos de componentes individuais associados ao Edge Microgateway 3.0.8. Como cada componente é um projeto separado, os números de lançamento podem não corresponder à versão principal do produto:

Correções de bugs e melhorias:

• 140025210: um novo recurso de "abertura em caso de falha" foi adicionado. Esse recurso permite que o processamento da API continue se um token JWT expirado não puder ser atualizado devido a um erro de conexão que impede uma chamada de verificação de chave de API bem-sucedida para o proxy edgemicro-auth.

  Com esse recurso, é possível definir um período de carência em que o token antigo permanece no cache e é reutilizado até o fim desse período. O recurso permite que o Edge Microgateway continue processando solicitações em caso de falha temporária de conexão. Quando a conectividade é retomada e uma chamada bem-sucedida da API Verify é feita, um novo JWT é buscado e substitui o antigo no cache.

  Para configurar o novo recurso "abrir em caso de falha", faça o seguinte:

  1. Defina as seguintes propriedades na seção oauth do arquivo de configuração do Edge Microgateway:

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

     Exemplo:

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

     Neste exemplo, o token antigo será usado por cinco segundos se não puder ser atualizado devido a um problema de conectividade. Após 5 segundos, um erro de autenticação será retornado.

• 141168968: uma atualização foi feita para incluir o correlation_id em toda a saída de registro do plug-in. Além disso, os níveis de alguns registros foram alterados para error conforme necessário.
• 140193349: uma atualização foi feita no proxy edgemicro-auth para exigir que a chave e o segredo do Edge Microgateway sejam verificados em todas as solicitações de verificação da chave de API. O Edge Microgateway foi atualizado para sempre enviar a chave e o segredo em todas as solicitações de verificação de chave de API. Essa mudança impede que os clientes recebam um JWT apenas com uma chave de API.
• 140090250: uma atualização foi feita para adicionar registros de diagnóstico ao processamento de cota. Com essa mudança, agora é possível correlacionar a saída do registro de cota com o restante dos registros do Edge Microgateway.

3.0.7

Na quinta-feira, 12 de setembro, lançamos as seguintes correções e melhorias no Edge Microgateway.

Versões dos componentes:

A tabela a seguir lista os números de versão dos projetos de componentes individuais associados ao Edge Microgateway 3.0.7. Como cada componente é um projeto separado, os números de lançamento podem não corresponder à versão principal do produto:

Correções de bugs e melhorias:

• 140075602: uma atualização foi feita no plug-in OAuth para retornar um código de status 5xx quando apropriado. Antes, o plug-in retornava apenas códigos de status 4xx em todos os casos diferentes de 200. Agora, para qualquer resposta de mensagem que não seja um status 200, o código 4xx ou 5xx exato será retornado, dependendo do erro.

  Esse recurso fica desativado por padrão. Para ativar esse recurso, adicione a propriedade oauth.useUpstreamResponse: true à configuração do Edge Microgateway. Exemplo:

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

• 140090623: na versão 3.0.6, uma nova propriedade de configuração foi adicionada, quota.quotaUri. Defina essa propriedade de configuração se quiser gerenciar cotas pelo proxy edgemicro-auth implantado na sua organização. Se essa propriedade não for definida, o endpoint de cota será definido como o endpoint interno do Edge Microgateway. Exemplo:

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

  Na versão 3.0.7, o edgemicro-auth foi atualizado para aceitar essa nova configuração. Para usar a propriedade quotaUri, faça upgrade para o proxy edgemicro-auth mais recente. Para mais detalhes, consulte Como fazer upgrade do proxy edgemicro-auth.

• 140470888: um cabeçalho de autorização foi adicionado às chamadas de cota para fornecer autenticação. Além disso, o proxy edgemicro-auth foi modificado para remover "organization" do identificador de cota. Como o endpoint de cota reside na organização do cliente, o identificador de cota não é mais necessário.
• 140823165: o seguinte nome de propriedade:

  edgemicro:
      keepAliveTimeout

  foi documentado incorretamente na versão 3.0.6. O nome correto da propriedade é:

  edgemicro:
      keep_alive_timeout

• 139526406 - Correção de um bug em que uma contagem de cota incorreta ocorria se um app de desenvolvedor tivesse vários produtos. A cota agora é aplicada corretamente a cada produto em um app que tem vários produtos. A combinação de "appName + productName" é usada como o identificador de cota.

3.0.6

Na quinta-feira, 29 de agosto, lançamos as seguintes correções e melhorias no Edge Microgateway.

• 138633700: adicionamos uma nova propriedade de configuração, keepAliveTimeout. Essa propriedade permite definir o tempo limite do Edge Microgateway (em milissegundos). (Padrão: 5.000 milissegundos)

  Exemplo:

  edgemicro:
    keep_alive_timeout: 600

• 140090623: adicionamos uma nova propriedade de configuração, quotaUri. Defina essa propriedade de configuração se quiser gerenciar cotas pelo proxy edgemicro-auth implantado na sua organização. Se essa propriedade não estiver definida, o endpoint de cota será o endpoint interno do Edge Microgateway por padrão. Exemplo:

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

  Para usar esse recurso, primeiro implante a versão mais recente do proxy edgemicro-auth na sua organização. Para mais detalhes, consulte Como fazer upgrade do proxy edgemicro-auth.

• 138722809: adicionamos uma nova propriedade de configuração, stack_trace. Essa propriedade permite controlar se os rastreamentos de pilha aparecem ou não nos arquivos de registro. Exemplo:

  stack_trace: false

  Se stack_trace estiver definido como true, o rastreamento de pilha será impresso nos registros. Se for definido como false, o rastreamento de pilha não será impresso nos registros.

3.0.5

Na quinta-feira, 15 de agosto, lançamos as seguintes correções e melhorias no Edge Microgateway.

• 139005279: foi corrigido um problema em que o comando edgemicro status não retornava o número correto de processos de worker.
• 138437710: foi corrigido um problema na classe ExitCounter que impedia a gravação do registro adequado.

• 139064652: adicionamos a capacidade de incluir níveis de geração de registros trace e debug para eventos e registros do sistema. Por enquanto, apenas a capacidade de adicionar esses níveis de registro foi incluída. No momento, os níveis de registro disponíveis são info, warn e error.
• 139064616: a saída de registro foi padronizada para todas as instruções de registro do console. As instruções de registro do console agora incluem estes atributos:
• Carimbo de data/hora
• Nome do componente
• ID do processo
• Mensagem de registro do console

• 138413755: melhora as mensagens de registro relacionadas a chaves e secrets JWT para estes comandos da CLI: cert, verify, upgradekvm, token, genkeys, revokekeys, rotatekey e configure.

• 138413577: adiciona e melhora o tratamento de erros para tempos limite do serviço de back-end.
• 138413303: adiciona e melhora o tratamento de erros para tempos limite de resposta e de soquete.
• 138414116: adiciona e melhora o tratamento de erros de "conexão recusada".

3.0.4

Na quinta-feira, 1º de agosto, lançamos as seguintes correções e melhorias no Edge Microgateway.

• 134445926: melhorias na autenticação interna do Edge Microgateway.
• 137582169: correção de um problema em que processos indesejados eram iniciados. Os processos extras fizeram com que os plug-ins fossem recarregados e usassem memória em excesso. O Edge Microgateway agora mantém o número de processos dentro do limite esperado.
• 137768774 - Melhorias nas mensagens de registro:
  • Registros de transação (solicitação) limpos.
  • Adicionamos mais mensagens de registro quando necessário.
  • Mensagens de registro de transações (solicitações) movidas da saída do console para o arquivo de registro relevante.
  • Atualização dos registros do console para usar uma função de geração de registros centralizada.
• 138321133, 138320563: mudança interna fundamental no buffer de cota para permitir melhorias futuras na cota.

3.0.3

Na terça-feira, 23 de julho, lançamos as seguintes correções e melhorias no Edge Microgateway.

• Melhorias no registro: os registros de ambiente de execução atuais usam uma nova função eventLog() que captura e registra dados de ambiente de execução em um formato consistente. As informações de registro incluem:
  • Carimbo de data/hora (ISO 8601: AAAA-MM-DDTHH:mm:ss.sssZ).
  • Nível de registro (erro, aviso ou informação).
  • Nome do host: o nome do host solicitante do cabeçalho da solicitação.
  • ID do processo: se você estiver executando um cluster de processos do Node.js, esse será o ID do processo em que o registro em log ocorreu.
  • Nome da organização da Apigee.
  • Nome do ambiente na organização.
  • Nome do proxy de API.
  • Endereço IP do cliente.
  • ClientId.
  • ID de correlação (ainda não definido).
  • Nome do componente do Edge Microgateway.
  • Mensagem personalizada: alguns objetos podem imprimir informações adicionais transmitidas a essa propriedade de erro.
  • Método de solicitação (se for uma solicitação HTTP).
  • Código de status da resposta (se for uma solicitação HTTP).
  • Mensagem de erro.
  • Código de erro: se um objeto incluir um código de erro, ele será impresso nessa propriedade.
  • Tempo gasto.
  • Marcador de fim de linha do sistema operacional.

  Valores de propriedade nulos resultam em colchetes vazios, [].

  O exemplo a seguir mostra o formato do registro:

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

  (137770055)

• Performance: os produtos da API não estavam sendo filtrados com base no ambiente. Esse problema foi corrigido. (135038879)
• Várias integrações de testes funcionais e melhorias na qualidade do código.

3.0.2

Na quarta-feira, 3 de julho de 2019, lançamos as seguintes correções e melhorias no Edge Microgateway.

Qualidade do código: o código foi revisado para garantir a qualidade, e as mudanças foram feitas para atender aos padrões solicitados pelos usuários. Corrigimos erros e avisos de qualidade do código derivados do JSHint. Como resultado, alguns erros de código reais foram identificados e corrigidos. Todos os módulos do Apigee Edge Microgateway passaram por esse processo. Consulte os commits de 28 de junho e 2 de julho para microgateway-config, microgateway-core, microgateway-plugins e microgateway. Todos os módulos com mudanças na qualidade do código foram testados com ferramentas internas que verificam a execução do Edge Microgateway para casos de uso do cliente.

3.0.1

Na sexta-feira, 21 de junho de 2019, lançamos as seguintes correções e melhorias no Edge Microgateway.

• 134834551: mude as versões compatíveis do Node.js para o Edge Microgateway
  (versões compatíveis do Node.js: 8 e 12; as versões 7, 9 e 11 são experimentais)
• 134751883: o Edge Microgateway falha ao recarregar sob carga
• 134518428 - O endpoint "Products" do Edge Microgateway retorna 5XX se o padrão de filtro estiver incorreto
• 135113408: os workers precisam ser reiniciados se forem encerrados inesperadamente
• 134945852: tokenCacheSize não é usado no plug-in do OAuth
• 134947757: definir cacheTTL no plug-in OAuth
• 135445171: o cálculo de gracePeriod no OAuth não está correto
• Usar o módulo memored fornecido com a instalação do Edge Microgateway
• 135367906: Auditoria de segurança

Versão 2.5.x

Novos recursos e melhorias v.2.5.x

(corrigido na versão 2.5.38, 06/07/2019)

JWTs formatados incorretamente podem causar falhas nos workers ao usar o cache de token. Corrigido no módulo microgateway-plugins do Edge. (b/134672029)

(Adicionado 2.5.37) Adicione a opção da CLI edgemicro-cert -t.

A opção edgemicro cert -t permite especificar um token OAuth para autenticar APIs de gerenciamento. Consulte também Gerenciar certificados.

(Adicionado 2.5.35) Adicione suporte para depurar o Edge Microgateway usando edgemicroctl.

Use a flag mgdebug com edgemicroctl. Consulte também Tarefas de integração do Kubernetes.

(Adicionado na versão 2.5.35) Ative um build do Windows para edgemicroctl.

(Adicionado na versão 2.5.31) Nova API edgemicro-auth/token

Uma nova API edgemicro-auth/token foi adicionada para permitir que você transmita o cliente/secret como um cabeçalho de autorização básica codificado em Base64 e o grant_type como um parâmetro de formulário. Consulte Como receber tokens de portador diretamente.

(Corrigido na versão 2.5.31) A configuração particular não respeita a flag de token

Foi corrigido um problema em que a configuração do Edge Microgateway para usar um token de acesso OAuth2 no Edge para Private Cloud não funcionava corretamente (o token não era respeitado).

Docker: suporte ao uso de certificados autoassinados

(Adicionado em 2.5.29) Se você estiver usando uma autoridade de certificação (CA) que não seja confiável por padrão pelo Node.js, use o parâmetro NODE_EXTRA_CA_CERTS ao executar um contêiner do Docker com o Edge Microgateway. Para mais detalhes, consulte Usar uma CA que não é confiável para o Node.js.

Docker: suporte para TLS

(Adicionado na versão 2.5.29) O Edge Microgateway em execução em um contêiner do Docker agora oferece suporte a TLS para solicitações de entrada ao servidor do Edge Microgateway (solicitações de entrada) e para solicitações de saída do Edge Microgateway a um aplicativo de destino (solicitações de saída).

Os exemplos a seguir explicam em detalhes como configurar essas configurações de TLS:

• Exemplo de configuração de TLS de saída
• Exemplo de configuração de TLS de saída

Nesses exemplos, você vai aprender a usar o ponto de montagem do contêiner /opt/apigee/.edgemicro para carregar os certificados, que são referenciados no arquivo de configuração do Edge Microgateway.

Docker: suporte ao proxy de solicitação

(Adicionado na versão 2.5.27) Se você executar o Edge Microgateway em um contêiner do Docker, poderá usar estas opções para controlar o comportamento do proxy quando o microgateway estiver sendo executado atrás de um firewall:

• HTTP_PROXY
• HTTPS_PROXY
• NO_PROXY

Para detalhes, consulte Executar o Edge Micro como um contêiner do Docker.

Docker: instruções atualizadas do plug-in

(Adicionado na versão 2.5.27) Se você executar o Edge Microgateway em um contêiner do Docker, agora terá duas opções para implantar plug-ins. Uma opção, usando um ponto de montagem do Docker, é nova. A outra opção já existia e basicamente não mudou. No entanto, o Dockerfile foi atualizado. Para mais detalhes, consulte os links a seguir:

• Opção A: ativar o diretório de plug-ins em um volume (novo)
• Opção B: criar os plug-ins no contêiner (atualizada)

Novo suporte a token OAuth para o comando de upgrade do KVM

(Adicionado na versão 2.5.27) É possível usar um token OAuth com o comando upgradekvm. Para mais detalhes, consulte Fazer upgrade do KVM.

Separação de APIs no Edge Analytics

(Adicionado na versão 2.5.26) Novas flags de plug-in de análise permitem separar um caminho de API específico para que ele apareça como um proxy separado nos painéis do Edge Analytics. Por exemplo, é possível separar as APIs de verificação de integridade para evitar confundi-las com chamadas de API reais. Para mais informações, consulte Excluir caminhos da análise.

Configurar um proxy local

(Adicionado em 2.5.25) Com um proxy local, não é necessário criar manualmente um proxy compatível com microgateway no Apigee Edge. Em vez disso, o microgateway vai usar o caminho base do proxy local. Para mais informações, consulte Como usar o modo de proxy local.

Como usar o modo independente

(Adicionado na versão 2.5.25) É possível executar o Edge Microgateway completamente desconectado de qualquer dependência do Apigee Edge. Esse cenário, chamado de modo independente, permite executar e testar o Edge Microgateway sem uma conexão de Internet. Consulte Executar o Edge Microgateway no modo independente.

Revogação de chaves

(Adicionado na versão 2.5.19) Um novo comando da CLI foi adicionado para revogar as credenciais de chave e secret de uma configuração do Edge Microgateway.

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

Suporte ao Docker

(Adicionado na versão 2.5.19) Agora é possível fazer o download da versão mais recente do Edge Microgateway como uma imagem do Docker:

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

Suporte do Kubernetes

(Adicionado em 2.5.19) É possível implantar o Edge Microgateway como um serviço ou como um gateway secundário na frente de serviços implantados em um cluster do Kubernetes. Consulte: Visão geral da integração do Edge Microgateway com o Kubernetes.

Suporte para a opção TCP nodelay

(Adicionado na versão 2.5.16) Uma nova configuração, nodelay, foi adicionada à configuração do Edge Micro.

Por padrão, as conexões TCP usam o algoritmo de Nagle para armazenar dados em buffer antes de enviá-los. Definir nodelay como true desativa esse comportamento. Os dados são disparados imediatamente sempre que socket.write() é chamado. Consulte também a documentação do Node.js para mais detalhes.

Para ativar o nodelay, edite o arquivo de configuração do Edge Micro da seguinte maneira:

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

Novas opções da CLI para monitoramento permanente

(Adicionado na versão 2.5.12) Novos parâmetros foram adicionados ao comando edgemicro forever. Com esses parâmetros, é possível especificar o local do arquivo forever.json e iniciar ou interromper o processo em segundo plano do Forever. Consulte também Monitoramento permanente.

Exemplos:

Para iniciar o Forever:

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

Para interromper o Forever:

edgemicro forever -a stop

Rotação de chaves JWT

Um novo recurso foi adicionado para permitir a rotação dos pares de chaves públicas/privadas usados para gerar os tokens JWT usados para segurança do OAuth no Edge Microgateway. Consulte Como fazer rotação de chaves JWT.

Filtrar proxies de API baixados

Por padrão, o Edge Microgateway baixa todos os proxies na sua organização do Edge que começam com o prefixo de nomenclatura "edgemicro_". É possível mudar esse padrão para baixar proxies cujos nomes correspondam a um padrão. Consulte Filtrar proxies baixados.

Especificar produtos sem proxies de API

No Apigee Edge, é possível criar um produto de API que não contenha proxies de API. Essa configuração permite que uma chave de API associada a esse produto funcione com qualquer proxy implantado na sua organização. A partir da versão 2.5.4, o Edge Microgateway é compatível com essa configuração de produto.

Suporte para monitoramento permanente

O Edge Microgateway tem um arquivo forever.json que pode ser configurado para controlar quantas vezes e com quais intervalos o Edge Microgateway deve ser reiniciado. Esse arquivo configura um serviço chamado "forever-monitor", que gerencia o Forever de forma programática. Consulte Monitoramento permanente.

Gerenciamento centralizado do arquivo de configuração do Edge Micro

Se você executar várias instâncias do Edge Microgateway, talvez queira gerenciar as configurações delas em um único local. Para isso, especifique um endpoint HTTP em que o Edge Micro possa fazer o download do arquivo de configuração. Consulte Como especificar um endpoint de arquivo de configuração.

Suporte à opção "forever" da CLI

(Adicionado na versão 2.5.8) Use o comando edgemicro forever [package.json] para especificar o local do arquivo forever.json. Antes da adição desse comando, o arquivo de configuração precisava estar no diretório raiz do Edge Microgateway.

Exemplo:

edgemicro forever ~/mydir/forever.json

Adição da opção configUrl ao comando de recarregamento

(Adicionado na versão 2.5.8) Agora é possível usar a opção --configUrl ou -u com o comando edgemicro reload.

Período de carência para discrepâncias de tempo do JWT

(Adicionado na versão 2.5.7) Um atributo gracePeriod na configuração do OAuth ajuda a evitar erros causados por pequenas discrepâncias entre o relógio do sistema e os horários "Not Before" (nbf) ou "Issued At" (iat) especificados no token de autorização JWT. Defina esse atributo como o número de segundos para permitir essas discrepâncias. Consulte Atributos do OAuth.

(Adicionado na versão 2.5.7) Um atributo gracePeriod na configuração do OAuth ajuda a evitar erros causados por pequenas discrepâncias entre o relógio do sistema e os horários "Not Before" (nbf) ou "Issued At" (iat) especificados no token de autorização JWT. Defina esse atributo como o número de segundos para permitir essas discrepâncias. Consulte Atributos do OAuth.

Bugs corrigidos v2.5.x

• (Problema nº 236) Correção de um erro de digitação ao limpar o cache.
• (Problema nº 234) Falhas de recarregamento no Edge Microgateway 2.5.35.
• (Problema nº 135) Erro de referência de host virtual inválida "secure" ao usar a opção -v. Essa correção modifica o proxy edgemicro-auth antes da implantação para garantir que os hosts virtuais correspondam exatamente ao que é especificado na flag "-v". Além disso, é possível especificar qualquer número e nome para o host virtual (não mais restrito a padrão e seguro).
• (Problema nº 141) O comando edgemicro reload não é compatível com a opção de arquivo de configuração -c. Esse problema foi corrigido.
• (Problema nº 142) O Edge Microgateway reclama sobre criptografia descontinuada no momento da instalação. Esse problema foi corrigido.
• (Problema nº 145) A cota não está funcionando com o Edge Microgateway. Esse problema foi corrigido.
• (Problema da comunidade Apigee: https://community.apigee.com/questions/33149/emg-jwt-token-validated-against-both-api-proxies-a.html#answer-33336) O token JWT foi validado em relação aos proxies de API e ao URI de recurso no OAUTH. Esse problema foi corrigido.
• (Problema da comunidade Apigee: https://community.apigee.com/questions/47846/microgateway-not-working-with-oauth.html) O microgateway não funciona com o OAuth. Esse problema foi corrigido.
• Correção de pidPath no Windows.
• (Problema nº 157) Corrigimos um problema que causava a seguinte mensagem de erro: ReferenceError: deployProxyWithPassword não está definido.
• (Problema nº 169) Atualizar dependências do Node.js (npm audit)
• O proxy edgemicro-auth agora usa as políticas JWT do Edge. O proxy não depende mais do Node.js para oferecer suporte a JWT.

Versão 2.4.x

Novos recursos e melhorias v.2.4.x

1. Defina um alias personalizado para o proxy edgemicro-auth (PR 116)

É possível mudar o basepath padrão do proxy edgemicro-auth. Por padrão, o caminho base é /edgemicro-auth. Para mudar, use a flag -x no comando edgemicro configure.

Exemplo:

edgemicro configure -x /mypath …

2. Suporte a caracteres curinga para caminhos de base (PR 77)

É possível usar um ou mais caracteres curinga "*" no caminho de base de um proxy edgemicro_*. Por exemplo, um caminho base de /team/*/members permite que os clientes chamem https://[host]/team/blue/members e https://[host]/team/green/members sem que você precise criar novos proxies de API para dar suporte a novas equipes. Observe que /**/ não é compatível.

3. Caminho de configuração personalizado adicionado à CLI para configuração do Private Cloud (PR 99)

Por padrão, o arquivo de configuração do microgateway está em ./config/config.yaml. Nos comandos init, configure e start, agora é possível especificar um caminho de configuração personalizado na linha de comando usando as flags -c ou --configDir. Correção de um problema em que um diretório de configuração personalizado para instalações de nuvem privada não era reconhecido.

Exemplo:

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

4. Respeitar as variáveis *_PROXY (PR 61)

Se o Edge Microgateway estiver instalado atrás de um firewall e não puder se comunicar com o Apigee Edge na nuvem pública, há duas opções a considerar:

Opção 1:

A primeira opção é definir a opção edgemicro: proxy_tunnel como "true" no arquivo de configuração do microgateway:

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

Quando proxy_tunnel é true, o Edge Microgateway usa o método HTTP CONNECT para tunelar solicitações HTTP em uma única conexão TCP. O mesmo vale se as variáveis de ambiente para configurar o proxy estiverem ativadas para TLS.

Opção 2:

A segunda opção é especificar um proxy e definir proxy_tunnel como false no arquivo de configuração do microgateway. Exemplo:

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

Nesse caso, você pode definir as seguintes variáveis para controlar os hosts de cada proxy HTTP que você quer usar ou quais hosts não devem processar proxies do Edge Microgateway: HTTP_PROXY, HTTPS_PROXY e NO_PROXY. Você pode definir NO_PROXY como uma lista separada por vírgulas de domínios que o Edge Microgateway não deve usar como proxy. Exemplo:

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

Para mais informações sobre essas variáveis, consulte:

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

5. Definir um tempo limite personalizado para solicitações de segmentação (PR 57)

É possível definir um tempo limite personalizado para solicitações de destino com esta configuração:

edgemicro:
    request_timeout: 10

O tempo limite é definido em segundos. Se ocorrer um tempo limite, o Edge Microgateway vai responder com um código de status 504.

6. Respeitar mensagens de status HTTP personalizadas na resposta de destino (PR 53)

O Edge Microgateway respeita as mensagens de status HTTP personalizadas definidas na resposta de destino. Em versões anteriores, as mensagens de status enviadas do destino eram substituídas pelos padrões do Node.js.

7. O cabeçalho X-Forwarded-For pode definir o client_ip para análise

Se presente, o cabeçalho X-Forwarded-For vai definir a variável client_ip informada no Edge Analytics. Com esse recurso, você pode saber o IP do cliente que enviou uma solicitação ao Edge Microgateway.

8. Mudanças no plug-in do OAuth

O plug-in OAuth é compatível com a verificação de chaves de API e de tokens de acesso OAuth. Antes dessa mudança, o plug-in aceitava qualquer uma das formas de segurança. Com essa mudança, é possível permitir apenas um desses modelos de segurança (mantendo a compatibilidade com versões anteriores).

Os plug-ins do OAuth adicionam duas novas flags:

• allowOAuthOnly: se definido como true, todas as APIs precisam ter um cabeçalho de autorização com um token de acesso do portador.

• allowAPIKeyOnly: se definido como true, todas as APIs precisam ter um cabeçalho x-api-key (ou um local personalizado) com uma chave de API.

Defina essas flags no arquivo de configuração do Edge Microgateway desta forma:

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

9. Melhoria do proxy edgemicro-auth (PR 40)

Foram feitas melhorias no proxy edgemicro-auth. Antes dessas mudanças, o proxy armazenava chaves no Edge Secure Store, um cofre criptografado. Agora, o proxy armazena chaves no mapa de chave-valor (KVM) criptografado do Edge.

10. Reescrever o URL de destino padrão em um plug-in (PR 74)

Você também pode substituir a porta do endpoint de destino e escolher entre HTTP e HTTPS. Modifique estas variáveis no código do plug-in: req.targetPort e req.targetSecure. Para escolher HTTPS, defina req.targetSecure como true. Para HTTP, defina como false. Se você definir req.targetSecure como true, consulte esta discussão em um tópico para mais informações.

11. Suporte inicial para autenticação de token OAuth (PR 125)

É possível configurar o Edge Microgateway para usar um token OAuth na autenticação em vez de nome de usuário/senha. Para usar um token OAuth, use o seguinte parâmetro no comando edgemicro configure:

-t, --token <token>

Exemplo:

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

Bugs corrigidos na v2.4.3

• Foi corrigido um problema em que era necessário ter uma organização paga para executar corretamente o proxy edgemicro-auth. Agora, você também pode usar o Edge Microgateway com organizações de teste. (PR 5)
• Foi corrigido um problema em que o fluxo não terminava de processar os dados, mas os manipuladores de fim eram executados de qualquer maneira. Isso fez com que uma resposta parcial fosse enviada. (PR 71)
• Correção de um problema em que um diretório de configuração personalizado para instalações da nuvem privada não era reconhecido. (PR 110)
• Correção de um problema com SSL bidirecional entre o cliente e o Edge Microgateway. (PR 70)
• Correção de um problema em que uma barra invertida final era necessária no basepath do proxy para que a verificação da chave de API funcionasse corretamente. Agora, não é necessário usar uma barra no final do caminho base. (PR 48)

Versão 2.3.5

Novos recursos e melhorias v.2.3.5

Filtragem de proxy

É possível filtrar quais proxies compatíveis com o microgateway uma instância do Edge Microgateway vai processar. Quando o Edge Microgateway é iniciado, ele baixa todos os proxies compatíveis com microgateway na organização associada. Use a configuração a seguir para limitar quais proxies o microgateway vai processar. Por exemplo, esta configuração limita a três os proxies que o microgateway vai processar: edgemicro_proxy-1, edgemicro_proxy-2 e edgemicro_proxy-3:

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

Mascaramento de dados do Google Analytics

Uma nova configuração permite impedir que as informações do caminho da solicitação apareçam na análise do Edge. Adicione o seguinte à configuração do microgateway para mascarar o URI e/ou o caminho da solicitação. O URI consiste nas partes de nome do host e caminho da solicitação.

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

Versão 2.3.3

Novos recursos e melhorias v.2.3.3

Confira a seguir os novos recursos e melhorias desta versão.

Desativar a pesquisa automática de mudanças

Para desativar a pesquisa automática de mudanças, defina este atributo na configuração do microgateway:

disabled_config_poll_interval: true

Por padrão, a pesquisa periódica detecta todas as mudanças feitas no Edge (em produtos, proxies compatíveis com microrrede etc.) e no arquivo de configuração local. O intervalo de sondagem padrão é de 600 segundos (cinco minutos).

Como reescrever URLs de destino em plug-ins

É possível substituir o URL de destino padrão de forma dinâmica em um plug-in modificando estas variáveis no código do plug-in: req.targetHostname e req.targetPath.

Nova assinatura de função do plug-in

Uma nova assinatura de função de plug-in foi adicionada, fornecendo a resposta de destino como um argumento. Assim, fica mais fácil para os plug-ins acessarem a resposta desejada.

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

Saída de registro padrão simplificada

Por padrão, o serviço de geração de registros agora omite o JSON de proxies, produtos e JWTs baixados. Para mudar o padrão e gerar esses objetos, defina DEBUG=* ao iniciar o Edge Microgateway. Exemplo:

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

Caminho de configuração personalizado adicionado à CLI

Por padrão, o arquivo de configuração do microgateway está em ./config/config.yaml. Nos comandos init, configure e start, agora é possível especificar um caminho de configuração personalizado na linha de comando. Por exemplo:

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

Bugs corrigidos v2.3.3

• Foi corrigido um vazamento de memória que ocorria durante solicitações/respostas grandes.
• A ordem de execução do plug-in foi corrigida. Agora ele se comporta da maneira explicada na documentação.
• O plug-in accumulate-request não trava mais para solicitações GET.
• Foi corrigido um problema no plug-in "accumulate-response" em que a falta de um corpo de resposta causava erros.

Versão 2.3.1

Observação sobre a instalação

Algumas versões anteriores do Edge Microgateway permitem instalar o software fazendo o download de um arquivo ZIP. Esses arquivos ZIP não são mais compatíveis. Para instalar o Edge Microgateway, use:

npm install -g edgemicro

Consulte o tópico de instalação para mais detalhes.

Novos recursos e melhorias v.2.3.1

Confira a seguir os novos recursos e melhorias desta versão.

Filtrar proxies

Uma nova configuração permite filtrar quais proxies o Edge Microgateway vai carregar na inicialização. Antes, o microgateway carregava todos os proxies compatíveis com ele (proxies chamados edgemicro_*) extraídos da organização/ambiente do Edge especificados no comando configure do edgemicro. Com esse novo recurso, é possível filtrar a lista de proxies para que o Edge Microgateway carregue apenas os especificados. Basta adicionar o elemento "proxies" ao arquivo de configuração do microgateway desta forma:

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

Por exemplo, digamos que você tenha 50 proxies edgemicro_* na sua organização/ambiente do Edge, incluindo os chamados edgemicro_foo e edgemicro_bar. Você pode dizer ao microgateway para usar apenas esses dois proxies assim:

edge micro:
proxies:
    - edgemicro_foo
    - edgemicro_bar

Na inicialização, o microrrecurso só poderá chamar os proxies especificados. Qualquer tentativa de chamar outros proxies compatíveis com microrrede baixados da organização/ambiente do Edge resultará em um erro.

Definir cabeçalhos de solicitação de destino em plug-ins

Há dois padrões básicos a serem considerados se você quiser adicionar ou modificar cabeçalhos de solicitação de destino: um em que a solicitação de entrada contém dados (como em uma solicitação POST) e outro em que não contém (como em uma solicitação GET simples).

Vamos considerar um caso em que a solicitação de entrada contém dados e você quer definir cabeçalhos de solicitação na solicitação de destino. Em versões anteriores do Edge Microgateway, não era possível definir cabeçalhos de destino de maneira confiável nesse caso.

A chave para esse padrão é primeiro acumular todos os dados recebidos do cliente. Em seguida, na função onend_request(), use a nova função request.setOverrideHeader(name, value) para personalizar os cabeçalhos.

Confira um exemplo de código de plug-in mostrando como fazer isso. Os cabeçalhos definidos em onend_request são enviados ao destino:

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

  };

}

Se a solicitação não incluir dados, você poderá definir cabeçalhos de destino no processador onrequest(). Esse padrão não é novo. Ele já foi documentado e usado nos plug-ins de amostra fornecidos com o 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();
    }

Recurso de atualização sem inatividade

Depois de fazer uma mudança de configuração no Edge Microgateway, é possível carregar a configuração sem descartar nenhuma mensagem. Com essa mudança, o Edge Microgateway sempre é iniciado no modo de cluster, e a opção --cluster foi removida do comando edgemicro start.

Além disso, três novos comandos da CLI foram adicionados. Execute esses comandos no mesmo diretório em que o comando de início do edgemicro foi executado:

• edgemicro status: verifica se o Edge Microgateway está em execução ou não.
• edgemicro stop: interrompe o cluster do Edge Microgateway.
• edgemicro reload: recarrega a configuração do Edge Microgateway sem inatividade.

Recarregamento automático da configuração sem tempo de inatividade

O Edge Microgateway carrega uma nova configuração periodicamente e executa uma recarga se algo mudar. A pesquisa detecta todas as mudanças feitas no Edge (em produtos, proxies compatíveis com microrroteadores etc.), bem como as mudanças feitas no arquivo de configuração local. O intervalo de pesquisa padrão é de 600 segundos (cinco minutos). É possível mudar o padrão no arquivo de configuração do microgateway da seguinte maneira:

edgemicro:
    config_change_poll_interval: [seconds]

Informações de versão adicionadas à CLI

Uma flag --version foi adicionada à CLI. Para conferir a versão atual do Edge Microgateway, use:

edgemicro --version

Novas opções de SSL do servidor do Edge Microgateway

Além de key e cert, o Edge Microgateway agora é compatível com as seguintes opções de SSL do servidor:

Enviar arquivos de registro para stdout

É possível enviar dados de registro para a saída padrão com uma nova configuração:

edgemicro:
  logging:
    to_console: true  

Consulte Como gerenciar arquivos de registros.

Versão 2.1.2

Confira a seguir os novos recursos e melhorias desta versão.

Permitir endpoint de API personalizado para configuração

Há novos endpoints configuráveis para o proxy de autorização que oferecem suporte ao uso de um serviço de autenticação personalizado. São eles:

• edgeconfig:verify_api_key_url
• edgeconfig:products

Para mais detalhes, consulte Como usar um serviço de autenticação personalizado.

Versão 2.1.1

Confira a seguir os novos recursos e melhorias desta versão.

Implantar um proxy de autenticação compatível com várias plataformas

Foi feita uma melhoria para que o comando usado para implantar o proxy de autorização do Edge Microgateway no Edge seja compatível com sistemas Windows.

Versão 2.1.0

Novos recursos e melhorias v.21.0

Confira os novos recursos e melhorias:

Especificar opções de SSL/TLS do cliente

É possível especificar opções de cliente para conexões SSL/TSL com destinos usando um novo conjunto de opções de configuração. Consulte Usar opções de SSL/TSL do cliente.

Versão 2.0.11

Observação de instalação v2.0.11

Algumas versões anteriores do Edge Microgateway permitem instalar o software fazendo o download de um arquivo ZIP. Esses arquivos ZIP não são mais compatíveis. Para instalar o Edge Microgateway, use:

npm install -g edgemicro

Consulte o tópico de instalação para mais detalhes.

Novos recursos e melhorias v.2.0.11

Confira os novos recursos e melhorias:

Especificar uma porta na inicialização

O comando de inicialização permite especificar um número de porta para substituir a porta especificada no arquivo de configuração. Também é possível especificar um número de porta usando a variável de ambiente PORT. Consulte o comando start para mais detalhes.

Preservar cabeçalhos de autenticação (opcional)

Uma nova configuração, keepAuthHeader, permite preservar o cabeçalho de autorização enviado na solicitação. Se definido como verdadeiro, o cabeçalho de autenticação será transmitido para o destino. Consulte atributos do OAuth.

Capacidade de usar um serviço de autorização personalizado

Se você quiser usar seu próprio serviço personalizado para processar a autenticação, mude o valor authUri no arquivo de configuração do Edge Microgateway para apontar para seu serviço. Para mais detalhes, consulte Usar um serviço de autenticação personalizado.

Versão 2.0.4

O Edge Microgateway v.2.0.4 foi lançado em 25 de maio de 2016.

Novos recursos e melhorias v2.0.4

Confira a seguir os novos recursos e melhorias desta versão.

Suporte para caminhos de recursos em produtos

O Edge Microgateway agora é compatível com caminhos de recursos em produtos. Os caminhos de recursos permitem restringir o acesso às APIs com base no sufixo do caminho do proxy. Para detalhes sobre como criar produtos e configurar caminhos de recursos, consulte Criar produtos de API.

Suporte para instalação global do npm

Agora é possível instalar o Edge Microgateway usando a opção npm -g (global). Para mais detalhes sobre essa opção, consulte a documentação do npm.

Versão 2.0.0

O Edge Microgateway v2.0.0 foi lançado em 18 de abril de 2016.

Novos recursos e melhorias v.2.0.0

Confira a seguir os novos recursos e melhorias desta versão.

Servidor de processo único

O Edge Microgateway agora é um servidor de processo único. Ele não usa mais um modelo de dois processos em que um processo (antes conhecido como "agente") inicia o Edge Microgateway, o segundo processo. A nova arquitetura facilita a automação e a conteinerização.

Arquivos de configuração com namespace

Os arquivos de configuração agora usam namespaces com organização e ambiente para que várias instâncias do Microgateway possam ser executadas no mesmo host. Os arquivos de configuração podem ser encontrados em ~/.edgemicro depois que você executa o comando de configuração do Edge Microgateway.

Novas variáveis de ambiente

Agora há quatro variáveis de ambiente: EDGEMICRO_ORG, EDGEMICRO_ENV, EDGEMICRO_KEY e EDGEMICRO_SECRET. Se você definir essas variáveis no seu sistema, não será necessário especificar os valores delas ao usar a interface de linha de comando (CLI) para configurar e iniciar o Edge Microgateway.

Configuração em cache

O Edge Microgateway usa um arquivo de configuração em cache se for reiniciado sem uma conexão com o Apigee Edge.

Modo de cluster

Agora há opções para iniciar o Edge Microgateway no modo de cluster. O modo de cluster permite aproveitar os sistemas multi-core. O microgateway usa o módulo de cluster do Node.js para esse recurso. Para mais detalhes, consulte a documentação do Node.js.

Bugs corrigidos v2.0.0

O ciclo de vida do evento do plug-in agora processa corretamente o código assíncrono que contém um novo callback.

Versão 1.1.2

O Edge Microgateway v. 1.1.2 foi lançado em 14 de março de 2016.

Novos recursos e melhorias v.1.1.2

Confira a seguir os novos recursos e melhorias desta versão.

Melhoria de performance

O Edge Microgateway agora usa o agente HTTP do Node.js corretamente para melhorar o pool de conexões. Essa melhoria aumenta o desempenho e a estabilidade geral sob carga alta.

Suporte para depurador remoto

É possível configurar o Edge Microgateway para ser executado com um depurador remoto, como o node-inspector.

Novo local do arquivo de configuração

Ao configurar o Edge Microgateway, o arquivo agent/config/default.yaml é copiado para ~./edgemicro/config.yaml.

Rotação de arquivos de registro

Um novo atributo de configuração permite especificar um intervalo de rotação para os registros do Edge Microgateway.

Bugs corrigidos v1.1.2

Os bugs a seguir foram corrigidos na versão 1.1.2.