Esta página foi traduzida pela API Cloud Translation.

09/16/21 - Notas de lançamento do Apigee Edge para nuvem pública

Você está vendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. informações

Na quinta-feira, 13 de outubro de 2016, começamos a lançar uma nova versão do Apigee Edge para nuvem pública.

Novos recursos e atualizações

Veja a seguir os novos recursos e atualizações desta versão.

Fluxos compartilhados e ganchos de fluxo para operacionalizar proxies de API (apenas Beta por solicitação)

O novo recurso "Fluxos compartilhados" permite operacionalizar a funcionalidade em proxies de API. Ao combinar políticas e recursos condicionalizados em um fluxo compartilhado, é possível referenciá-lo em qualquer proxy de API para executar uma lógica reutilizável de fonte única. Por exemplo, um fluxo compartilhado pode verificar a chave de API, proteger contra prisões de pico e dados de registro.

Você define fluxos compartilhados na IU de gerenciamento (APIs > Fluxos compartilhados) e os refere a duas maneiras diferentes:

Com uma nova política de frases de destaque de fluxo em um proxy de API
ou
Em um novo artefato chamado ganchos de fluxo, que estão nos seguintes locais:
- Solicitação: antes do pré-fluxo de ProxyEndpoint, depois do pré-fluxo do TargetEndpoint
- Resposta: antes do pré-fluxo do TargetEndpoint, depois do pré-fluxo do ProxyEndpoint
Esses pontos de anexo permitem executar a lógica operacional antes ou depois dos pontos de fluxo principais do proxy individual. Você atribui fluxos compartilhados a esses locais de hooks na interface de gerenciamento (APIs > Configuração do ambiente > Hooks de fluxo).

Mapas de chave-valor criptografados

É possível criar mapas de chave-valor criptografados (KVMs, na sigla em inglês) para armazenar informações sensíveis, como credenciais ou dados PII/HIPAA. Esse recurso é diferente do armazenamento seguro do Edge (vault) e foi projetado para superá-lo, já que os valores do Vault só podem ser acessados com Node.js (além da API de gerenciamento). É possível acessar valores KVM criptografados com Node.js ou a política de operações de mapeamento de chave-valor.

Como criar KVMs criptografadas

Usar as APIs KVM já existentes. Quando você inclui “encrypted”: “true” na definição de payload ao criar uma KVM, o Edge criptografa a KVM e gera uma chave de criptografia que tem o mesmo escopo que a KVM.
Não é possível usar a política de operações de mapa de chave-valor para criar uma KVM criptografada.
Não é possível criptografar uma KVM não criptografada.

Como usar KVMs criptografadas

Use a política de operações de mapeamento de chave-valor para receber e atualizar valores KVM criptografados.
Ao receber um valor de chave criptografado, insira "private" como prefixo da variável. Por exemplo, <Get assignTo="private.secretVar">. Essa variável private.secretVar contém o valor descriptografado.
Ao atualizar um valor com a política, você não precisa fazer nada de especial. O valor será criptografado automaticamente em KVMs criptografadas.
Também é possível acessar o valor descriptografado usando o módulo "apigee-access" no código Node.js. Use a função getKeyValueMap() para recuperar uma KVM com base no nome e no escopo. Duas funções estão disponíveis no objeto retornado: getKeys(callback) para receber uma matriz de nomes de chaves e get(key, callback) para receber o valor de uma chave específica. Por exemplo:
```
var apigee = require('apigee-access');
  var encryptedKVM = apigee.getKeyValueMap('VerySecureKVM', 'apiproxy'); 
  encryptedKVM.get('secret1', function(err, secretValue) { 
  // use the secret value here 
});
```

(APIRT-1197)

Aviso:

Operações PUT do KVM com chaves nulas

Se uma política de operações de mapa de chave-valor tentar PUT uma nova chave/valor em um mapa de chave-valor (KVM) usando uma chave nula, a seguinte chave vai ser criada automaticamente: __$$_EDGE_KVM_EMPTY_KEY_$$__

Essa situação acontecerá, por exemplo, se você estiver preenchendo uma chave usando uma referência de variável nula. Como há uma tentativa de novos PUTs com chaves nulas, somente essa chave é usada. Portanto, os valores atuais dela poderão ser substituídos sempre que a política for executada.

O comportamento anterior para uma chave nula era que a chave/valor não fosse adicionada à KVM. Em vez disso, ela permaneceu no cache na memória do processador de mensagens e estava temporariamente disponível para as operações Get subsequentes. Se a implementação da política de KVM depender do comportamento anterior, as operações Get em chaves nulas falharão porque não estão referenciando o novo nome de chave (acima), criado para chaves nulas. (APIRT-3530).

URLs de especificação OpenAPI incluídos nos metadados de proxy de API

Quando você cria um proxy de API com base em uma especificação OpenAPI, o local dessa especificação é armazenado nos metadados do proxy de API. Por exemplo, se você usar a API de gerenciamento para ver os detalhes de uma revisão de proxy, os metadados incluirão o caminho para a especificação OpenAPI no seguinte formato:

"spec" : "https://raw.githubusercontent.com/apigee/api-platform-samples/master/default-proxies/helloworld/openapi/mocktarget.yaml"

Essa melhoria é compatível com a versão de última geração do Edge, que vincula as especificações OpenAPI a proxies, produtos e documentos de referência de API no novo portal do desenvolvedor. (MGMT-2913)

Aviso:

Novo parâmetro de prefixo para Node.js getCache()

Ao receber um armazenamento em cache de borda no Node.js usando a função getCache() do módulo apigee-access, um novo parâmetro de prefixo permite especificar o prefixo do cache, se ele estiver configurado para usar <CacheKey>/<Prefix>, conforme descrito em Preencher a política de cache. Exemplo:

var cache = apigee.getCache('Cache1', {resource: 'Cache1', scope: 'global', prefix: 'UserToken__'});

Antes, se um cache incluísse um prefixo de chave de cache, a função getCache() não conseguia recuperar o cache. (APIRT-3262)

Controle de IP do cliente com o Sense

Para controlar com mais precisão onde encontrar endereços IP para a detecção de bots do Sense ao usar produtos de roteamento, como a Akamai, o Sense permite definir o local do IP do cliente com uma variável additionalIPVars. Por exemplo, defina additionalIPVars para usar o cabeçalho true-client-ip, que contém o IP correto da Akamai para avaliação nas regras de bot. (APIRT-3332).

Bugs corrigidos

Os bugs a seguir foram corrigidos nesta versão. Esta lista é principalmente para usuários que verificam se os tíquetes de suporte foram corrigidos. Ela não foi projetada para fornecer informações detalhadas a todos os usuários.

Id do problema	Descrição
APIRT-3507	Erros intermitentes (como erros de SNI) em chamadas de serviço JavaScript
APIRT-3408	Versão MP 160817 do módulo de análise de acesso à Apigee processando mensagens de forma diferente
APIRT-3390	Mudança na resposta de falha retornada pela política de token de acesso de atualização Aviso:mudança no código de erro "invalid_client" do OAuthV2. Observe a seguinte mudança em um código de erro gerado pelas operações da política OAuthV2 GenerateAccessToken e RefreshAccessToken quando a propriedade <GenerateResponse> da política do OAuthV2 estiver definida como false: `{"ErrorCode" : "invalid_client", "Error" :"Client identifier is required"}` foi alterado para: `{"ErrorCode" : "InvalidClientIdentifier", "Error" :"Client identifier is required"}` É recomendável mudar as condições da regra de falha que capturam "`invalid_client`" para capturar os códigos antigo e novo. Por exemplo, na regra de falha, altere: `(fault.name = "invalid_client")` para: `(fault.name = "invalid_client") OR (fault.name = "InvalidClientIdentifier")`
APIRT-3389	Aviso:erro ao fazer o upload de payloads do Node.js com mais de 25 KB Agora é permitido fazer upload de payloads do Node.js com mais de 25 KB.
APIRT-3381	Altas latências em proxies de produção do cliente
APIRT-3366	As políticas do JavaScript apresentam falha em todas as novas organizações de teste
APIRT-3363	A análise de URL inválido retorna um status 500 com ApplicationNotFound
APIRT-3356	Mensagem de token inválido do OAuth
APIRT-3355	Erro 403 intermitente no proxy OAuth
APIRT-3285	Aviso:validade inconsistente do token OAuth2 Ao gerar um token OAuth usando a política do OAuth v2.0, é possível definir a validade dele por referência ou por um padrão codificado. Por exemplo: `<ExpiresIn ref="kvm.oauth.expires_in">1800000</ExpiresIn>`. Na primeira vez que a expiração do token foi definida por referência, o Edge armazenou e usou esse valor para cada nova expiração de token. Esse bug foi corrigido para usar o valor de referência ou, se nenhum valor de referência for fornecido, a expiração padrão definida na política. Essa correção pode alterar a duração da expiração do token e causar efeitos colaterais, como mais erros de token inválido, o que pode exigir a implementação de atualizações mais frequentes ou a alteração da expiração padrão nas políticas do OAuth.
APIRT-3261	As credenciais são validadas em relação a outro app de desenvolvimento em produção
APIRT-3234	O app Node.js retorna NPE
APIRT-3223	Problema de cache desatualizado da Apigee
APIRT-3193	O servidor de destino Node.js está travado após a migração para o ASG
APIRT-3152	A chamada de gerenciamento de cachedlogs causa a interrupção das mensagens de registro
APIRT-3117	O MP alcançou 100% de uso da CPU e parou de atender ao tráfego
APIRT-3064	Roteador: mensagem de erro 503 personalizada do roteador
APIRT-2620	Separe um pool de linhas de execução para algumas etapas de bloqueio a fim de melhorar o processamento de carga
CORESERV-774	O acesso usando uma chave válida com referência de apiproduct inválida causa erro interno do servidor