Notas de la versión de Edge Microgateway

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

Versión 3.3.x

Corrección de errores y mejoras v.3.3.x

3.3.3

El 25 de abril de 2024, lanzamos las siguientes correcciones y mejoras en Edge Microgateway

Versiones de los componentes:

En la siguiente tabla, se indican los números de versión para los proyectos de componentes individuales asociadas con Edge Microgateway 3.3.3. Ten en cuenta que, como cada componente es un proyecto independiente, Es posible que los números de versión no coincidan con la versión principal del producto:

Mejoras y correcciones de errores:

Se solucionaron los problemas de seguridad

• 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

El 18 de agosto de 2023, lanzamos las siguientes correcciones y mejoras en Edge Microgateway

Versiones de los componentes:

En la siguiente tabla, se indican los números de versión para los proyectos de componentes individuales asociadas con Edge Microgateway 3.3.2. Ten en cuenta que, como cada componente es un proyecto independiente, Es posible que los números de versión no coincidan con la versión principal del producto:

Mejoras y correcciones de errores:

Se solucionaron los problemas de seguridad

Ninguno

3.3.1

El 7 de junio de 2022, lanzamos las siguientes correcciones y mejoras en Edge Microgateway

Versiones de los componentes:

En la siguiente tabla, se indican los números de versión para los proyectos de componentes individuales asociadas con Edge Microgateway 3.3.1. Ten en cuenta que, como cada componente es un proyecto independiente, Es posible que los números de versión no coincidan con la versión principal del producto:

Mejoras y correcciones de errores:

Se solucionaron los problemas de seguridad

3.3.0

El 4 de febrero de 2022, lanzamos las siguientes correcciones y mejoras en Edge Microgateway

Versiones de los componentes:

En la siguiente tabla, se indican los números de versión para los proyectos de componentes individuales asociadas con Edge Microgateway 3.3.0. Ten en cuenta que, como cada componente es un proyecto independiente, Es posible que los números de versión no coincidan con la versión principal del producto:

Mejoras y correcciones de errores:

npm install apigeetool@0.15.1

Versión 3.2.x

Corrección de errores y mejoras v.3.2.x

3.2.3

El 17 de septiembre de 2021, lanzamos las siguientes correcciones y mejoras en Edge Microgateway

Versiones de los componentes:

En la siguiente tabla, se indican los números de versión para los proyectos de componentes individuales asociadas con Edge Microgateway 3.2.3. Ten en cuenta que, como cada componente es un proyecto independiente, Es posible que los números de versión no coincidan con la versión principal del producto:

Mejoras y correcciones de errores:

Se solucionaron los problemas de seguridad

3.2.2

El jueves 15 de julio de 2021, lanzamos las siguientes correcciones y mejoras en Edge Microgateway

Versiones de los componentes:

En la siguiente tabla, se indican los números de versión para los proyectos de componentes individuales asociadas con Edge Microgateway 3.2.2. Ten en cuenta que, como cada componente es un proyecto independiente, Es posible que los números de versión no coincidan con la versión principal del producto:

Mejoras y correcciones de errores:

Se solucionaron los problemas de seguridad

3.2.1

El viernes 5 de marzo de 2021, lanzamos las siguientes correcciones y mejoras en Edge Microgateway

Versiones de los componentes:

En la siguiente tabla, se indican los números de versión para los proyectos de componentes individuales asociadas con Edge Microgateway 3.2.1. Ten en cuenta que, como cada componente es un proyecto independiente, Es posible que los números de versión no coincidan con la versión principal del producto:

Mejoras y correcciones de errores:

edgemicro:
 enable_GET_req_body: true

3.2.0

El jueves 21 de enero de 2021, lanzamos las siguientes correcciones y mejoras en Edge Microgateway

Versiones de los componentes:

En la siguiente tabla, se indican los números de versión para los proyectos de componentes individuales asociadas con Edge Microgateway 3.2.0. Ten en cuenta que, como cada componente es un proyecto independiente, Es posible que los números de versión no coincidan con la versión principal del producto:

Mejoras y correcciones de errores:

Versión 3.1.x

Corrección de errores y mejoras v.3.1.x

3.1.8

El lunes 16 de noviembre de 2020, lanzamos las siguientes correcciones y mejoras en Edge Microgateway

Versiones de los componentes:

En la siguiente tabla, se indican los números de versión para los proyectos de componentes individuales asociadas con Edge Microgateway 3.1.8. Ten en cuenta que, como cada componente es un proyecto independiente, Es posible que los números de versión no coincidan con la versión principal del producto:

Mejoras y correcciones de errores:

3.1.7

El jueves 24 de septiembre de 2020, lanzamos las siguientes correcciones y mejoras en Edge Microgateway

Versiones de los componentes:

En la siguiente tabla, se indican los números de versión para los proyectos de componentes individuales asociadas con Edge Microgateway 3.1.7. Ten en cuenta que, como cada componente es un proyecto independiente, Es posible que los números de versión no coincidan con la versión principal del producto:

Mejoras y correcciones de errores:

{"message":"write after end","code":"ERR_STREAM_WRITE_AFTER_END"}

3.1.6

El jueves 20 de agosto de 2020, lanzamos las siguientes correcciones y mejoras en Edge Microgateway

Versiones de los componentes:

En la siguiente tabla, se indican los números de versión para los proyectos de componentes individuales asociadas con Edge Microgateway 3.1.6. Ten en cuenta que, como cada componente es un proyecto independiente, Es posible que los números de versión no coincidan con la versión principal del producto:

Mejoras y correcciones de errores:

3.1.5

El viernes 26 de junio de 2020, lanzamos las siguientes correcciones y mejoras en Edge Microgateway

Versiones de los componentes:

En la siguiente tabla, se indican los números de versión para los proyectos de componentes individuales asociadas con Edge Microgateway 3.1.5. Ten en cuenta que, como cada componente es un proyecto independiente, Es posible que los números de versión no coincidan con la versión principal del producto:

Mejoras y correcciones de errores:

3.1.4

El viernes 23 de abril de 2020, lanzamos la siguiente corrección en Edge Microgateway

Corrección de errores:

Se corrigió un problema de dependencia en la versión 3.1.3. La versión 3.1.3 se marcó como obsoleto en el repositorio de npm. De lo contrario, todas las Las correcciones de errores y las mejoras que se describen en la nota de la versión 3.1.3 se aplican a esta versión.

3.1.3

El miércoles 15 de abril de 2020, lanzamos las siguientes correcciones y mejoras en Edge Microgateway

Versiones de los componentes:

En la siguiente tabla, se indican los números de versión para los proyectos de componentes individuales asociadas con Edge Microgateway 3.1.3. Ten en cuenta que, como cada componente es un proyecto independiente, Es posible que los números de versión no coincidan con la versión principal del producto:

Mejoras y correcciones de errores:

• 153509313: se corrigió un problema por el que el módulo de depuración de Node.js provocaba fugas de memoria. El problema existe en las versiones 3.1.0, 3.1.1 y 3.1.2.
• 153509313: se solucionó un problema por el que el mismo ID de mensaje para dos transacciones diferentes se imprimió en el resultado del registro.
• 151673570: se solucionó un problema por el que no se actualizaba Edge Microgateway para que usara el APIs de KVM para Apigee. Edge Microgateway ahora usa los comandos nuevos para agregar y actualizar Valores de KVM.
• 152822846: en versiones anteriores, se actualizó Edge Microgateway para que el procesamiento coincide con la de Apigee Edge. En esta versión, se solucionó un problema en el que el patrón /literal_string/* no se manejó correctamente. Por ejemplo, /*/2/*. Consulta también La configuración del comportamiento de la ruta de acceso del recurso “/”, “/*” y “/**”.
• 152005003: se realizaron cambios para habilitar identificadores con permisos de la organización y el entorno para las cuotas.
• 152005003: se realizaron cambios para habilitar identificadores con permisos de la organización y el entorno para las cuotas. La combinación de “org + env + appName + productName” se usa como cuota identificador.

3.1.2

El lunes 16 de marzo de 2020, lanzamos las siguientes correcciones y mejoras en Edge Microgateway

Versiones de los componentes:

En la siguiente tabla, se indican los números de versión para los proyectos de componentes individuales asociadas con Edge Microgateway 3.1.3. Ten en cuenta que, como cada componente es un proyecto independiente, Es posible que los números de versión no coincidan con la versión principal del producto:

Mejoras y correcciones de errores:

• 151285018: se mejoró la función para agregar compatibilidad con el proxy HTTP para el tráfico. entre Edge Microgateway y los destinos de backend. Además, se solucionaron los problemas de los registros de proxy entre Edge Microgateway y Apigee Edge. Para obtener más información, consulta lo siguiente:
  • Usa un proxy HTTP para la comunicación con Apigee Edge
  • Usa un proxy HTTP para la comunicación de destino
• 149101890: el código de notificación de registro para los casos en los que el servidor de destino o el balanceador de cargas cierra la conexión, se cambió de ERROR a INFO.
• 150746985: se solucionó un problema en el que el comando edgemicro verify no lo hacía. funcionan correctamente si redisBasedConfigCache: true o quotaUri: https://%s-%s.apigee.net/edgemicro-auth estaban presentes en el archivo de configuración.
• 151284716: se mejoró para cerrar las conexiones con el servidor más rápido cuando los trabajadores se reinicien durante una recarga.
• 151588764: Actualiza la versión de Node.js en la imagen de Docker que se usa para ejecutar Edge Microgateway. en un contenedor de Docker a 12, porque Node.js v8 está obsoleto.
• 151306049: se realizó una actualización en la documentación para enumerar la administración de Apigee Edge Las APIs que usan los comandos de la CLI de Edge Microgateway. Consulta ¿Qué APIs de administración usa Edge Microgateway?

3.1.1

El jueves 20 de febrero, lanzamos las siguientes correcciones y mejoras en Edge Microgateway

Versiones de los componentes:

En la siguiente tabla, se indican los números de versión para los proyectos de componentes individuales asociadas con Edge Microgateway 3.1.1. Ten en cuenta que, como cada componente es un proyecto independiente, Es posible que los números de versión no coincidan con la versión principal del producto:

Mejoras y correcciones de errores:

• 146069701: Se solucionó un problema en el módulo microgateway-core. No se respetaron las variables de entorno HTTP_PROXY ni HTTPS_PROXY. Con este cambio, la configuración de proxy en el archivo de configuración YAML, si se especifica, ignorados; solo se usan las variables de entorno para especificar el proxy.

  Si quieres especificar la configuración del proxy en el archivo de configuración, también debes especifica una variable HTTP_PROXY que mencione la misma URL de proxy que la especificada en el archivo de configuración. Por ejemplo, si especificas la siguiente configuración:

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

  También debes especificar esta variable de entorno:

  HTTP_PROXY=http://10.128.0.20:3128

• 146320620: se incluyó un parámetro de configuración nuevo, edgemicro.headers_timeout. agregado. Este atributo limita la cantidad de tiempo (en milisegundos) que el analizador de HTTP esperará para recibir el encabezados HTTP completos. Por ejemplo:

  edgemicro:
  keep_alive_timeout: 6000
  headers_timeout: 12000

  De forma interna, el parámetro establece la biblioteca Server.headersTimeout en las solicitudes. (Predeterminado: 5 segundos más que la hora establecida con edgemicro.keep_alive_timeout. Esta configuración predeterminada evita que los balanceadores de cargas o los proxies descarten la conexión por error).

• 149278885: se agregó una función nueva que permite establecer el tiempo de espera de la API de destino en el Nivel de proxy de API en lugar de usar una configuración de tiempo de espera global.

  Si estableces la propiedad TargetEndpoint io.timeout.millis en el proxy de API, Edge Microgateway podrá recuperar esa propiedad y aplicar tiempos de espera específicos del extremo. Si no se aplica este parámetro, Edge Microgateway usa el tiempo de espera global especificado con edgemicro.request_timeout.

3.1.0

El martes 21 de enero, lanzamos las siguientes correcciones y mejoras en Edge Microgateway

Versiones de los componentes:

En la siguiente tabla, se indican los números de versión para los proyectos de componentes individuales asociadas con Edge Microgateway 3.1.0. Ten en cuenta que, como cada componente es un proyecto independiente, Es posible que los números de versión no coincidan con la versión principal del producto:

Mejoras y correcciones de errores:

• 144187500: Se registrará un nuevo evento de nivel WARN cuando se active la marca quotas.failOpen. Esta marca se activa si se produce un error de procesamiento de la cuota o si el valor de “quota apply” solicitar a Edge no puede actualizar los contadores de cuotas remotos. En este caso, la cuota se procesará según en recuentos locales solo hasta que se realice la siguiente sincronización remota correcta de la cuota. Anteriormente, esta el evento solo se registró cuando el nivel de registro se estableció en DEBUG.

  Por ejemplo:

  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: Se corrigió un problema que afectaba a las transacciones nuevas o en tránsito. cada vez que Edge Microgateway detectó un cambio en un proxy de API Cuando se realiza un cambio en un proxy, Edge Microgateway actualiza la caché y se reinician los nodos trabajadores. Con este cambio, las transacciones en tránsito y las nuevas llamadas a la API que se envían a microgateway no se ven afectadas.
• 146378327: el nivel de registro de sourceRequest, targetRequest y targetResponse se cambiaron al nivel INFO.
• 146019878: una discrepancia entre la latencia que se calculó para “Rendimiento del proxy de la API” en Edge Analytics y los eventos de registro sourceResponse/targetResponse de Edge Microgateway y solucionar el problema. Ahora, la latencia en las estadísticas de Edge y los eventos de registro de Microgateway está alineada.
• Cambios relacionados con la lógica de coincidencia de patrones:
  • 147027862: Se actualizó el complemento de OAuth para admitir la siguiente ruta de acceso del recurso. patrones coincidentes que se especifican en los productos de API:
    • /{literal}**
    • /{literal}*
    • Cualquier combinación de los dos patrones anteriores

    Con este cambio, el complemento de Edge Microgateway ahora sigue el mismo coincidencia de patrones como Apigee Edge, como se explica en Configurar el comportamiento de un recurso la ruta de acceso de “/”, “/*” y “/**”.

  • 145644205: se actualizó la lógica de coincidencia de patrones del complemento apiKeys para que coincida con el complemento de OAuth.
• 143488312: se solucionó un problema en el que se agregaban espacios iniciales o finales en el ID de cliente. hizo que la creación de la lista de productos de JWT quedara vacía para el token de OAuth y Solicitudes de clave de API.
• 145640807 y 147579179: Se agregó una función nueva que permite una Edge Microgateway especial. llamada “el sincronizador” para recuperar datos de configuración de Apigee Edge y escribirlos a una base de datos local de Redis. Luego, se pueden configurar otras instancias de micropuertas de enlace para que lean su de configuración de la base de datos. Esta función agrega un nivel de resiliencia a Edge Microgateway. Permite que las instancias de micropuertas de enlace se inicien y funcionen sin necesidad de comunicarse con Apigee Edge Para obtener más información, consulta Uso del sincronizador.

  Actualmente, la función del sincronizador es compatible con Redis 5.0.x.

Versión 3.0.x

Correcciones de errores y mejoras v.3.0.x

3.0.10

El viernes 8 de noviembre, lanzamos las siguientes correcciones y mejoras en Edge Microgateway

Versiones de los componentes:

En la siguiente tabla, se indican los números de versión para los proyectos de componentes individuales asociadas con Edge Microgateway 3.0.10. Ten en cuenta que, como cada componente es un proyecto independiente, Es posible que los números de versión no coincidan con la versión principal del producto:

Mejoras y correcciones de errores:

• 142677575: se realizó una actualización de funciones para que el patrón coincida con las rutas de acceso de los recursos. que se usa en los productos de API para Edge Microgateway ahora se alinea con la coincidencia de patrones de la ruta de acceso del recurso que usa Apigee Edge, como se describe en La configuración del comportamiento de la ruta de acceso del recurso “/”, “/*” y “/**”.

  Nota: Si usas un patrón de recursos compuestos como /*/2/**, debe asegurarse de que el proxy edgemicro_auth se agregue a un producto de API independiente. Luego, debes incluir ese producto en la app de desarrollador del proxy, como se muestra en la siguiente captura de pantalla:

  

  Nota: La propiedad de configuración features.isSingleForwardSlashBlockingEnabled, como se describe en No se admite la configuración del comportamiento de la ruta de acceso del recurso “/”, “/*” y “/**” para Edge Microgateway.

• 143740696: Cambió la estructura de configuración de quotas (consulta también). las notas de la versión 3.0.9). El quotas se usa para configurar el complemento de cuotas. El cambio en la estructura se realizó para mejorar la claridad de los elementos de configuración. Para configurar el complemento de cuota, usa la siguiente configuración de YAML. Ten en cuenta que de configuración se llama quotas. Para obtener detalles sobre la configuración individual de quotas propiedades, consulta Opciones de configuración para la cuota.

  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: se agregó una función nueva que te permite usar Redis como cuota. almacén de respaldo. Si useRedis es verdadero, entonces el elemento volos-quota-redis usado. Cuando es verdadera, la cuota se restringe solo a las instancias de Edge Microgateway que conectarse a Redis. Si es falso, el volos-quota-apigee se usa como almacén de respaldo, y el contador de cuotas es global. Para obtener más información, consulta Opciones de configuración para la cuota Por ejemplo:

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

• 140574210: el tiempo de vencimiento predeterminado para los tokens que genera edgemicro-auth ha cambiado de 108000 milisegundos (1.8 minutos) a 1800 segundos (30 minutos).
• 143551282: Para admitir organizaciones con SAML, el comando edgemicro genkeys tiene para incluir un parámetro ‑‑token. Este parámetro te permite usar un Es un token de OAuth para la autenticación en lugar de un nombre de usuario y una contraseña. Para obtener detalles, consulta Generación de claves

3.0.9

El viernes 11 de octubre, lanzamos las siguientes correcciones y mejoras en Edge Microgateway

Versiones de los componentes:

En la siguiente tabla, se indican los números de versión para los proyectos de componentes individuales asociadas con Edge Microgateway 3.0.9. Ten en cuenta que, como cada componente es un proyecto independiente, Es posible que los números de versión no coincidan con la versión principal del producto:

Mejoras y correcciones de errores:

• 141989374: un nuevo “fail open” se agregó la función para el complemento de cuota. Cuando esta función está habilitada, si se produce un error de procesamiento de cuota o si la "cuota aplicable" solicitud a Edge no puede actualizar los contadores de cuota remotos, la cuota se procesarán en función de recuentos locales solo hasta la próxima cuota remota exitosa de que ocurra la sincronización. En ambos casos, una marca quota-failed-open se establece en el objeto de la solicitud.

  Habilita la cuota “fail open” establece la siguiente configuración:

  quotas :
   failOpen : true

  Nota: Además, se cambió el nombre de la marca de objeto de solicitud fail-open del complemento de OAuth a oauth-failed-open

• 142093764: se realizó un cambio de configuración en el proxy edgemicro-auth. para evitar excesos de cuota. El cambio consiste en establecer el tipo de cuota en calendario. Para usar esta mejora, debes actualizar tu edgemicro-auth a la versión 3.0.7 o una posterior
• 142520568: Se agregó una función nueva para habilitar el registro del MP. ID (encargado del tratamiento de mensajes) en las respuestas de cuota. Para usar esta función, actualiza tu proxy edgemicro-auth a la versión 3.0.7 o posterior y establece la siguiente configuración:

  quotas:
    useDebugMpId: true

  Cuando se establece useDebugMpId, las respuestas de cuota de Edge contendrán el ID de MP. y se registrará con Edge Microgateway. Por ejemplo:

  {
      "allowed": 20,
      "used": 3,
      "exceeded": 0,
      "available": 17,
      "expiryTime": 1570748640000,
      "timestamp": 1570748580323,
      "debugMpId": "6a12dd72-5c8a-4d39-b51d-2c64f953de6a"
  }

3.0.8

El jueves 26 de septiembre, lanzamos las siguientes correcciones y mejoras a Edge Microgateway

Versiones de los componentes:

En la siguiente tabla, se indican los números de versión para los proyectos de componentes individuales asociadas con Edge Microgateway 3.0.8. Ten en cuenta que, como cada componente es un proyecto independiente, Es posible que los números de versión no coincidan con la versión principal del producto:

Mejoras y correcciones de errores:

• 140025210: un nuevo “fail open” se agregó el atributo. Esta función permite que el procesamiento de la API continúe si un token JWT vencido no se puede actualizar debido a un error de conexión que impide una llamada de verificación de clave de API exitosa al proxy edgemicro-auth

  La función permite establecer un período de gracia en el que el token anterior permanece en la caché y se vuelve a usar hasta que vence el período de gracia. Esta función permite que Edge Microgateway para continuar procesando solicitudes en caso de una falla temporal en la conexión. Cuándo se reanuda la conectividad y se realiza una llamada exitosa a la función Verificar la clave de API, se crea un nuevo token se recupera y reemplaza el JWT antiguo en la caché.

  Cómo configurar el nuevo "fail open" haz lo siguiente:

  1. Configura las siguientes propiedades en la estrofa oauth de Edge Microgateway de Terraform:

     oauth:
       failOpen: true
       failopenGraceInterval: time_in_seconds
       cacheKey: true
       ...

     Por ejemplo:

     oauth:
       failOpen: true
       failopenGraceInterval: 5
       cacheKey: true
       ...

     En este ejemplo, si no se puede actualizar, se usará el token anterior durante 5 segundos debido a un problema de conectividad. Después de 5 segundos, se mostrará un error de autenticación.

• 141168968: se realizó una actualización para incluir el correlation_id en todos los resultados de registro del complemento. Además, los niveles de algunos registros se cambiaron a error según sea necesario.
• 140193349: se actualizó el proxy edgemicro-auth para requerir Edge Microgateway. clave y secreto que se deben verificar en cada solicitud de verificación de la clave de API. Edge Microgateway tiene un para enviar siempre la clave y el secreto en cada solicitud de Verificar clave de API. Este cambio impide que los clientes obtengan un JWT con solo una clave de API.
• 140090250: se realizó una actualización a fin de agregar registros de diagnóstico para el procesamiento de cuota. Con este cambio, ahora es posible correlacionar el resultado del registro de quoto con el resto de Edge Microgateway los registros del sistema operativo.

3.0.7

El jueves 12 de septiembre, lanzamos las siguientes correcciones y mejoras en Edge Microgateway

Versiones de los componentes:

En la siguiente tabla, se indican los números de versión para los proyectos de componentes individuales asociadas con Edge Microgateway 3.0.7. Ten en cuenta que, como cada componente es un proyecto independiente, Es posible que los números de versión no coincidan con la versión principal del producto:

Mejoras y correcciones de errores:

• 140075602: se actualizó el complemento de OAuth para mostrar un código de estado 5xx en el que lo que sea apropiado. Antes, el complemento solo mostraba códigos de estado 4xx en todos que no son de 200. Para cualquier respuesta de mensaje que no sea un estado 200, Según el error, se mostrará un código 4xx o 5xx.

  Esta función está inhabilitada de forma predeterminada. Para habilitar esta función, agrega oauth.useUpstreamResponse: true a la configuración de Edge Microgateway. Por ejemplo:

  oauth:
    allowNoAuthorization: false
    allowInvalidAuthorization: false
    gracePeriod: 10
    useUpstreamResponse: true

• 140090623: en la versión 3.0.6, se agregó una nueva propiedad de configuración, quota.quotaUri. Establece esta propiedad de configuración si deseas administrar cuotas mediante edgemicro-auth que se implementa en tu organización. Si no se establece esta propiedad, el extremo de la cuota se usa de forma predeterminada en el extremo interno de Edge Microgateway. Por ejemplo:

  edge_config:
    quotaUri: https://%s-%s.apigee.net/edgemicro-auth

  En la versión 3.0.7, se actualizó edgemicro-auth para aceptar este nuevo configuración. Para usar la propiedad quotaUri, debes actualizar a la el proxy edgemicro-auth más reciente. Para obtener detalles, consulta Actualiza Edgemicro-auth proxy.

• 140470888: se agregó un encabezado de autorización. a las llamadas de cuota para proporcionar autenticación. Además, se modificó el proxy edgemicro-auth para quitar “organización” a partir del identificador de la cuota. Debido a que el extremo de cuota reside en de la organización del cliente, ya no será necesario el identificador de cuota.
• 140823165: el siguiente nombre de propiedad:

  edgemicro:
      keepAliveTimeout

  se documentó incorrectamente en la versión 3.0.6. El nombre de propiedad correcto es:

  edgemicro:
      keep_alive_timeout

• 139526406... Se corrigió un error por el que se producía un recuento incorrecto de la cuota si una app de desarrollador tenía varios productos. Ahora la cuota se aplica correctamente a cada producto en una app. que tiene varios productos. La combinación de “appName + productName” se usa como el identificador de cuota.

3.0.6

El jueves 29 de agosto, lanzamos las siguientes correcciones y mejoras en Edge Microgateway

• 138633700: se agregó una nueva propiedad de configuración, keepAliveTimeout. Esta propiedad permite que debes configurar el tiempo de espera de Edge Microgateway (en milisegundos). (Predeterminado: 5,000 milisegundos)

  Por ejemplo:

  edgemicro:
    keep_alive_timeout: 600

• 140090623: se agregó una nueva propiedad de configuración, quotaUri. Establecer esta configuración si quieres administrar cuotas a través del proxy edgemicro-auth que se implementado en tu organización. Si no se establece esta propiedad, el extremo de cuota se establece de forma predeterminada en el extremo interno de Edge Microgateway. Por ejemplo:

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

  Para utilizar esta función, primero debes implementar la última versión del edgemicro-auth proxy para tu organización. Para obtener más información, consulta Actualiza el proxy de Edgemicro-auth.

• 138722809: se agregó una nueva propiedad de configuración, stack_trace. Esta propiedad te permite controlar si no aparecen seguimientos de pila en los archivos de registro. Por ejemplo:

  stack_trace: false

  Si stack_trace se establece como true, el seguimiento de pila imprimirse en registros. Si se establece en false, la pila el registro no se imprimirán en los registros.

3.0.5

El jueves 15 de agosto, lanzamos las siguientes correcciones y mejoras en Edge Microgateway

• 139005279: se corrigió un problema por el que no se mostraba el comando edgemicro status. el número correcto de procesos trabajadores.
• 138437710: se solucionó un problema en la clase ExitCounter que impedía que se realizara para evitar que se escriban.

• 139064652: se agregó la capacidad de agregar niveles de registro trace y debug para el evento. y registros del sistema. Por ahora, solo se agregó la capacidad de agregar estos niveles de registro. Actualmente, los niveles de registro disponibles son info, warn y error.
• 139064616: El resultado del registro se estandarizó para todas las instrucciones de registro de la consola. Consola Las instrucciones de registro ahora incluyen estos atributos:
• Marca de tiempo
• Nombre del componente
• ID de proceso
• Mensaje de registro de la consola

• 138413755: se mejoraron los mensajes de registro relacionados con la clave JWT y los secretos para esta CLI comandos: cert, verify, upgradekvm, token, genkeys, revokeys, renamekey y configure.

• 138413577: agrega y mejora el manejo de errores para los tiempos de espera del servicio de backend.
• 138413303: se agregó y mejoró el manejo de errores para los tiempos de espera de respuesta y socket.
• 138414116: agrega y mejora el manejo de errores de “conexión rechazada” errores.

3.0.4

El jueves 1 de agosto, lanzamos las siguientes correcciones y mejoras en Edge Microgateway

• 134445926: se implementaron mejoras en la autenticación interna de Edge Microgateway.
• 137582169: se solucionó un problema por el que se iniciaban procesos no deseados. Los procesos adicionales causaba que los complementos se volvieran a cargar y usaba una memoria excesiva. Edge Microgateway ahora mantiene la cantidad de procesos dentro del límite esperado.
• 137768774. Registra las mejoras de los mensajes:
  • Se borraron los registros de transacciones (solicitud).
  • Se agregaron más mensajes de registro cuando fuera necesario.
  • Se trasladaron los mensajes de registro de transacciones (solicitud) del resultado de la consola a relevantes. archivo de registro.
  • Se actualizaron los registros de la consola para usar una función de registro centralizada.
• 138321133, 138320563: Cambio interno básico en el búfer de cuota para habilitar futuras mejoras de la cuota.

3.0.3

El martes 23 de julio, lanzamos las siguientes correcciones y mejoras para Edge Microgateway

• Mejoras de los registros: Los registros del entorno de ejecución existentes usan un nuevo eventLog() que captura y registra los datos del entorno de ejecución de forma de un conjunto de datos tengan un formato común. La información de registro incluye lo siguiente:
  • Marca de tiempo (ISO 8601: AAAA-MM-DDTHH:mm:ss.sssZ).
  • Nivel de registro (error, advertencia o información).
  • Nombre de host: El nombre de host solicitante del encabezado de la solicitud.
  • Process ID: si ejecutas un clúster de procesos de Node.js, este es el ID del el proceso en el que se produjo el registro.
  • Nombre de la organización de Apigee.
  • Nombre del entorno en la organización.
  • Nombre del proxy de API.
  • Dirección IP del cliente.
  • ID de cliente
  • ID de correlación (no establecido actualmente).
  • Nombre del componente de Edge Microgateway.
  • Mensaje personalizado: Algunos objetos pueden imprimir información adicional que se pasa. a esta propiedad de error.
  • Método de solicitud (si es una solicitud HTTP).
  • Código de estado de la respuesta (si es una solicitud HTTP).
  • Mensaje de error
  • Código de error: Si un objeto incluye un código de error, se imprime en esta propiedad.
  • Tiempo que le tomaste.
  • Sistema operativo marcador de fin de línea.

  Los valores de propiedad nulos dan como resultado corchetes vacíos, [].

  En el siguiente ejemplo, se muestra el formato del registro:

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

  (137770055)

• Rendimiento: No se filtraron los productos de API según el entorno. Esta edición se solucionó el problema. (135038879)
• Varias integraciones de pruebas funcionales y mejoras en la calidad del código.

3.0.2

El miércoles 3 de julio de 2019, lanzamos las siguientes correcciones y mejoras en Edge Microgateway

Calidad del código: Se revisó la calidad del código y se realizaron cambios en él cumplir con los estándares de calidad que solicitan los usuarios. Abordamos errores y advertencias en relación con la calidad del código. derivada de JSHint. Como resultado, se identificaron y repararon algunos errores reales de código. Todas las instancias de Apigee Edge Microgateway los módulos se sometieron a este proceso. Consulta los compromisos del 28 de junio y 2 de julio para microgateway-config, microgateway-core, microgateway-plugins y microgateway Todos los módulos con cambios en la calidad de código se probaron con herramientas internas que verifican la la ejecución de Edge Microgateway para casos de uso de los clientes.

3.0.1

El viernes 21 de junio de 2019, lanzamos las siguientes correcciones y mejoras en Edge Microgateway

• 134834551: Cambia las versiones compatibles de Node.js para Edge Microgateway
  (versiones compatibles con Node.js: 8 y 12; las versiones 7, 9 y 11 son experimentales)
• 134751883: Falla de Edge Microgateway cuando se vuelve a cargar con carga.
• 134518428: El extremo de productos para Edge Microgateway muestra el error 5XX si el patrón de filtro es incorrecto
• 135113408: los trabajadores deben reiniciarse si finalizan de forma inesperada.
• 134945852: tokenCacheSize no se usa en el complemento de OAuth.
• 134947757: configurar cacheTTL en el complemento de OAuth
• 135445171: El cálculo del período de gracia en OAuth no es correcto.
• Usa el módulo mencionado que se proporciona con la instalación de Edge Microgateway
• 135367906: auditoría de seguridad

Versión 2.5.x

Nuevas funciones y mejoras v.2.5.x

(Corregido 2.5.38, 07/06/2019)

Los JWT con formato incorrecto pueden hacer que los trabajadores fallen cuando se usa la caché de tokens. Fijos en el perímetro microgateway-plugins. (b/134672029).

(Se agregó 2.5.37) Agrega la opción de CLI edgemicro-cert -t.

La opción edgemicro cert -t te permite especificar un token OAuth para autentica las APIs de administración. Consulta también Administra certificados.

Se agregó compatibilidad con la depuración de Edge Microgateway con edgemicroctl.

Puedes usar la marca mgdebug con edgemicroctl. Consulta también Tareas de integración de Kubernetes.

Habilita una compilación de Windows para edgemicroctl(se agregó 2.5.35).

(Se agregó 2.5.31) Nueva API de Edgemicro-auth/token

Se agregó una nueva API de Edgemicro-auth/token que te permite pasar el cliente/secreto como un objeto codificado en Base64 Encabezado de autorización básica y otorga_type como parámetro del formulario. Consulta Cómo obtener tokens del portador directamente.

(Corregido 2.5.31) La configuración privada no respeta la marca del token

Se solucionó un problema relacionado con la configuración de Edge Microgateway para que use un token de acceso OAuth2 en Edge para La nube privada no funcionaba correctamente (no se respetó el token).

Docker: Compatibilidad con el uso de certificados autofirmados

(Agregado 2.5.29) Si usas una autoridad certificadora (AC) que no es de confianza de forma predeterminada Node.js, puedes usar el parámetro NODE_EXTRA_CA_CERTS cuando ejecutes un contenedor de Docker con Edge Microgateway. Para obtener más información, consulta Cómo usar una AC que no sea de confianza para Node.js.

Docker: compatibilidad con TLS

(Se agregó 2.5.29). Edge Microgateway que se ejecuta en un contenedor de Docker ahora admite TLS para entradas al servidor de Edge Microgateway (solicitudes del norte) y las solicitudes salientes de Edge Microgateway a una aplicación objetivo (solicitudes hacia el sur).

En los siguientes ejemplos, se explica en detalle cómo establecer estos parámetros de configuración de TLS:

• Ejemplo de configuración de TLS con dirección al norte
• Ejemplo de configuración de TLS en dirección sur

En estos ejemplos, aprenderás a usar el punto de activación del contenedor /opt/apigee/.edgemicro para realizar la carga. los certificados, a los que luego se hace referencia en el archivo de configuración de Edge Microgateway.

Docker: compatibilidad con proxy de solicitudes

Si ejecutas Edge Microgateway en un contenedor de Docker, puedes usar estas opciones para controlar cuando la micropuerta de enlace se ejecuta detrás de un firewall:

• HTTP_PROXY
• HTTPS_PROXY
• NO_PROXY

Para obtener más información, consulta Ejecuta Edge Micro como un contenedor de Docker.

Docker: Instrucciones actualizadas para el complemento

(Se agregó 2.5.27). Si ejecutas Edge Microgateway en un contenedor de Docker, ahora tienes dos opciones para la implementación de complementos. Una opción, que usa un punto de activación de Docker, es nueva. La otra opción ya existía, básicamente no cambia; Sin embargo, el Dockerfile se actualizó. Para obtener más información, consulta los siguientes vínculos:

• Opción A: Activa el directorio de complementos en un volumen (nuevo)
• Opción B: Compila los complementos en el contenedor (actualizado)

Nueva compatibilidad con tokens de OAuth para el comando de actualización de KVM

(Se agregó 2.5.27). Puedes usar un token de OAuth con el comando upgradekvm. Para obtener más información, consulta Actualiza el KVM.

Segrega API en Edge Analytics

(Se agregó 2.5.26). Las nuevas marcas de complemento de análisis te permiten segregar una ruta de acceso a la API específica para que aparezca como un proxy independiente en los paneles de Edge Analytics. Por ejemplo: Puedes separar las APIs de verificación de estado para evitar confundirlas con llamadas reales a las APIs. Para obtener más información, consulta Exclusión de rutas de acceso de Analytics.

Configura un proxy local

(Se agregó 2.5.25). Con un proxy local, no es necesario crear manualmente un proxy con reconocimiento de micropuertas de enlace en Apigee Edge En su lugar, microgateway usará el la ruta base del proxy local. Para obtener más información, consulta Cómo usar el modo de proxy local.

Cómo usar el modo independiente

(Se agregó 2.5.25). Puedes ejecutar Edge Microgateway sin conexión por completo de cualquier Dependencia de Apigee Edge. Esta situación, llamada modo independiente, te permite ejecutar y probar Edge Microgateway sin conexión a Internet, consulta Ejecuta Edge Microgateway en modo independiente.

Revocación de claves

(Se agregó 2.5.19). Se agregó un nuevo comando CLI que revoca las credenciales clave y secretas de una Configuración de Edge Microgateway.

edgemicro revokekeys -o [organization] -e [environment] -u [username] -k [key] -s [secret]

Compatibilidad con Docker

Ahora puedes descargar la versión más reciente de Edge Microgateway como una imagen de Docker (se agregó 2.5.19):

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

Asistencia de Kubernetes

Puedes implementar Edge Microgateway como un servicio o una puerta de enlace de sidecar frente a (se agregó 2.5.19). servicios implementados en un clúster de Kubernetes. Consulta lo siguiente: Descripción general de la integración de Edge Microgateway con Kubernetes.

Compatibilidad con la opción de nodelay de TCP

(Se agregó 2.5.16) Se agregó un nuevo parámetro de configuración, nodelay, a la configuración de Edge Micro.

De forma predeterminada, las conexiones TCP usan el protocolo Nagle para almacenar datos en búfer antes de enviarlos. Configurando nodelay como true, desactiva este comportamiento (los datos se activarán de inmediato con los datos cada vez se llama a socket.write()). Consulta también la documentación de Node.js documentación para obtener más detalles.

Para habilitar nodelay, edita el archivo de configuración de microconfiguración de Edge de la siguiente manera:

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

Nuevas opciones de CLI para la supervisión de Forever

(Se agregó 2.5.12). Se agregaron parámetros nuevos al comando edgemicro forever. Estos parámetros te permiten especificar la ubicación del archivo forever.json y permitirte iniciar o detener la configuración proceso en segundo plano. Consulta también Supervisión permanente

Ejemplos:

Sigue estos pasos para comenzar de forma permanente:

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

Para detener siempre, haz lo siguiente:

edgemicro forever -a stop

Rotación de claves de JWT

Se agregó una función nueva que permite rotar los pares de clave pública/privada que se utilizan para Generar los tokens JWT que se usan para la seguridad de OAuth en Edge Microgateway. Consulta Rotar claves JWT.

Filtrado de proxies de API descargados

De forma predeterminada, Edge Microgateway descarga todos los proxies de tu organización de Edge que comienzan con el prefijo de denominación “edgemicro_”. Puedes cambiar este valor predeterminado para descargar proxies cuyos nombres coinciden con un patrón. Consulta Filtra los proxies descargados.

Especifica productos sin proxies de API

En Apigee Edge, puedes crear un producto de API que no contenga ningún proxy de API. Esta configuración de producto permite que funcione una clave de API asociada con ese producto con cualquier con el proxy implementado en tu organización. A partir de la versión 2.5.4, Edge Microgateway es compatible con este producto configuración.

Compatibilidad con la supervisión permanente

Edge Microgateway tiene un archivo forever.json que puedes configurar para controlar cuántas veces y con qué intervalos se debe reiniciar Edge Microgateway Este archivo Configura un servicio llamado Always-monitor, que administra Forever de manera programática. Consulta Supervisión permanente

Administración central del archivo de microconfiguración de Edge

Si ejecutas varias instancias de Edge Microgateway, es posible que desees administrar sus parámetros de configuración desde una única ubicación. Para hacerlo, especifica un extremo HTTP en el que Edge Micro puede descargar su archivo de configuración. Consulta Especifica un extremo del archivo de configuración.

Compatibilidad con la opción de CLI para siempre

(Se agregó 2.5.8). Usa el comando edgemicro forever [package.json] para especificar la Ubicación del archivo forever.json Antes de agregar este comando, la configuración tenía que estar en el directorio raíz de Edge Microgateway.

Por ejemplo:

edgemicro forever ~/mydir/forever.json

Incorporación de la opción configUrl para volver a cargar el comando

(Se agregó 2.5.8). Ahora puedes usar la opción --configUrl o -u con el Comando edgemicro reload.

Período de gracia para las discrepancias de tiempo de JWT

(Se agregó 2.5.7). El uso de un atributo gracePeriod en la configuración de OAuth ayuda a evitar errores. debido a leves discrepancias entre el reloj del sistema y la columna No antes (nbf) o Emitida a la(s) (iat) veces que se especifica en el token de autorización JWT. Configura este atributo en la cantidad de segundos para permitir tales discrepancias. Consulta Atributos de OAuth.

(Se agregó 2.5.7). El uso de un atributo gracePeriod en la configuración de OAuth ayuda a evitar errores. debido a leves discrepancias entre el reloj del sistema y la columna No antes (nbf) o Emitida a la(s) (iat) veces que se especifica en el token de autorización JWT. Configura este atributo en la cantidad de segundos para permitir tales discrepancias. Consulta Atributos de OAuth.

Errores corregidos v2.5.x

• (Error #236) Se corrigió un error de ortografía al borrar la caché.
• (Error #234) Vuelve a cargar las fallas de Edge Microgateway 2.5.35.
• (Error 135) La referencia de host virtual "secure" no es válida cuando se usa el -v. Esta corrección modifica el proxy de Edgemicro-auth antes de la implementación en asegurarse de que los hosts virtuales coincidan exactamente con lo que se especifica en la "-v" marca. Además, puedes especificar cualquier cantidad y cualquier nombre para el host virtual (ya no se limita a de forma predeterminada y segura).
• (Error #141) El comando edgemicro reload no admite las opción del archivo de configuración -c. Ya corregimos el problema.
• (Problema #142) Edge Microgateway reclama un reclamo de criptografía obsoleta en el momento de la instalación. Ya corregimos el problema.
• (Problema n.o 145) La cuota no funciona con Edge Microgateway. Ya corregimos el problema.
• (Problema con la comunidad de Apigee: https://community.apigee.com/questions/33149/emg-jwt-token-validated-against-both-api-proxies-a.html#answer-33336) El token JWT se valida con los proxies de API y con el URI de recurso en OAuth. Este problema y solucionar el problema.
• (Problema de Apigee Community: https://community.apigee.com/questions/47846/microgateway-not-working-with-oauth.html) Microgateway no funciona con OAuth. Ya corregimos el problema.
• Se corrigió pidPath en Windows.
• (Error 157) Se corrigió el problema que causaba el siguiente mensaje de error: No se definió ReferenceError: deployProxyWithPassword.
• (Error n.o 169) Actualiza las dependencias de Node.js (auditoría de npm)
• El proxy edgemicro-auth ahora usa las políticas de Edge JWT. El proxy ya no depende Node.js para proporcionar compatibilidad con JWT.

Versión 2.4.x

Nuevas funciones y mejoras v.2.4.x

1. Configura un alias personalizado para el proxy de Edgemicro-Auth (PR 116)

Puedes cambiar la ruta base predeterminada para el proxy edgemicro-auth. De forma predeterminada, la ruta base es /edgemicro-auth. Para cambiarlo, usa la marca -x. en el comando edgemicro configure.

Ejemplo:

edgemicro configure -x /mypath …

2. Compatibilidad con comodines para las rutas de acceso base (PR 77)

Puedes usar uno o varios “*” comodines en la ruta base de un edgemicro_*. Por ejemplo, una ruta base de /team/*/members permite a los clientes llamar a https://[host]/team/blue/members y https://[host]/team/green/members sin necesidad de crear nuevos proxies de API para asistir a nuevos equipos. Ten en cuenta que /**/ no es no es compatible.

3. Se agregó la ruta de configuración personalizada a la CLI para la configuración de la nube privada (PR) 99)

De forma predeterminada, el archivo de configuración de microgateway se encuentra en ./config/config.yaml. En los comandos init, configure y start, ahora puedes especificar una ruta de configuración personalizada en la con las marcas -c o --configDir. Se solucionó un problema en el que no se reconoció un directorio de configuración personalizado para las instalaciones de la nube privada.

Ejemplo:

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

4. Respeta las variables *_PROXY (PR 61)

Si Edge Microgateway está instalado detrás de un firewall y no puede comunicarse con Apigee Edge en la nube pública, existen dos opciones que se deben considerar:

Opción 1:

La primera es establecer la opción Edgemicro: proxy_tunnel como verdadero en microgateway archivo de configuración:

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

Cuando proxy_tunnel es true, Edge Microgateway usa el protocolo CONNECT para crear un túnel para las solicitudes HTTP a través de una sola conexión TCP. (Lo mismo sucede si el variables de entorno para configurar el proxy estén habilitadas para TLS).

Opción 2:

La segunda opción es especificar un proxy y establecer proxy_tunnel como false en el archivo de configuración de microgateway. Por ejemplo:

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

En este caso, puedes configurar las siguientes variables para controlar los hosts de cada proxy HTTP que quieres usar o qué hosts no deben controlar los proxies de Edge Microgateway: HTTP_PROXY, HTTPS_PROXY y NO_PROXY. Puedes establecer NO_PROXY como una lista delimitada por comas de dominios que Edge Microgateway debería no con proxy. Por ejemplo:

export HTTP_PROXY='http://localhost:3786'
export HTTPS_PROXY='https://localhost:3786'

Para obtener más información sobre estas variables, consulta lo siguiente:

https://www.npmjs.com/package/request#controlling-proxy-behaviour-using-environment-variables

5. Establece un tiempo de espera personalizado para las solicitudes de destino (PR 57)

Puedes establecer un tiempo de espera personalizado para las solicitudes de destino con esta configuración:

edgemicro:
    request_timeout: 10

El tiempo de espera se configura en segundos. Si se agota el tiempo de espera, Edge Microgateway responde con un 504 código de estado.

6. Respetar los mensajes de estado HTTP personalizados en la respuesta objetivo (PR) 53)

Edge Microgateway respeta los mensajes de estado HTTP personalizados establecidos en la respuesta de destino. En las versiones anteriores, los mensajes de estado enviados desde el destino se anulaban con Node.js los valores predeterminados.

7. El encabezado X-Forwarded-For puede establecer la clave client_ip para Analytics

Si está presente, el encabezado X-Forwarded-For establecerá la La variable client_ip que se informa en Edge Analytics. Esta función te permite conocer la IP del cliente que envió una solicitud a Edge Microgateway

8. Cambios en el complemento de OAuth

El complemento de OAuth admite la verificación de claves de API y la verificación de tokens de acceso de OAuth. Antes este cambio, el complemento aceptó cualquier forma de seguridad. Con este cambio, solo podrás permitir uno de esos modelos de seguridad (al mismo tiempo que mantiene la retrocompatibilidad).

Los complementos de OAuth agregan dos marcas nuevas:

• allowOAuthOnly: si se configura como true, cada API debe llevar un encabezado de autorización con un token de acceso del portador.

• allowAPIKeyOnly: si se configura como true, cada API debe llevar Un encabezado x-api-key (o una ubicación personalizada) con una clave de API

Configura estas marcas en el archivo de configuración de Edge Microgateway de la siguiente manera:

oauth:
    allowNoAuthorization: false
    allowInvalidAuthorization: false
    keep-authorization-header: false
    allowOAuthOnly: false
    allowAPIKeyOnly: false

9. Se mejoró el proxy de Edgemicro-auth (PR 40)

Se realizaron mejoras en el proxy edgemicro-auth. Antes las claves almacenadas por el proxy en Edge Secure Store, una bóveda encriptada. Ahora, el proxy almacena las claves en el mapa de clave-valor encriptado (KVM) de Edge.

10. Reescribe la URL de destino predeterminada en un complemento (PR 74)

También puedes anular el puerto del extremo de destino y elegir entre HTTP y HTTPS. Modificar variables en el código del complemento: req.targetPort y req.targetSecure. Para elegir HTTPS, establece req.targetSecure como true; Para HTTP, configúralo como false. Si estableces req.targetSecure como true; consulta este debate conversación para obtener más información.

11. Compatibilidad inicial para la autenticación con token OAuth (PR) 125).

Puedes configurar Edge Microgateway para que use un token de OAuth para la autenticación en lugar de nombre de usuario/contraseña. Para usar un token de OAuth, emplea el siguiente parámetro en edgemicro configure:

-t, --token <token>

Por ejemplo:

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

Errores corregidos v2.4.3

• Se solucionó un problema por el que se requería una organización pagada para ejecutar correctamente el proxy de Edgemicro-Auth. Ahora, también puedes usar Edge Microgateway con organizaciones de prueba. (PR 5)
• Se solucionó un problema por el que la transmisión no terminaba de procesar datos, pero se hacían los controladores finales que se ejecuta de todas formas. Esto provocó que se enviara una respuesta parcial. (PR 71)
• Se solucionó un problema por el que no se actualizaba un directorio de configuración personalizado para las instalaciones de la nube privada reconocido. (PR 110)
• Se solucionó un problema con SSL bidireccional entre el cliente y Edge Microgateway. (PR 70)
• Se solucionó un problema por el que se requería una barra final en la ruta base del proxy para la clave de API. la verificación para funcionar correctamente. Ahora, no se necesita una barra final al final de la ruta base. (PR 48)

Versión 2.3.5

Nuevas funciones y mejoras v.2.3.5

Filtrado de proxy

Puedes filtrar qué proxies con reconocimiento de micropuertas de enlace procesará una instancia de Edge Microgateway. Cuando se inicia Edge Microgateway, se descargan todos los proxies que reconocen las micropuertas de enlace del organización a la que está asociada. Usa la siguiente configuración para limitar los proxies que microgateway procesará. Por ejemplo, esta configuración limita los proxies de microgateway se procesará en tres: edgemicro_proxy-1, edgemicro_proxy-2 y edgemicro_proxy-3:

proxies:
  - edgemicro_proxy-1
  - edgemicro_proxy-2
  - edgemicro_proxy-3

Enmascaramiento de datos de Analytics

Una configuración nueva permite evitar que se muestre información de la ruta de la solicitud en Edge de análisis de datos en la nube. Agrega lo siguiente a la configuración de microgateway para enmascarar el URI de solicitud o ruta de acceso de la solicitud. Ten en cuenta que el URI consta de las partes de la ruta de acceso y el nombre de host de la solicitud.

analytics:
  mask_request_uri: 'string_to_mask'
  mask_request_path: 'string_to_mask'

Versión 2.3.3

Nuevas funciones y mejoras v.2.3.3

A continuación, se detallan las nuevas funciones y mejoras de esta versión.

Cómo inhabilitar el sondeo de cambio automático

Para desactivar el sondeo de cambio automático, configura este atributo en microgateway configuración:

disabled_config_poll_interval: true

De forma predeterminada, el sondeo periódico recopila los cambios que se realizan en Edge (cambios en los productos, proxies compatibles con microgateway, etc.), así como los cambios realizados en el archivo de configuración local. Predeterminado el intervalo de sondeo es de 600 segundos (cinco minutos).

Reescritura de URLs de destino en complementos

Puedes anular la URL de destino predeterminada de forma dinámica en un complemento modificando estas variables. en el código del complemento: req.targetHostname y req.targetPath.

Nueva firma de la función del complemento

Se agregó una nueva firma de función del complemento que proporciona la respuesta de destino como una argumento. Esta adición facilita que los complementos accedan a la respuesta de destino.

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

Resultado de registro predeterminado simplificado

De forma predeterminada, el servicio de registro ahora omite el JSON de los proxies descargados, los productos y el JWT. Puedes cambiar la salida predeterminada de estos objetos estableciendo DEBUG=* cuando comiences Edge Microgateway. Por ejemplo:

DEBUG=* edgemicro start -o docs -e test -k abc123 -s xyz456

Se agregó una ruta de configuración personalizada a la CLI

De forma predeterminada, el archivo de configuración de microgateway se encuentra en ./config/config.yaml. En el init, configurar e iniciar comandos, ahora puedes especificar una ruta de configuración personalizada en la línea de comandos. Por ejemplo:

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

Errores corregidos v2.3.3

• Se corrigió una fuga de memoria que se producía durante las solicitudes o respuestas de gran tamaño.
• Se corrigió el orden de ejecución del complemento. Ahora se comporta de la manera en que se explica en la en la documentación de Google Cloud.
• El complemento acumulado-request ya no se bloquea en las solicitudes GET.
• Se solucionó un problema en el complemento de acumulación y respuesta en el que la falta de cuerpo de respuesta causaba errores.

Versión 2.3.1

Nota de instalación

Algunas versiones anteriores de Edge Microgateway te permiten instalar el software descargando un archivo ZIP . Estos archivos ZIP ya no son compatibles. Para instalar Edge Microgateway, debes usar los siguientes elementos:

npm install -g edgemicro

Consulta el tema de instalación para más detalles.

Nuevas funciones y mejoras v.2.3.1

A continuación, se detallan las nuevas funciones y mejoras de esta versión.

Filtrar proxies

Una configuración nueva te permite filtrar en qué proxies cargará Edge Microgateway inicio. Anteriormente, microgateway cargaba todos los proxies compatibles con microgateway (proxies denominados Edgemicro_*) extraído de la organización o el entorno de Edge que especificaste en Edgemicro configure. Esta nueva función te permite filtrar esta lista de proxies para que Edge Microgateway solo carga los que especifiques. Simplemente agrega el elemento de proxies a microgateway archivo de configuración de la siguiente manera:

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

Por ejemplo, supongamos que tienes 50 proxies edgemicro_* en tu perímetro org/env, incluidas las llamadas edgemicro_foo y edgemicro_bar. Puedes le indica a microgateway que use solo estos dos proxies de la siguiente manera:

edge micro:
proxies:
    - edgemicro_foo
    - edgemicro_bar

Al inicio, microgateway solo podrá llamar a los proxies especificados. Cualquier intento llamar a otros proxies con reconocimiento de micropuertas de enlace descargados de la organización o entorno de Edge den como resultado un error.

Establece encabezados de solicitud de destino en complementos

Existen dos patrones básicos que debes considerar si deseas agregar o modificar encabezados de solicitud de destino: una en la que la solicitud entrante contiene datos (como en una solicitud POST) y otra en la que no (como en una solicitud GET simple).

Consideremos un caso en el que la solicitud entrante contiene datos y quieres establecer una encabezados en la solicitud objetivo. En las versiones anteriores de Edge Microgateway, no era posible configura los encabezados de destino de manera confiable.

La clave para este patrón es, primero, acumular todos los datos entrantes del cliente. Luego, en la onend_request(), usa la nueva función request.setOverrideHeader(name, value) para personalizar los encabezados.

A continuación, se incluye un ejemplo de código de complemento en el que se muestra cómo hacerlo. Los encabezados configurados en onend_request se envían al 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);
    }

  };

}

Si la solicitud no incluye datos, puedes establecer encabezados de destino en la onrequest(). Este patrón no es nuevo; se documentó anteriormente y se usó en los complementos de muestra proporcionados con 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();
    }

Función de recarga sin tiempo de inactividad

Después de realizar un cambio en la configuración de Edge Microgateway, puedes cargar los archivos sin perder ningún mensaje. Con este cambio, Edge Microgateway siempre se inicia en modo de clúster, y se quitó la opción --cluster de edgemicro start kubectl.

Además, se agregaron tres comandos nuevos de la CLI. Debes ejecutar estos comandos desde la mismo directorio en el que se ejecutó el comando de Edgemicro start:

• edgemicro status: Comprueba si Edge Microgateway es en ejecución o no.
• edgemicro stop: Detén el clúster de Edge Microgateway.
• edgemicro reload: Vuelve a cargar Edge Microgateway. configuración sin tiempo de inactividad.

Recarga de configuración automática sin tiempo de inactividad

Edge Microgateway carga una configuración nueva de forma periódica y, si corresponde, ejecuta una recarga. cambió. El sondeo recoge todos los cambios realizados en Edge (cambios en los productos, reconocimiento de micropuertas proxies, etc.), así como los cambios realizados en el archivo de configuración local. El intervalo de sondeo predeterminado es 600 segundos (cinco minutos) Puedes cambiar el valor predeterminado en el archivo de configuración de microgateway como sigue:

edgemicro:
    config_change_poll_interval: [seconds]

Se agregó información de la versión a la CLI

Se agregó una marca --version a la CLI. Para obtener la versión actual de Edge, sigue estos pasos: Microgateway, usa:

edgemicro --version

Nuevas opciones de SSL del servidor de Edge Microgateway

Edge Microgateway ahora admite las siguientes opciones de SSL del servidor, además de key y cert:

Cómo enviar archivos de registro a stdout

Puedes enviar datos de registro a la salida estándar con un nuevo parámetro de configuración:

edgemicro:
  logging:
    to_console: true  

Consulta Administra archivos de registro.

Versión 2.1.2

A continuación, se detallan las nuevas funciones y mejoras de esta versión.

Permitir el extremo de API personalizado para la configuración

Existen nuevos extremos configurables para el proxy de autorización que admiten el uso de un de autenticación personalizado. Estos extremos son los siguientes:

• edgeconfig:verify_api_key_url
• edgeconfig:products

Para obtener detalles, consulta Usar un servicio de autenticación personalizado

Versión 2.1.1

A continuación, se detallan las nuevas funciones y mejoras de esta versión.

Implementa el proxy de autenticación multiplataforma compatible

Se mejoró la arquitectura del comando para implementar la autorización de Edge Microgateway. proxy a Edge es compatible con sistemas Windows.

Versión 2.1.0

Nuevas funciones y mejoras v.21.0

A continuación, se incluyen las nuevas funciones y mejoras:

Especifica las opciones de SSL/TLS del cliente

Puedes especificar opciones de cliente para las conexiones SSL/TSL a destinos con un nuevo conjunto de parámetros de configuración opciones de estado. Consulta Usa las opciones de SSL/TSL del cliente

Versión 2.0.11

Nota de instalación v2.0.11

Algunas versiones anteriores de Edge Microgateway te permiten instalar el software descargando un archivo ZIP . Estos archivos ZIP ya no son compatibles. Para instalar Edge Microgateway, debes usar los siguientes elementos:

npm install -g edgemicro

Consulta el tema de instalación para más detalles.

Nuevas funciones y mejoras v.2.0.11

A continuación, se incluyen las nuevas funciones y mejoras:

Cómo especificar un puerto en el inicio

El comando start te permite especificar un número de puerto para anular el puerto especificado en la de Terraform. También puedes especificar un número de puerto con la variable de entorno PORT. Consulta comando start para obtener más detalles.

De manera opcional, puedes conservar los encabezados de autenticación

Un nuevo parámetro de configuración, keepAuthHeader, te permite conservar el Encabezado de autorización enviado en la solicitud. Si se establece como verdadera, el encabezado Auth se transfiere al objetivo. Consulta oauth.

Capacidad para usar un servicio de autorización personalizado

Si quieres usar tu propio servicio personalizado para controlar la autenticación, cambia el authUri en el archivo de configuración de Edge Microgateway para que apunte a tu servicio. Para detalles, consulta Usar un servicio de autenticación personalizado

Versión 2.0.4

Edge Microgateway v.2.0.4 se lanzó el 25 de mayo de 2016.

Nuevas funciones y mejoras v2.0.4

A continuación, se detallan las nuevas funciones y mejoras de esta versión.

Compatibilidad con rutas de recursos en productos

Edge Microgateway ahora admite rutas de acceso a recursos en los productos. Las rutas de acceso a recursos te permiten restringir acceso a las APIs en función del sufijo de la ruta de acceso del proxy. Para obtener detalles sobre la creación de productos y la configuración rutas de acceso a recursos, consulta Crear API productos.

Compatibilidad con la instalación global de npm

Ahora puedes instalar Edge Microgateway con la opción npm -g (global). Para obtener más información al respecto, consulta la página de npm documentación.

Versión 2.0.0

Edge Microgateway v2.0.0 se lanzó el 18 de abril de 2016.

Nuevas funciones y mejoras v.2.0.0

A continuación, se detallan las nuevas funciones y mejoras de esta versión.

Servidor de proceso único

Edge Microgateway ahora es un servidor de procesos único. Ya no usa un modelo de dos procesos en la que un proceso (antes denominado “agente”) inicia Edge Microgateway, y el segundo el proceso de administración de recursos. La nueva arquitectura facilita la automatización y la creación de contenedores.

Archivos de configuración con espacio de nombres

A los archivos de configuración ahora se les asignan espacios de nombres mediante la organización y el entorno para que varias Las instancias de Microgateway pueden ejecutarse en el mismo host. Puedes encontrar los archivos de configuración en ~/.edgemicro después de ejecutar el comando de configuración de Edge Microgateway.

Nuevas variables de entorno

Ahora hay 4 variables de entorno: EDGEMICRO_ORG, EDGEMICRO_ENV, EDGEMICRO_KEY, EDGEMICRO_SECRET Si estableces estas variables en tu sistema, no es necesario que especifiques sus cuando usas la interfaz de línea de comandos (CLI) para configurar y, luego, iniciar Edge Microgateway

Configuración almacenada en caché

Edge Microgateway usa un archivo de configuración almacenado en caché si se reinicia sin una conexión a Apigee Edge.

Modo de clúster

Ahora hay opciones para iniciar Edge Microgateway en modo de clúster. El modo de clúster te permite usar de los sistemas de varios núcleos. La micropuerta de enlace emplea el módulo de clúster de Node.js para esta función. Para obtener más información, consulta la documentación de Node.js.

Errores corregidos v2.0.0

El ciclo de vida del evento de complemento ahora administra correctamente el código asíncrono que contiene código con un nuevo devolución de llamada.

Versión 1.1.2

Edge Microgateway v. 1.1.2 se lanzó el 14 de marzo de 2016.

Nuevas funciones y mejoras v.1.1.2

A continuación, se detallan las nuevas funciones y mejoras de esta versión.

Mejora del rendimiento

Edge Microgateway ahora usa correctamente el agente HTTP de Node.js para mejorar la agrupación de conexiones. Esta mejora el rendimiento y la estabilidad general bajo cargas altas.

Compatibilidad con el depurador remoto

Puedes configurar Edge Microgateway para que se ejecute con un depurador remoto, como node-inspector.

Nueva ubicación del archivo de configuración

Cuando configuras Edge Microgateway, el archivo agent/config/default.yaml ahora se copió en ~./edgemicro/config.yaml.

Rotación del archivo de registro

Un nuevo atributo de configuración te permite especificar un intervalo de rotación para Edge Microgateway los registros del sistema operativo.

Errores corregidos (v1.1.2)

Los siguientes errores se corrigieron en la versión 1.1.2.