API Platform 4.3.4.0

Correções de bugs

  • Quando uma nova Revision de API era criada, estava ocorrendo uma falha no editor de Swagger que levava a alterações indevidas no código, com perda de informações. Agora, somente o que for explicitamente alterado na nova Revision será modificado no arquivo Swagger.

  • Quando uma chamada era feita utilizando o interceptor Internal API Call (usado para invocar uma chamada interna), o método HTTP da chamada interna estava repetindo o método da chamada original. Agora, o método HTTP da chamada interna está devidamente seguindo o método cadastrado no campo "Operation" da configuração do interceptor. Além disso, o Internal API Call estava tratando headers informados como case-sensitive, e isso também foi corrigido.

  • Se o usuário tentasse gerar um access token pelo fluxo Password de um interceptor de OAuth usando uma API sem vínculo com API Identity, o retorno seria uma código de estado 400 e uma mensagem de erro que não correspondia ao problema. Alteramos o retorno para 401 e adicionamos uma mensagem avisando o usuário que não é permitido gerar token por fluxo Password sem vínculo com uma API Identity. Também ajustamos a documentação para deixar claro esse comportamento.

  • A listagem de APIs não estava obedecendo completamente os filtros escolhidos.

  • Quando o extraInfo de uma app era alterado utilizando um interceptor Custom JavaScript com o método $call.app.extraInfo, essa alteração era refletida não somente no contexto da chamada, mas dentro do escopo da aplicação (ou seja, a alteração permanecia nas chamadas seguintes que resgatassem o valor do extraInfo). Agora, essa alteração será restrita ao contexto da chamada, sem modificar os dados da app que estão registrados no Manager.

  • Se o fluxo de uma API contivesse um interceptor JWT Validation configurado sem marcar a opção de utilizar criptografia ("Use JWE-JSON Web Encryption") e uma chamada a essa API fosse feita utilizando um token JWT criptografado, havia um retorno de erro com código de estado 500 (erro de servidor). O código de erro foi alterado para 401 (Unauthorized).

  • Não estava sendo possível desvincular uma API de uma API Identity (a remoção de vínculo não estava impedindo que se gerasse um token para a API). Isso foi solucionado e agora é perfeitamente possível cada uma seguir o seu caminho (George Michael ficaria satisfeito).

  • O campo "URI" do Trace de APIs estava exibindo valores indevidos por causa do método utilizado para retornar o endereço (quando havia múltiplas URLs em um JSON, a primeira era retornada e exibida no campo "URI"). Isso ocasionava confusão, incluindo a percepção de que o Trace estava misturando chamadas a APIs diferentes (o que não estava acontecendo). Mudamos o método e o campo agora exibe o valor correto.

  • Quando a opção de visibilidade de uma API era modificada, essa alteração não estava sendo refletida no Manager, o que causava comportamentos indesejáveis (como a impossibilidade de deletar um usuário dono de uma API).

  • Não havia mensagem de aviso quando um usuário deletasse um ambiente vinculado a pelo menos uma API. Agora, o usuário é alertado do vínculo e precisa confirmar a deleção.

  • Buscas na tela de APIs utilizando o caractere / estavam retornando erro.

  • Usuários que não fossem do tipo Super Admin não estavam conseguindo criar API Identities.

  • Adicionamos mensagem de alerta ao usuário quando caracteres não suportados forem utilizados na tela de login (como espaço em branco).

  • Em algumas instâncias, as permissões de visibilidade e de implantação em ambientes não estavam sendo tratadas como independentes (o que fazia com que uma alteração em apenas uma das permissões não fosse mantida).

  • A função de exportação de dados do General Trace por meio do download de um arquivo JSON estava quebrada.

  • Na tela de uma API, é possível buscar usuários e/ou times ativos para selecionar o responsável pela API, mas o Manager só estava retornando 10 usuários/times como resultado da consulta. Agora, todos os usuários ativos (ou seja, não bloqueados) e times existentes são exibidos e podem ser selecionados.

  • Na janela modal de criação de um novo usuário, era possível incluir um endereço de email com letras maiúsculas, mas isso gerava um erro não especificado (sem mensagem clara de aviso). Agora, não é mais possível incluir letras maiúsculas — o Manager automaticamente as transforma em letras minúsculas.

  • Incluímos na documentação a informação de que não é possível utilizar o interceptor Internal API Call para invocar uma API implantada em ambiente diferente da API de origem.

  • Resolvemos um problema na abertura de conexões que estava causando situações de inconsistência no Manager.

  • [Connectors] Chamadas utilizando connectors estavam retornando erro caso fosse passado um JWT no header Authorization.

  • [Connectors] A seção "Docker Run" em API Connectors  Create Connector  COMMAND IMAGE não possuía a informação "SERVER_PORT", que foi incluída.

  • [Connectors] Havia um erro relacionado a busca por keyword do banco de dados quando uma operação era criada através de um connector.

  • Por último, algumas correções no front vieram para satisfazer quem se importa com questões gramaticais e estéticas (#tamojunto!):

    • a mensagem de validação exibida quando o usuário escolhia deletar um ambiente vinculado a um connector não estava clara e foi ajustada;

    • os valores exibidos na janela modal de importação de mapas (em Environments) estavam quebrando quando eram extensos (agora estão ok, com quebras de linha que ajudam a visualização);

    • quando um connector que não estava funcionando era selecionado, o front mostrava um ícone de erro mas sem mensagem explicativa (que foi adicionada);

    • nomes extensos e sem espaços entre palavras estavam sendo exibidos sem quebra de linha em Audit;

    • nomes extensos de APIs estavam sendo exibidos sem quebra de linha e desconfigurando a visualização das APIs em modo Lista.

Melhorias

  • O processo de configuração de fluxos de APIs está mais amigável (você pode ver as novas telas aqui). Implementamos estas mudanças:

    • a tela agora exibe as descrições do recurso e operação que estão sendo configurados, ou a informação de que as configurações serão aplicadas a todos os recursos e/ou operações;

    • o nome da API e da Revision agora são exibidos na tela, acima dos campos para selecionar recurso e operação.

  • Implementamos melhorias na API do Manager:

    • adicionamos o parâmetro operation_id no endpoint /metrics/health para permitir consulta de informações a respeito de apenas uma operação;

    • adicionamos o método PATCH para developers/{login}, que permite alterar campos de Developers individualmente.

  • Adicionamos uma opção de sysconfig para configurar tamanho mínimo de senha para acesso ao Manager.

  • Criamos uma validação de cenários com base em TimeStamp para impossibilitar que cenários desatualizados sejam consumidos.

  • Agora é possível enviar dados de certificado de origem via header em conexões mTLS. Quando habilitado o envio, as seguintes informações serão remetidas: By, Hash, Cert, Chain, Subject, URI e DNS. Veja mais sobre isso aqui.

  • [Connectors] Implementamos uma nova regra para Connectors: todos os novos connectors devem nascer como versão Beta e serão atualizados para uma versão estável após um período de maturação.

  • O link de acesso ao Online Help dos nossos produtos foi atualizado para o Sensedia Docs (este site!).

Matriz de compatibilidade entre componentes

A Sensedia API Platform é composta por diversos componentes. A Release 4.3.4.0 é formada por:

Aplicação Módulo Versão

API Platform

API Gateway

4.3.6.0

API Platform

API Manager

4.3.4.0

API Platform

API Manager Front

4.3.4.0

API Platform

Platform Elasticsearch Templates

Master

API Platform

API Authorization

4.1.2.0

API Platform

API Metrics

4.2.1.0

API Platform

Connector Manager

4.2.0.0

Connector

Connector-db-postgres-9.4

4.1.0.0-BETA

Thanks for your feedback!
EDIT
How useful was this article to you?