Notas de lançamento do Edge Microgateway

Esta é a documentação do Apigee Edge.
Acesse Documentação da Apigee X. informações

Versão 3.3.x

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

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 associadas com o Edge Microgateway 3.3.3. Observe que, como cada componente é um projeto separado, os números de versão 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 associadas com o Edge Microgateway 3.3.2. Observe que, como cada componente é um projeto separado, os números de versão 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 associadas com o Edge Microgateway 3.3.1. Observe que, como cada componente é um projeto separado, os números de versão 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 associadas com o Edge Microgateway 3.3.0. Observe que, como cada componente é um projeto separado, os números de versão 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 associadas com o Edge Microgateway 3.2.3. Observe que, como cada componente é um projeto separado, os números de versão podem não corresponder à versão principal do produto:

Correções de bugs e melhorias:

Problemas de segurança corrigidos

3.2.2

Na quinta-feira, 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 associadas com o Edge Microgateway 3.2.2. Observe que, como cada componente é um projeto separado, os números de versão 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 associadas com o Edge Microgateway 3.2.1. Observe que, como cada componente é um projeto separado, os números de versão 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 associadas com o Edge Microgateway 3.2.0. Observe que, como cada componente é um projeto separado, os números de versão 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 associadas com o Edge Microgateway 3.1.8. Observe que, como cada componente é um projeto separado, os números de versão 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 associadas com o Edge Microgateway 3.1.7. Observe que, como cada componente é um projeto separado, os números de versão 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 associadas com o Edge Microgateway 3.1.6. Observe que, como cada componente é um projeto separado, os números de versão 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 associadas com o Edge Microgateway 3.1.5. Observe que, como cada componente é um projeto separado, os números de versão 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 descontinuado no repositório npm. Caso contrário, todas As correções de bugs e as melhorias descritas na nota da versão 3.1.3 aplicam-se a esta versão.

3.1.3

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

Versões dos componentes:

A tabela a seguir lista os números de versão dos projetos de componentes individuais associadas com o Edge Microgateway 3.1.3. Observe que, como cada componente é um projeto separado, os números de versão podem não corresponder à versão principal do produto:

Correções de bugs e melhorias:

• 153509313 - Foi corrigido um problema em que o módulo de depuração do Node.js causa vazamentos de memória. O problema ocorre nas versões v3.1.0, v3.1.1 e 3.1.2.
• 153509313 – Foi corrigido um problema em que o mesmo ID de mensagem era usado em duas transações diferentes foi impressa na saída de registro.
• 151673570 - Foi corrigido um problema em que o Edge Microgateway não era atualizado para usar os novos APIs Apigee KVM. O Edge Microgateway agora usa os novos comandos para adicionar e atualizar a KVM.
• 152822846 - Em versões anteriores, o Edge Microgateway foi atualizado para que seu processamento de mapeamento de caminho de recursos corresponde ao do Apigee Edge. Nesta versão, um problema foi corrigido em que o padrão /literal_string/* não foi processado corretamente. Por exemplo, /*/2/*. Consulte também Como configurar o comportamento de um caminho de recurso de '/', '/*' e '/**'.
• 152005003 - Foram feitas alterações para permitir identificadores no escopo da organização e do ambiente para cotas.
• 152005003 - Foram feitas alterações para permitir identificadores no escopo da organização e do ambiente para cotas. A combinação de "org + env + appName + productName" é usado como a cota identificador.

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 associadas com o Edge Microgateway 3.1.3. Observe que, como cada componente é um projeto separado, os números de versão podem não corresponder à versão principal do produto:

Correções de bugs e melhorias:

• 151285018 - Um aprimoramento de recurso foi feito para adicionar suporte ao proxy HTTP para tráfego entre o Edge Microgateway e os destinos de back-end. Além disso, foram corrigidos os problemas de APIs suporte de proxy entre o Edge Microgateway e o Apigee Edge. Confira mais detalhes em:
  • 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 balanceador de carga fecha sua conexão foi alterada de ERROR para INFO.
• 150746985: um problema foi corrigido onde o comando edgemicro verify não funcionará corretamente se redisBasedConfigCache: true ou quotaUri: https://%s-%s.apigee.net/edgemicro-auth estavam presentes no arquivo de configuração.
• 151284716 - Foi feita uma melhoria para fechar as conexões com o 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 12, porque o Node.js v8 está obsoleto.
• 151306049 - Foi feita uma atualização na documentação para listar o gerenciamento do Apigee Edge APIs que são 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 associadas com o Edge Microgateway 3.1.1. Observe que, como cada componente é um projeto separado, os números de versão 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 definições de proxy no arquivo de configuração YAML, se especificadas, agora são ignorado; apenas as variáveis de ambiente são usadas para especificar o proxy.

  Para especificar a configuração de proxy no arquivo de configuração, também é necessário especifique uma variável HTTP_PROXY que mencione o mesmo URL de proxy que o especificado em o 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 adicionados. Esse atributo limita o tempo (em milissegundos) que o analisador HTTP aguardará para receber cabeçalhos HTTP completos. Exemplo:

  edgemicro:
  keep_alive_timeout: 6000
  headers_timeout: 12000

  Internamente, o parâmetro define o Node.js Server.headersTimeout nas solicitações. (Padrão: 5 segundos a mais que o horário definido com edgemicro.keep_alive_timeout. O padrão impede que balanceadores de carga ou proxies descarreguem erroneamente a conexão.)

• 149278885 - Foi adicionado um novo recurso que permite definir o tempo limite da API de destino no Nível de proxy da 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 de tempo limite específico do endpoint. 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 associadas com o Edge Microgateway 3.1.0. Observe que, como cada componente é um projeto separado, os números de versão podem não corresponder à versão principal do produto:

Correções de bugs e melhorias:

• 144187500: um novo evento de nível de WARN será registrado quando a sinalização quotas.failOpen for acionada. Essa sinalização será acionada se ocorrer um erro de processamento de cota ou se a "cota aplicável" solicitação para O Edge não atualiza os contadores de cotas remotas. Nesse caso, a cota será processada com base em contagens locais somente até a próxima sincronização remota de cota bem-sucedida acontecer. Antes, evento só foi registrado quando o nível de registro foi 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 que afetava novas transações ou transações em andamento sempre que o Edge Microgateway detectar uma alteração em um proxy de API. Quando uma alteração é feita em um proxy, O Edge Microgateway atualiza o cache e a reinicialização dos nós de trabalho. Com essa mudança, as transações em andamento e as novas chamadas de API enviadas para o microgateway não serão afetadas.
• 146378327: o nível de registro de sourceRequest, targetRequest, e targetResponse foram alterados para o nível INFO.
• 146019878 - Discrepância entre a latência calculada para "Desempenho do proxy da API" na análise do Edge e os eventos de registro sourceResponse/targetResponse do Edge Microgateway foram corrigidos. Agora a latência da análise do Edge e dos eventos de registro do Microgateway está alinhada.
• Mudanças relacionadas à lógica de correspondência de padrões:
  • 147027862 - O plug-in OAuth foi atualizado para oferecer suporte ao seguinte caminho de recurso padrões de correspondência especificados nos produtos da 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 Configuração do comportamento de um recurso caminho de "/", '/*' e '/**'.

  • 145644205 - Atualização da 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 ID do cliente fez com que a criação da lista de produtos JWT fique vazia para o token OAuth e solicitações de chave de API.
• 145640807 e 147579179 - Um novo atributo foi adicionado que permite um Edge Microgateway especial chamado "sincronizador" para recuperar dados de configuração do Apigee Edge e gravá-los para um banco de dados local do Redis. Outras instâncias de microgateway podem ser configuradas para ler de configuração do banco de dados. Esse recurso adiciona um nível de resiliência ao Edge Microgateway. Ele permite que instâncias de microgateway sejam iniciadas e funcionem sem a necessidade de comunicação com Apigee Edge. Para mais detalhes, consulte Como usar o sincronizador.

  Atualmente, o recurso sincronizador funciona 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 associadas com o Edge Microgateway 3.0.10. Observe que, como cada componente é um projeto separado, os números de versão 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 o padrão de correspondência dos caminhos de recursos usada em produtos de API para o Edge Microgateway agora se alinha com a correspondência de padrão de caminho de recurso 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/**, precisa garantir que o proxy edgemicro_auth seja adicionado a um independente de produto de API. Em seguida, inclua esse produto no app para desenvolvedores do proxy. conforme ilustrado na captura de tela a seguir:

  

  Observação: a propriedade de configuração features.isSingleForwardSlashBlockingEnabled, conforme descrito em Não há suporte para a configuração do comportamento de um caminho de recurso de "/", "/*" e '/**' para o Edge Microgateway.

• 143740696 - A estrutura de configuração do quotas mudou (veja também notas da versão 3.0.9). O 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. Observe que o propriedade de configuração é chamada quotas. Para detalhes sobre a configuração individual do quotas propriedades, consulte Opções de configuração para cotas.

  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 - Foi adicionado um novo recurso que permite usar o Redis como cota loja de apoio. Se useRedis for verdadeiro, volos-quota-redis usado. Quando definido como verdadeiro, a cota é restrita apenas às instâncias do Edge Microgateway que conectar-se ao Redis. Se for falso, o volos-quota-apigee é usado como armazenamento de apoio, e o contador de cota é global. Para mais detalhes, consulte Opções de configuração para cotas. Exemplo:

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

• 140574210: o prazo de validade padrão para tokens gerados pelo edgemicro-auth foi alterado de 108.000 milissegundos (1,8 minuto) para 1800 segundos (30 minutos).
• 143551282: para oferecer suporte a organizações com SAML ativada, o comando edgemicro genkeys foi atualizado para incluir um parâmetro ‑‑token. Esse parâmetro permite usar uma Token OAuth para autenticação, em vez de nome de usuário/senha. Para obter detalhes, consulte geração de 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 associadas com o Edge Microgateway 3.0.9. Observe que, como cada componente é um projeto separado, os números de versão podem não corresponder à versão principal do produto:

Correções de bugs e melhorias:

• 141989374 - Uma nova falha ao abrir foi adicionado ao plug-in de cotas. Quando este recurso estiver ativado, se ocorrer um erro de processamento de cota ou se a "cota" for aplicada solicitação para o Edge não atualizar os contadores de cota remota, a cota será processado com base nas contagens locais somente até a próxima cota remota bem-sucedida a sincronização ocorrer. Em ambos os casos, uma sinalização quota-failed-open é definida em o objeto da solicitação.

  Para ativar a cota, "fail open" defina a seguinte configuração:

  quotas :
   failOpen : true

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

• 142093764: uma mudança de configuração foi feita no proxy edgemicro-auth para evitar que a cota seja excedida. A mudança é definir o tipo de cota como agenda. Para usar essa melhoria, você precisa atualizar edgemicro-auth para a versão 3.0.7 ou mais recente.
• 142520568 - Um novo recurso foi adicionado para permitir o registro do MP ID (processador da mensagem) nas respostas de cotas. Para usar esse recurso, você precisa atualizar seu proxy edgemicro-auth para a versão 3.0.7 ou superior e defina a seguinte configuração:

  quotas:
    useDebugMpId: true

  Quando useDebugMpId estiver definido, as respostas de cota do Edge conterão o ID do MP e serão registrados 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 associadas com o Edge Microgateway 3.0.8. Observe que, como cada componente é um projeto separado, os números de versão podem não corresponder à versão principal do produto:

Correções de bugs e melhorias:

• 140025210 - Uma nova falha ao abrir recurso foi adicionado. Esse recurso permite que o processamento da API continue se não é possível atualizar um token JWT expirado 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.

  O recurso permite definir um período de carência em que o token antigo permanece em cache e reutilizado até que o período de carência expire. O recurso permite que o Edge Microgateway para continuar processando solicitações em caso de falha temporária na conexão. Quando é retomada e ocorre uma chamada de verificação da chave de API bem-sucedida, um novo JWT é buscado e substitui o JWT antigo no cache.

  Para configurar a nova "falha ao abrir" faça o seguinte:

  1. Defina as propriedades a seguir na estrofe oauth do Edge Microgateway de configuração do Terraform:

     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 5 segundos se não for possível atualizá-lo devido a um problema de conectividade. Após cinco segundos, um erro de autenticação será retornado.

• 141168968 – Foi feita uma atualização para incluir o correlation_id em todas as saídas 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 o Edge Microgateway e o secret sejam verificados em todas as solicitações de verificação de 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 obtenham um JWT com apenas uma chave de API.
• 140090250 - Foi feita uma atualização na adição de log de diagnóstico para processamento de cotas. Com este mudança, agora é possível correlacionar a saída do registro de quoto com o restante do Edge Microgateway ou de sistemas operacionais de contêineres.

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 associadas com o Edge Microgateway 3.0.7. Observe que, como cada componente é um projeto separado, os números de versão podem não corresponder à versão principal do produto:

Correções de bugs e melhorias:

• 140075602: foi feita uma atualização no plug-in OAuth para retornar um código de status 5xx em que apropriados. Antes, o plug-in retornava apenas códigos de status 4xx em todas além de 200 casos. Agora, para qualquer resposta de mensagem que não tenha um status 200, o O código 4xx ou 5xx vai ser retornado, dependendo do erro.

  Esse recurso fica desativado por padrão. Para ativar esse recurso, adicione o oauth.useUpstreamResponse: true para a 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 esta propriedade de configuração se você quiser gerenciar cotas por meio do edgemicro-auth que é implantado na sua organização. Se esta propriedade não for definida, o endpoint da cota o padrão é 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 do Terraform. Para usar a propriedade quotaUri, é necessário fazer upgrade para a proxy edgemicro-auth mais recente. Para obter detalhes, consulte Como fazer upgrade do Edgemicro-auth proxy.

• 140470888: um cabeçalho de autorização foi adicionado a chamadas de cota para fins de autenticação. Além disso, o proxy edgemicro-auth foi modificado para remover "organização" do identificador de cota. Como o endpoint de cota fica organização do cliente, o identificador de cota não é mais necessário.
• 140823165 – O nome da propriedade a seguir:

  edgemicro:
      keepAliveTimeout

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

  edgemicro:
      keep_alive_timeout

• 139526406 Foi corrigido um bug em que uma contagem de cotas incorreta ocorria quando um aplicativo de desenvolvedor vários produtos. A cota agora é aplicada corretamente para cada produto em um app que tem vários produtos. A combinação de "appName + productName" é usado como identificador de cota.

3.0.6

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

• 138633700: uma nova propriedade de configuração foi adicionada, keepAliveTimeout. Essa propriedade permite que você defina o tempo limite do Edge Microgateway (em milissegundos). (Padrão: 5.000 milissegundos)

  Exemplo:

  edgemicro:
    keep_alive_timeout: 600

• 140090623: uma nova propriedade de configuração foi adicionada, quotaUri. Definir esta configuração propriedade se quiser gerenciar cotas pelo proxy edgemicro-auth que está implantados na organização. Se a propriedade não for definida, o endpoint de cota usa como padrão o endpoint interno do Edge Microgateway. Exemplo:

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

  Para usar esse recurso, é necessário primeiro implantar a versão mais recente do edgemicro-auth proxy para sua organização. Para mais detalhes, consulte Atualização do proxy Edgemicro-auth.

• 138722809: uma nova propriedade de configuração foi adicionada, stack_trace. Esta propriedade você controla se os stack traces não aparecem nos arquivos de registro. Exemplo:

  stack_trace: false

  Se stack_trace for definido como true, o stack trace vai ser impressas em registros. Se ele estiver definido como false, a pilha rastros não serão mostrados 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 retornou o número certo de processos de worker.
• 138437710 – Um problema foi corrigido na classe OutCounter que impedia a execução seja gravado.

• 139064652 - Capacidade adicionada para adicionar níveis de geração de registros trace e debug para o evento e registros do sistema. Por enquanto, só é possível adicionar esses níveis de registro. Atualmente, os níveis de registro disponíveis são info, warn e error.
• 139064616 - A saída do registro foi padronizada para todos os log statements do console. Console instruções de geração de registros agora incluem estes atributos:
• Carimbo de data/hora
• Nome do componente
• ID do processo
• Mensagem de registro do console
.

• 138413755 - Melhoria das mensagens de registro da chave JWT e do secret para essas CLI comandos: cert, verify, upgradekvm, token, genkeys, resellerkeys, backupkey e configure.

• 138413577 - Adição e melhoria do tratamento de erros para tempos limite do serviço de back-end.
• 138413303 - Adicione e melhore o tratamento de erros para tempos limite de resposta e de soquete.
• 138414116 - Adicionar e melhorar o tratamento de erros para "conexão recusada" erros.

3.0.4

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

• 134445926 - Melhorias na autenticação interna do Edge Microgateway.
• 137582169 - Foi corrigido um problema em que processos indesejados eram iniciados. Os processos extras fez com que os plug-ins fossem recarregados e usassem memória excessiva. Agora o Edge Microgateway mantém o número de processos dentro do limite esperado.
• 137768774 - Melhorias nas mensagens de registro:
  • Limpeza dos registros de transação (solicitação).
  • Adicionamos mais mensagens de registro quando necessário.
  • As mensagens de registro de transações (solicitação) foram movidas da saída do console para as mensagens relevantes do arquivo de registros.
  • Atualização dos registros do console para usar uma função de geração de registros centralizada.
• 138321133, 138320563 - Alteração interna básica no buffer de cota para ativar futuras melhorias de cota.

3.0.3

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

• Melhorias no Logging: os registros atuais do ambiente de execução usam uma nova eventLog(), que captura e registra dados do ambiente de execução de forma 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ções).
  • Nome do host: o nome do host solicitante do cabeçalho da solicitação.
  • ID do processo: se você está executando um cluster de processos do Node.js, esse é o ID do o processo em que a geração de registros 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 (não definido atualmente).
  • Nome do componente do Edge Microgateway.
  • Mensagem personalizada: alguns objetos podem imprimir informações adicionais que são transmitidas para essa propriedade de erro.
  • Método de solicitação (se for 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 nesta propriedade.
  • Tempo gasto.
  • Sistema operacional marcador de fim de linha.

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

  Confira no exemplo a seguir o formato do registro:

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

  (137770055)

• Performance: os produtos de API não estavam sendo filtrados com base no ambiente. Este problema foi corrigido. (135038879)
• Diversas 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 para o Edge Microgateway

Qualidade do código: a qualidade do código foi revisada, e as alterações foram feitas nele atendem aos padrões de qualidade exigidos pelos usuários. Resolvemos os erros e avisos de qualidade do código derivado de JSHint. Alguns erros reais de código foram identificados e reparados como resultado. Todos os Apigee Edge Microgateway módulos foram submetidos a esse processo. Veja os compromissos de 28 de junho e 2 de julho para microgateway-config, microgateway-core, microgateway-plugins e microgateway. Todos os módulos com alterações na qualidade do código foram testados com ferramentas internas que verificam a a execução do Edge Microgateway para casos de uso de clientes.

3.0.1

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

• 134834551 - Alterar as versões do Node.js compatíveis com o Edge Microgateway
  Versões compatíveis com o 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 de produtos para o Edge Microgateway retornará 5XX se o padrão de filtro for incorreto
• 135113408 - Os workers devem ser reiniciados se forem encerrados inesperadamente
• 134945852 - tokenCacheSize não é usado no plug-in OAuth
• 134947757 - definir cacheTTL no plug-in do OAuth
• 135445171 - O cálculo do período de carência no OAuth não está correto
• Usar o módulo de memória 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 em 2.5.38, 07/06/2019)

JWTs formatados incorretamente podem causar falhas nos workers ao usar o cache de token. Fixo na borda microgateway-plugins. (b/134672029).

(Adição da versão 2.5.37) Adicionar a opção da CLI edgemicro-cert -t.

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

(Adicionado na versão 2.5.35) Foi adicionado suporte para depurar o Edge Microgateway usando edgemicroctl.

É possível usar a sinalização mgdebug com edgemicroctl. Consulte também Tarefas de integração do Kubernetes.

(Adição da versão 2.5.35) Ativar um build do Windows para edgemicroctl.

(Adição da versão 2.5.31) Nova API Edgemicro-auth/token

Foi adicionada uma nova API Edgemicro-auth/token que permite passar o cliente/secret como um Código Base64 Cabeçalho de autorização básica e Grants_type como parâmetro de formulário. Consulte Como receber tokens do portador diretamente.

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

Foi corrigido um problema que impedia a configuração do Edge Microgateway para usar um token de acesso OAuth2 no Edge para A nuvem privada não funcionou corretamente (o token não foi respeitado).

Docker: suporte ao uso de certificados autoassinados (em inglês)

(Adicionado na versão 2.5.29) Se você estiver usando uma autoridade de certificação (CA) que não seja confiável por padrão Node.js, é possível usar o parâmetro NODE_EXTRA_CA_CERTS ao executar um contêiner do Docker com o Edge Microgateway. Para detalhes, consulte Como usar uma AC 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 para o servidor Edge Microgateway (solicitações no sentido norte) e para solicitações enviadas do Edge Microgateway para para um aplicativo de destino (solicitações direcionadas ao sul).

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

• Exemplo de configuração do TLS para a direção norte
• Exemplo de configuração de TLS no sentido sul

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

Docker: suporte para proxy de solicitação (em inglês)

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

• HTTP_PROXY
• HTTPS_PROXY
• NO_PROXY

Veja mais detalhes em Executar o Edge Micro como um contêiner do Docker.

Docker: instruções atualizadas sobre o 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, usar um ponto de montagem do Docker, é nova. A outra opção já existia, não muda. mas o Dockerfile foi atualizado. Para mais detalhes, consulte os seguintes links:

• 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 ao token OAuth para o comando de upgrade do KVM

(Adicionado 2.5.27) É possível usar um token OAuth com o comando upgradekvm. Para mais detalhes, consulte Como fazer upgrade da KVM.

Como segregar APIs no Edge Analytics

(Adicionado na versão 2.5.26) As novas sinalizações de plug-in de análise permitem que você segregue um caminho de API específico para que ele apareça como um proxy separado nos painéis do Edge Analytics. Por exemplo: segregar APIs de verificação de integridade para evitar confundi-las com chamadas de API reais. Para mais informações, consulte Excluir caminhos das análises.

Como configurar um proxy local

(Adicionado 2.5.25) Com um proxy local, você não precisa criar manualmente um proxy com reconhecimento de microgateway no Apigee Edge. Em vez disso, o microgateway 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 autônomo, permite executar e testar o Edge Microgateway sem uma conexão de Internet, consulte Como executar o Edge Microgateway no modo independente.

Como revogar chaves

(Adicionado na versão 2.5.19) Um novo comando CLI foi adicionado que revoga as credenciais de chave e secret para 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 Docker:

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

Suporte ao Kubernetes

(Adicionado na versão 2.5.19) É possível implantar o Edge Microgateway como um serviço ou como um gateway de arquivo secundário na frente de implantados em um cluster do Kubernetes. Consulte: Integrar o Edge Microgateway com a visão geral do Kubernetes

Suporte para a opção de nodelay do TCP

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

Por padrão, as conexões TCP usam o protocolo Nagle algoritmo para armazenar os dados em buffer antes de enviá-los. Definindo nodelay como true, desativa esse comportamento (os dados disparam imediatamente cada vez que socket.write() é chamado). Consulte também a documentação do Node.js documentação para saber mais.

Para ativar 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 de CLI para monitoramento contínuo

(Adicionado 2.5.12) Novos parâmetros foram adicionados ao comando edgemicro forever. Esses parâmetros permitem que você especificar a localização do arquivo forever.json e permitir que você inicie ou interrompa a operação em segundo plano. Consulte também Monitoramento contínuo

Exemplos:

Para começar para sempre:

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

Para parar definitivamente:

edgemicro forever -a stop

Rotação de chaves JWT

Foi adicionado um novo recurso que permite alternar os pares de chave pública/privada usados para gerar os tokens JWT usados para a segurança OAuth no Edge Microgateway. Consulte Como fazer a rotação de chaves JWT

Como filtrar proxies de API transferidos por download

Por padrão, o Edge Microgateway faz o download de todos os proxies na sua organização de Edge que começam com o prefixo de nomenclatura "edgemicro_". É possível alterar esse padrão para fazer o download de proxies cujos nomes correspondem a um padrão. Consulte Filtragem de proxies baixados

Como 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 de produto permite que uma chave de API associada ao produto funcione com qualquer proxy implantado na sua organização. A partir da versão 2.5.4, o Edge Microgateway é compatível com este produto configuração do Terraform.

Suporte para monitoramento contínuo

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. Este arquivo configura um serviço chamado "monitoramento permanente", que gerencia o acesso "sempre" de forma programática. Consulte Monitoramento contínuo.

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

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

Suporte para a opção de CLI permanente

(Adicionado 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 config precisa estar no diretório raiz do Edge Microgateway.

Exemplo:

edgemicro forever ~/mydir/forever.json

Inclusão da opção "configUrl" para recarregar o comando

(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 seu sistema e o valor de "Não antes" (nbf) ou emitido em (iat) vezes especificados no token de autorização JWT. Defina este atributo como o número de segundos para permitir essas discrepâncias. Consulte Atributos 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 seu sistema e o valor de "Não antes" (nbf) ou emitido em (iat) vezes especificados no token de autorização JWT. Defina este atributo como o número de segundos para permitir essas discrepâncias. Consulte Atributos OAuth.

Bugs corrigidos na v2.5.x

• (Problema no 236) Correção de erro de digitação ao limpar o cache.
• (Problema 234) Recarrega falhas do Edge Microgateway 2.5.35.
• (Problema 135) Referência de host virtual inválida "segura" ao usar o valor-chave -v. Essa correção modifica o proxy Edgemicro-auth antes da implantação para garantir que os hosts virtuais correspondam exatamente ao especificado em "-v" . Além disso, você pode especificar qualquer número e qualquer nome para o host virtual (não está mais restrito a padrão e segura).
• Problema 141: o comando edgemicro reseller não é compatível com a opção -c do arquivo de configuração. Esse problema foi corrigido.
• (Problema no 142) O Edge Microgateway reclama da criptografia obsoleta no momento da instalação. Esse problema foi corrigido.
• Problema 145: A cota não funciona com o Edge Microgateway. Esse problema foi corrigido.
• (Problema da comunidade na 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 da API e ao URI de recurso no OAUTH. Esse problema foi corrigidos.
• (Problema da comunidade da Apigee: https://community.apigee.com/questions/47846/microgateway-not-working-with-oauth.html) O microgateway não está funcionando com o OAuth. Esse problema foi corrigido.
• Correção do pidPath no Windows.
• (Problema 157) O problema que causava a seguinte mensagem de erro foi corrigido: ReferenceError: deployProxyWithPassword não está definido.
• Problema 169: atualizar dependências do Node.js (auditoria de npm)
• O proxy edgemicro-auth agora usa as políticas do Edge JWT. O proxy não depende mais Node.js para oferecer suporte a JWT.

Versão 2.4.x

Novos recursos e melhorias v.2.4.x

1. Definir um alias personalizado para o proxy Edgemicro-auth (PR 116)

É possível alterar o caminho de base padrão do proxy edgemicro-auth. Por padrão, o caminho de base é /edgemicro-auth; Para mudá-lo, use a flag -x no comando edgemicro configure.

Exemplo:

edgemicro configure -x /mypath …

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

Você pode usar um ou mais "*" caracteres curinga no caminho base de uma edgemicro_*. Por exemplo, um caminho base de /team/*/members permite que os clientes liguem para https://[host]/team/blue/members e https://[host]/team/green/members sem precisar criar novos proxies de API para apoiar novas equipes. /**/ não é suporte.

3. Caminho de configuração personalizado adicionado à CLI para configuração de nuvem privada (PR) 99)

Por padrão, o arquivo de configuração do microgateway está em ./config/config.yaml. Nos comandos "init", "configure" e "start", agora você pode especificar um caminho de configuração personalizado no linha de comando usando as sinalizações -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 foi reconhecido.

Exemplo:

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

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

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

Opção 1:

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

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

Quando proxy_tunnel for true, o Edge Microgateway usará o CONNECT para encapsular solicitações HTTP em uma única conexão TCP. O mesmo acontece se as variáveis de ambiente para configurar o proxy estão com o TLS ativado).

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 Defina NO_PROXY como uma lista de domínios delimitados por vírgulas que o Edge Microgateway precisa ter. sem 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 destino (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 responderá com um erro 504 .

6. Respeitar as mensagens personalizadas de status HTTP 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 por Node.js. padrão.

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

Se estiver presente, o cabeçalho X-Forwarded-For definirá o client_ip, que é informada no Edge Analytics. Esse recurso permite que você saber o IP do cliente que enviou uma solicitação para o Edge Microgateway.

8. Mudanças no plug-in OAuth

O plug-in OAuth é compatível com a verificação de chave de API e de token de acesso OAuth. Antes essa mudança, o plug-in aceitava qualquer forma de segurança. Com essa mudança, só é possível permitir um desses modelos de segurança (mantendo a compatibilidade com versões anteriores).

Os plug-ins OAuth adicionam duas novas sinalizações:

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

• allowAPIKeyOnly: se definida como true, todas as APIs deverão transportar um cabeçalho x-api-key (ou um local personalizado) com uma chave de API;

Você define essas sinalizações no arquivo de configuração do Edge Microgateway da seguinte maneira:

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 essas mudanças, as chaves armazenadas o proxy 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)

Também é possível substituir a porta do endpoint de destino e escolher entre HTTP e HTTPS. Modificar estes variáveis no código do plug-in: req.targetPort, e req.targetSecure. Para escolher HTTPS, defina req.targetSecure como true; Para HTTP, defina-o como false. Se você definir req.targetSecure como verdade, veja esta discussão 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 para autenticação em vez de nome de usuário/senha. Para usar um token OAuth, use o parâmetro a seguir no objeto edgemicro configure:

-t, --token <token>

Exemplo:

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

Bugs corrigidos na versão 2.4.3

• Correção de um problema em que uma organização paga era necessária para executar corretamente o proxy Edgemicro-auth. Agora, também é possível usar o Edge Microgateway com organizações de teste. (PR 5)
• Correção de um problema em que o stream não terminava de processar dados, mas os gerenciadores finais eram 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 de nuvem privada não era reconhecida. (PR 110)
• Correção de um problema com o SSL bidirecional entre o cliente e o Edge Microgateway. (PR 70)
• Correção de um problema em que uma barra final era necessária no caminho de base do proxy para a chave de API para funcionar corretamente. Agora, não é preciso adicionar uma barra no final do caminho de base. (PR 48)

Versão 2.3.5

Novos recursos e melhorias v.2.3.5

Filtragem de proxy

É possível filtrar quais proxies com reconhecimento de microgateway uma instância do Edge Microgateway processará. Quando o Edge Microgateway é iniciado, ele faz o download de todos os proxies com reconhecimento de microgateway organização está associado. Use a seguinte configuração para limitar quais proxies o o microgateway será processado. Por exemplo, esta configuração limita os proxies que o microgateway processará para três: 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 informações do caminho da solicitação apareçam no Edge análise de dados em nuvem. Adicione o seguinte à configuração do microgateway para mascarar o URI de solicitação e/ou caminho da solicitação. Observe que o URI consiste nas partes do nome do host e do 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

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

Desativar a sondagem automática de alterações

Você pode desativar a sondagem automática de alterações definindo este atributo no microgateway configuração:

disabled_config_poll_interval: true

Por padrão, a pesquisa periódica identifica todas as alterações feitas no Edge (alterações em produtos, proxies com reconhecimento de microgateway etc.), além das alterações feitas no arquivo de configuração local. O padrão é de 600 segundos (cinco minutos).

Como reescrever URLs de destino em plug-ins

Você pode modificar dinamicamente o URL de destino padrão em um plug-in modificando essas variáveis no código do seu plug-in: req.targetHostname e req.targetPath.

Nova assinatura da função do plug-in

Uma nova assinatura de função de plug-in foi adicionada e fornece a resposta-alvo como uma . Essa adição facilita o acesso dos plug-ins à resposta de destino.

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

Saída de geração de registros padrão simplificada

Por padrão, o serviço de geração de registros agora omite o JSON de proxies, produtos e JWT baixados. É possível alterar o padrão para gerar esses objetos definindo DEBUG=* ao começar. 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. No init, configure e inicie os comandos, agora você pode 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 na versão 2.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 na documentação do Google Cloud.
• O plug-in acumula-request não trava mais para solicitações GET.
• Foi corrigido um problema no plug-in acumula-response em que a falta de informações no corpo da resposta causava erros.

Versão 2.3.1

Nota de 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

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

Filtrar proxies

Uma nova configuração permite filtrar quais proxies serão carregados pelo Edge Microgateway inicialização. Anteriormente, o microgateway carregava todos os proxies com reconhecimento de microgateway (proxies chamados Edgemicro_*) extraídos da organização/ambiente do Edge que você especificou em Edgemicro. configure. Esse novo recurso permite filtrar essa lista de proxies para que o Edge O Microgateway carrega apenas aqueles que você especificar. Basta adicionar o elemento proxies ao microgateway de configuração da Web como este:

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

Por exemplo, digamos que você tenha 50 proxies edgemicro_* no seu Edge org/env, incluindo os chamados edgemicro_foo e edgemicro_bar. Você pode diga ao microgateway para usar apenas esses dois proxies, desta forma:

edge micro:
proxies:
    - edgemicro_foo
    - edgemicro_bar

Na inicialização, o microgateway só poderá chamar os proxies especificados. Qualquer tentativa para chamar outros proxies com reconhecimento de microgateways baixado da organização/do ambiente de borda resultarão em erro.

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

Se quiser adicionar ou modificar cabeçalhos de solicitação de destino, considere dois padrões básicos: uma em que a solicitação recebida contém dados (como em uma solicitação POST) e outra em que não contém (conforme em uma solicitação GET simples).

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

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

Este é um exemplo de código do plug-in que mostra como fazer isso. Os cabeçalhos definidos em onend_request são enviadas 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ê pode definir cabeçalhos de destino no Gerenciador de onrequest(). Esse padrão não é novo. Ele foi documentado anteriormente e foi 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 alterar a configuração no Edge Microgateway, é possível carregar a configuração sem descartar nenhuma mensagem. Com essa mudança, o Edge Microgateway sempre será iniciado no modo de cluster, e a opção --cluster foi removida do edgemicro start kubectl.

Além disso, três novos comandos da CLI foram adicionados. Você precisa executar esses comandos na mesmo diretório em que o comando "edgemicro start" 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 o Edge Microgateway sem inatividade.

Atualização automática de configurações sem inatividade

O Edge Microgateway carrega uma nova configuração periodicamente e executa uma atualização, se necessário mudou. A sondagem capta todas as alterações feitas no Edge (alterações em produtos, com reconhecimento de microgateway) proxies etc.), bem como as alterações feitas no arquivo de configuração local. O intervalo de sondagem padrão é 600 segundos (cinco minutos). É possível alterar o padrão no arquivo de configuração do microgateway como da seguinte forma:

edgemicro:
    config_change_poll_interval: [seconds]

Adição de informações de versão à CLI

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

edgemicro --version

Novas opções de SSL do servidor Edge Microgateway

O Edge Microgateway agora oferece suporte às seguintes opções de SSL do servidor, além das key e cert:

Enviar arquivos de registros 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

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

Permitir a configuração de um endpoint de API personalizado

Há novos endpoints configuráveis para o proxy de autorização, que permitem o uso de um um serviço de autenticação personalizado. Esses endpoints são:

• edgeconfig:verify_api_key_url
• edgeconfig:products

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

Versão 2.1.1

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

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

Uma melhoria foi feita para que o comando usado para implantar a autorização do Edge Microgateway para o Edge é compatível com sistemas Windows.

Versão 2.1.0

Novos recursos e melhorias v.21.0

Veja a seguir os novos recursos e melhorias:

Especificar as opções de SSL/TLS do cliente

Você pode especificar opções de cliente para conexões SSL/TSL com destinos usando um novo conjunto de configurações . Consulte Como usar as opções de SSL/TSL do cliente.

Versão 2.0.11

Nota 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

Veja a seguir os novos recursos e melhorias:

Especificar uma porta na inicialização

O comando "start" permite especificar um número de porta para substituir a porta especificada no de configuração do Terraform. Você também pode especificar um número de porta usando a variável de ambiente PORT. Consulte start para mais detalhes.

Como opção, preserve os cabeçalhos de autenticação

Uma nova definição de configuração, keepAuthHeader, permite preservar o Cabeçalho de autorização enviado na solicitação. Se definido como verdadeiro, o cabeçalho Auth é passado para o alvo. Consulte OAuth.

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

Se quiser usar seu próprio serviço personalizado para lidar com a autenticação, altere o authUri no arquivo de configuração do Edge Microgateway para apontar para seu serviço. Para detalhes, consulte Como 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

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

Suporte para caminhos de recursos em produtos

O Edge Microgateway agora oferece suporte a caminhos de recursos em produtos. Com os caminhos de recursos, você restringe acesso a APIs com base no sufixo do caminho do proxy. Para mais detalhes sobre como criar produtos e configurar caminhos de recursos, consulte Criar API produtos.

Suporte para instalação global do npm

Agora é possível instalar o Edge Microgateway usando a opção npm -g (global). Para mais detalhes consulte a API NPM Documentação.

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

Veja 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 de desenvolvimento de software. A nova arquitetura facilita a automação e a conteinerização.

Arquivos de configuração com namespace

Os arquivos de configuração agora recebem namespaces usando organização e ambiente para que vários As instâncias de microgateway podem ser executadas no mesmo host. Os arquivos de configuração estão em ~/.edgemicro depois de executar 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 EDGEMICRO_SECRET. Se você definir essas variáveis em seu sistema, não precisará especificar seus quando você usa a interface de linha de comando (CLI) para configurar e iniciar o Edge Microgateway

Configuração em cache

O Edge Microgateway usará um arquivo de configuração em cache se for reiniciado sem ao Apigee Edge.

Modo de cluster

Agora há opções para iniciar o Edge Microgateway no modo de cluster. Com o modo de cluster, você pode e aproveitar os benefícios dos sistemas multinúcleo. O microgateway usa o módulo de cluster Node.js para esse recurso. Para mais detalhes, consulte a documentação do Node.js.

Bugs corrigidos na versão 2.0.0

O ciclo de vida de eventos do plug-in agora lida corretamente com códigos assíncronos que contêm códigos com uma nova o retorno de chamada.

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

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

Melhoria de desempenho

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

Suporte ao 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

Quando você configura o Edge Microgateway, o arquivo agent/config/default.yaml agora é copiado para ~./edgemicro/config.yaml.

Rotação do arquivo de registro

Um novo atributo de configuração permite especificar um intervalo de rotação para o Edge Microgateway ou de sistemas operacionais de contêineres.

Bugs corrigidos na v1.1.2

Os seguintes bugs foram corrigidos na v. 1.1.2.