API Platform 4.3.5.0

Encontramos una situación en la que se podían crear tokens de acceso para una API que no se implementó en ningún entorno. Esto se ha resuelto, y ahora solo las aplicaciones vinculadas a APIs implementadas pueden tener tokens de acceso creados.

Hemos corregido un error en el front-end que provocaba la ejecución de un interceptor que no aparecía en el flujo.

La función de comprobación automática cada 15 minutos en Setting  Health Checks se interrumpió y se eliminó del front. Para comprobaciones automáticas de diferentes parámetros de rendimiento de APIs, consulte nuestra solución Sensedia Flexible Actions.

Cuando se eliminaba un plan, aparecía un mensaje de éxito acompañado de un mensaje de error incorrecto. Se ha eliminado el mensaje de error.

En algunas versiones, no era posible configurar el interceptor String Match Condition en el flujo de respuesta, solo en el flujo de petición; el interceptor se insertaba en el flujo, pero la ventana de configuración no se abría. Ahora, la ventana se abre normalmente y el interceptor está funcionando como debería.

Resolvemos casos en los que, al eliminar un interceptor del flujo, un segundo interceptor estaba siendo eliminado incorrectamente también.

Las llamadas con tokens revocados devolvían el código de error HTTP 403 (Forbidden). Establecemos el retorno a 401 (Unauthorized).

No se estaba realizando una validación de los caracteres de tipo Special Unicode en los campos de ruta de recursos/operaciones.

El gateway no estaba haciendo uso explícito de keep-alive (conexión persistente) implementada en los backends para peticiones HTTP.

Se ha corregido un error en algunos escenarios que no permitían la creación de una API con contexto de equipos (opción Teams en el campo Context).

Las versiones 4.3.x.x del API Gateway soportaban el protocolo HTTP sólo en las versiones 1.1 y 2.0. Esto generó un problema de compatibilidad con versiones anteriores en algunos clientes y ahora hemos ampliado el soporte a HTTP 0.9 y 1.0 también.

En algunos escenarios, una API que había sido eliminada seguía apareciendo en el front, aunque no fuera posible acceder a ella.

La lista de usuarios en Security  Users tenía un diseño quebrado al mostrar un usuario con un nombre de inicio de sesión demasiado largo.

Al utilizar el interceptor Internal API Call, puede mantener los parámetros de la petición original o agregar nuevos parámetros a la petición interna. Hemos comprobado y corregido este comportamiento incorrecto: al introducir parámetros manuales y luego optar por mantener los parámetros de la petición original, los parámetros que se habían introducido manualmente aún se enviaban.

[Adaptive Governance] Se ha ajustado el comportamiento incorrecto de la función Workflows del complemento Adaptive Governance. Al incluir el requisito de que no puede haber un cierto interceptor en el flujo de una API para guardarla en una etapa determinada, esto no impidió que se guardara una API que contenía dicho interceptor.

[Connectors] Se ha ajustado el mensaje de alerta que se muestra al eliminar un conector, cuyo diseño se rompía si el nombre del conector era demasiado grande.

[Connectors] Al guardar una nueva revisión de una API que tiene un recurso asociado a un conector, esta característica se desconfiguró en la nueva revisión y se perdió el enlace con el conector.