Se usó la API de Cloud Translation para traducir esta página.

16.09.21: Notas de la versión de Apigee Edge para la nube pública

Estás viendo la documentación de Apigee Edge.
Ve a la Documentación de Apigee X. información

El jueves 13 de octubre de 2016, comenzamos a lanzar una nueva versión de Apigee Edge para público Google Cloud.

Nuevas funciones y actualizaciones

A continuación, presentamos las nuevas funciones y actualizaciones de esta versión.

Compartida Flujos y enlaces de flujo para poner en funcionamiento los proxies de API (solo beta por solicitud)

Un nuevo “flujos compartidos” te permite poner en funcionamiento la funcionalidad en proxies de API. De combinando políticas y recursos condicionalizados en un flujo compartido, puedes hacer referencia a él desde cualquier proxy de API para ejecutar lógica reutilizable de una sola fuente. Por ejemplo, un flujo compartido podría verificar de la clave de API, protegerla contra ataques de aumento repentino y datos de registro.

Defines los flujos compartidos en la IU de administración (APIs > Flujos compartidos) y, luego, hacer referencia a ellos de dos maneras diferentes:

Con una nueva política de Texto destacado de flujo en un proxy de API
o
En un artefacto nuevo llamado hooks de flujo, que se encuentran en las siguientes ubicaciones:
- Solicitud: Antes del ProxyPreFlow y después del TargetEndpoint. PostFlow
- Respuesta: Antes del TargetEndpoint PreFlow, después del ProxyEndpoint PostFlow
Estos puntos de conexión te permiten ejecutar la lógica operativa antes o después del flujo principal puntos de acceso del proxy individual. Los flujos compartidos se asignan a estas ubicaciones de enlace de flujo en el IU de administración (APIs > Configuración del entorno > Enlaces de flujo).

Mapas de clave-valor encriptados

Puedes crear mapas de clave-valor encriptados (KVM) para almacenar información sensible, como credenciales o datos PII/HIPAA. Esta función es diferente del almacén seguro de Edge existente (vault) y está diseñado para reemplazarlo, ya que solo se puede acceder a los valores de vault con Node.js (en además de la API de administración). Puedes acceder a los valores de KVM encriptados con Node.js o la clave Política de operaciones del mapa de valores.

Cómo crear KVM encriptados

Usa las APIs de KVM existentes. Cuando incluyes “encrypted”: “true” en la definición de la carga útil cuando creas un KVM, Edge encripta el KVM. y genera una clave de encriptación con el mismo alcance que el KVM.
No puedes usar la política de operaciones de mapas de pares clave-valor para crear un KVM encriptado.
No puedes encriptar un KVM existente sin encriptar.

Cómo usar KVM encriptados

Usa la política de operaciones de mapas de pares clave-valor para obtener y actualizar valores de KVM encriptados.
Cuando obtengas un valor de clave encriptado, usa “private” como prefijo de la variable para que contenga el valor. Por ejemplo: <Get assignTo="private.secretVar">. Que La variable private.secretVar contiene el valor desencriptado.
Cuando actualizas un valor con la política, no necesitas hacer nada especial. El valor se encriptarán automáticamente en KVMs.
También puedes acceder al valor desencriptado con el módulo de apigee-access en el código de Node.js. Usa la función getKeyValueMap() para recuperar un KVM según el nombre y el alcance. Dos funciones están disponibles en el objeto que se muestra: getKeys(callback) para obtener un array. de nombres de claves y get(key, callback) para obtener el valor de una clave en particular. Por ejemplo:
```
var apigee = require('apigee-access');
  var encryptedKVM = apigee.getKeyValueMap('VerySecureKVM', 'apiproxy'); 
  encryptedKVM.get('secret1', function(err, secretValue) { 
  // use the secret value here 
});
```

(APIRT-1197)

Advertencia:

Operaciones PUT de KVM con claves nulas

Si una política de operaciones del mapa de par clave-valor intenta PUT un Un par clave-valor nuevo en un mapa de clave-valor (KVM) con una clave nula, se crea automáticamente la siguiente clave: __$$_EDGE_KVM_EMPTY_KEY_$$__

Esta situación ocurriría, por ejemplo, si propagas una clave con una referencia de variable y la variable a la que se hace referencia es nula. A medida que se intentan realizar nuevas operaciones PUT con claves nulas, solo se usa esa clave, de modo que sus valores existentes se reemplacen cada vez que de que se ejecute la política.

El comportamiento anterior de una clave nula era que la clave-valor no se agregaba al KVM. sino que permaneció en la caché de la memoria del procesador de mensajes para operaciones Get posteriores. Si la implementación de tu política de KVM se basa en comportamiento anterior, las operaciones Get sobre claves nulas ahora fallarán porque no hacen referencia a el nuevo nombre de la clave (arriba) que se crea para las claves nulas. (APIRT-3530)

URLs de especificaciones de OpenAPI Se incluyen en los metadatos del proxy de API.

Cuando creas un proxy de API basado en una especificación de OpenAPI, la ubicación de la Las especificaciones se almacenan en los metadatos del proxy de API. Por ejemplo, si usas la API de administración para obtener la los detalles de una revisión del proxy, los metadatos incluyen la ruta a las Especificaciones de OpenAPI en formato:

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

Esta mejora es compatible con la versión de última generación de Edge, que vincula las especificaciones de OpenAPI a Proxies de API, productos de API y documentos de referencia de las APIs en el nuevo portal para desarrolladores. (MGMT-2913)

Control de IP de cliente con Sense

Con el fin de controlar con mayor precisión dónde encontrar direcciones IP para la detección de bots de Sense cuando usando productos de enrutamiento como Akamai, Sense te permite definir la ubicación de la IP de cliente con una variable additionalIPVars Por ejemplo, puedes establecer additionalIPVars. para usar el encabezado true-client-ip, que contiene la IP correcta de Akamai a evaluar en las reglas de bots. (APIRT-3332)

Fallas corregidas

En esta versión, se corrigieron los siguientes errores. Esta lista está dirigida principalmente a usuarios que verifican si sus tickets de asistencia se corrigieron. No está diseñada para proporcionar información detallada a todos los usuarios.

ID del problema	Descripción
APIRT-3507	Errores intermitentes (como errores de SNI) en el servicio de JavaScript textos destacados
APIRT-3408	Lanzamiento de MP 160817 de mensajes de procesamiento del módulo de estadísticas de acceso de Apigee de forma diferente
APIRT-3390	Cambio en la respuesta a errores que muestra la política de tokens de acceso de actualización Advertencia: Cambio en el código de error de OAuthV2 "invalid_client". Ten en cuenta el siguiente cambio en un código de error generado por las operaciones de la política OAuthV2. GenerateAccessToken y RefreshAccessToken cuando La propiedad <GenerateResponse> de la política OAuthV2 se establece en false: `{"ErrorCode" : "invalid_client", "Error" :"Client identifier is required"}` se cambió a: `{"ErrorCode" : "InvalidClientIdentifier", "Error" :"Client identifier is required"}` Se recomienda cambiar todas las condiciones de reglas de errores que atrapan “`invalid_client`” para detectar el código nuevo y el anterior. Para Por ejemplo, en tu regla de errores, cambia lo siguiente: `(fault.name = "invalid_client")` a esto: `(fault.name = "invalid_client") OR (fault.name = "InvalidClientIdentifier")`
APIRT-3389	Advertencia: Se produjo un error cuando se subían las cargas útiles de Node.js a través de 25KB Ahora puedes subir cargas útiles de Node.js de más de 25 KB.
APIRT-3381	Latencias altas en los proxies de producción del cliente
APIRT-3366	Las políticas de JavaScript fallan en todas las organizaciones de prueba nuevas
APIRT-3363	El análisis de una URL no válida muestra un estado 500 con ApplicationNotFound
APIRT-3356	Mensaje de token no válido de OAuth
APIRT-3355	Error intermitente 403 en el proxy de OAuth
APIRT-3285	Advertencia: El token de OAuth2 no coincide vencimiento Cuando generas un token de OAuth con la política de OAuth v2.0, puedes configurar el token. el vencimiento por referencia o como un valor predeterminado hard-coded. Por ejemplo: `<ExpiresIn ref="kvm.oauth.expires_in">1800000</ExpiresIn>`. La primera vez que el token se estableció por referencia el vencimiento, Edge almacenó y usó ese valor para cada token nuevo de vencimiento. Se corrigió este error para usar el valor de referencia o, si no hay referencia, si se proporciona un valor, el vencimiento predeterminado definido en la política. Esta corrección puede cambiar la duración de los vencimientos del token y puede experimentar efectos secundarios, como más errores de token no válido, que pueden requerir que implementes actualizaciones de token más frecuentes o Cambia el vencimiento predeterminado de tus políticas de OAuth.
APIRT-3261	Las credenciales se validan en comparación con otra app para desarrolladores que esté en producción
APIRT-3234	La app de Node.js muestra NPE
APIRT-3223	Problema de caché inactiva de Apigee
APIRT-3193	El servidor de destino de Node.js no responde después de migrar a ASG
APIRT-3152	la llamada de administración de registros en caché hace que los mensajes de registro se dividan
APIRT-3117	MP alcanzó el 100% de uso de CPU y dejó de entregar tráfico
APIRT-3064	Router: mensaje de error 503 personalizado del router
APIRT-2620	Grupo de subprocesos separado para algunos pasos de bloqueo para mejorar la carga y administración
CORESERV-774	El acceso que usa una clave válida con una referencia de apiproduct no válida causa que el servidor interno error