Problemi noti di Apigee

Quando la variabile di flusso cachehit viene utilizzata dopo il criterio LookupCache, a causa del modo in cui vengono inviati i punti di debug per il comportamento asincrono, LookupPolicy compila l'oggetto DebugInfo prima dell'esecuzione del callback, generando un errore.

Soluzione:ripeti la procedura (effettua la seconda chiamata) subito dopo la prima chiamata.

L'impostazione di PurgeChildEntries nel criterio InvalidateCache dovrebbe eliminare solo i valori dell'elemento KeyFragment, ma cancella l'intera cache.

Soluzione alternativa: utilizza il criterio KeyValueMapOperations per eseguire l'iterazione del versionamento della cache e aggirare la necessità di annullare la convalida della cache.

Questo può accadere, ad esempio, quando vengono eseguite in modo simultaneo pipeline di deployment CI/CD utilizzando revisioni diverse. Per evitare questo problema, evita di eseguire il deployment di proxy API o SharedFlow prima del completamento dell'attuale deployment.

Soluzione alternativa:evita i deployment simultanei di proxy API o SharedFlow.

A volte Edge API Analytics può contenere dati duplicati per le chiamate API. In questo caso, i conteggi mostrati per le chiamate API in Edge API Analytics sono superiori ai valori paragonabili mostrati negli strumenti di analisi di terze parti.

Soluzione alternativa: esporta i dati di analisi e utilizza il campo gateway_flow_id per deduplicare i dati.

• Apigee Edge supporta la specifica OpenAPI 3.0 quando crei specifiche utilizzando l'editor delle specifiche e pubblichi API utilizzando SmartDocs sul tuo portale, anche se un sottoinsieme di funzionalità non è ancora supportato.

  Ad esempio, le seguenti funzionalità della specifica OpenAPI 3.0 non sono ancora supportate:

  • Proprietà allOf per combinare ed estendere gli schemi
  • Riferimenti remoti

  Se nella specifica OpenAPI viene fatto riferimento a una funzionalità non supportata, in alcuni casi gli strumenti la ignorano, ma visualizzano comunque la documentazione di riferimento dell'API. In altri casi, una funzionalità non supportata causerà errori che impediscono il rendering corretto della documentazione di riferimento dell'API. In entrambi i casi, dovrai modificare la specifica OpenAPI per evitare di utilizzare la funzionalità non supportata finché non sarà supportata in una release futura.

  Nota: poiché l'editor delle specifiche è meno restrittivo di SmartDocs durante il rendering della documentazione di riferimento dell'API, potresti riscontrare risultati diversi tra gli strumenti.

• Quando utilizzi Prova questa API nel portale, l'intestazione Accept è impostata su application/json indipendentemente dal valore impostato per consumes nella specifica OpenAPI.
• 138438484: Non sono supportati più server.

• Al momento non sono supportati gli aggiornamenti simultanei del portale (ad esempio modifiche a pagine, temi, CSS o script) da parte di più utenti.
• Se elimini una pagina di documentazione di riferimento dell'API dal portale, non è possibile ricrearla. Dovrai eliminare e aggiungere nuovamente il prodotto API e rigenerare la documentazione di riferimento dell'API.
• Quando configuri i criteri di sicurezza dei contenuti, l'applicazione completa delle modifiche può richiedere fino a 15 minuti.
• Quando personalizzi il tema del portale, l'applicazione completa delle modifiche potrebbe richiedere fino a 5 minuti.

• La ricerca verrà integrata nel portale integrato in una versione futura.

È stata rilevata una vulnerabilità (CVE-2026-42945) che interessa ngx_http_rewrite_module in NGINX. Gli strumenti di scansione della sicurezza potrebbero contrassegnare i file binari NGINX inclusi in Apigee Edge for Private Cloud perché questo modulo viene compilato staticamente in NGINX.

Impatto su Apigee Edge for Private Cloud:

Apigee Edge for Private Cloud non è interessato da questa vulnerabilità nella sua configurazione predefinita. L'exploitability di CVE-2026-42945 dipende da pattern di configurazione NGINX specifici, in particolare dall'uso della direttiva rewrite in una sequenza specifica. Questi pattern non sono presenti in nessuna configurazione NGINX standard di Apigee Edge for Private Cloud.

Azione richiesta:

• Per le configurazioni predefinite di Apigee Edge for Private Cloud: non sono richieste patch, upgrade o modifiche operative. I risultati dello scanner relativi a CVE-2026-42945 possono essere trattati come falsi positivi per le installazioni predefinite. Puoi utilizzare il seguente testo per documentare questa eccezione nel tuo sistema di gestione delle vulnerabilità:

  CVE-2026-42945 — Accepted exception (false positive for Apigee Edge for Private Cloud). Apigee Edge for Private Cloud does not use the rewrite directive in any shipped NGINX configuration. The vulnerable code path in ngx_http_rewrite_module is configuration-gated and is not reachable in the default Apigee Edge for Private Cloud deployment.

• Per le configurazioni NGINX personalizzate: se hai modificato manualmente i file di configurazione NGINX all'interno dell'installazione di Apigee Edge for Private Cloud (ad esempio in /opt/nginx), devi eseguire il seguente controllo automatico per assicurarti che le personalizzazioni non abbiano introdotto inavvertitamente il pattern vulnerabile:
  1. Controlla la direttiva rewrite: su ogni nodo NGINX, esegui il comando:

     sudo grep -rnI '^\s*rewrite\b' /opt/nginx

  2. Analizza i risultati:
     • Se il comando non restituisce alcun output, il sistema non è interessato.
     • Se vengono trovate corrispondenze, esamina ogni istanza. La vulnerabilità è presente solo se tutte le seguenti condizioni sono soddisfatte per un determinato blocco:
       • Viene utilizzata la direttiva rewrite.
       • È immediatamente seguita da un'altra direttiva rewrite, if o set all'interno dello stesso blocco di configurazione.
       • Nelle direttive viene utilizzato un gruppo di acquisizione PCRE senza nome (ad esempio $1, $2 e così via).
       • La stringa di sostituzione nella direttiva contiene un punto interrogativo (?).
  3. Mitigazione (se vulnerabile): se tutte le condizioni sopra indicate sono vere per una parte della configurazione personalizzata, esegui la mitigazione:
     • Rimuovendo il punto interrogativo (?) dalla stringa di sostituzione.
     • Utilizzando gruppi di acquisizione PCRE denominati anziché quelli senza nome.
     • Rivalutando la necessità delle direttive concatenate.

In Edge for Private Cloud 4.53.00 e versioni successive, l'UI mostra un "End of Life" (EOL) warning pop-up. Questo avviso viene visualizzato
ripetutamente e non è possibile impedirne la visualizzazione o ridurne la frequenza.

Al momento non è disponibile alcun metodo per disattivare o ridurre la frequenza di questo avviso di fine del ciclo di vita.

Questo problema riguarda solo gli utenti che utilizzano MINT o che hanno attivato MINT nelle installazioni di Edge for Private Cloud.

Componente interessato: edge-message-processor

Problema: se hai attivato la monetizzazione e stai installando la versione 4.52.01 come installazione pulita o stai eseguendo l'upgrade dalle versioni precedenti di Private Cloud, si verificherà un problema con i processori di messaggi. Si verificherà un aumento graduale del numero di thread aperti, con conseguente esaurimento delle risorse. La seguente eccezione viene visualizzata in edge-message-processor system.log:

Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread

Di recente è stata scoperta una vulnerabilità di tipo Denial of Service (DoS) in più implementazioni del protocollo HTTP/2 (CVE-2023-44487), inclusa Apigee Edge for Private Cloud. La vulnerabilità potrebbe causare un attacco DoS alla funzionalità di gestione delle API di Apigee. Per ulteriori dettagli, consulta il Bollettino sulla sicurezza di Apigee GCP-2023-032.

I componenti router e server di gestione di Edge for Private Cloud sono esposti a internet e potrebbero essere vulnerabili. Sebbene HTTP/2 sia abilitato sulla porta di gestione di altri componenti specifici di Edge for Private Cloud, nessuno di questi componenti è esposto a internet. Sui componenti non Edge, come Cassandra, Zookeeper e altri, HTTP/2 non è abilitato. Ti consigliamo di seguire questi passaggi per risolvere la vulnerabilità di Edge for Private Cloud:

• Passaggi per le versioni di Edge for Private Cloud 4.51.00.11 o successive
• Passaggi per le versioni di Edge for Private Cloud precedenti alla 4.51.00.11

Segui questi passaggi se utilizzi le versioni di Edge Private Cloud 4.51.00.11 o successive:

1. Aggiorna il server di gestione:

   1. Su ogni nodo del server di gestione, apri /opt/apigee/customer/application/management-server.properties
   2. Aggiungi questa riga al file delle proprietà:

      conf_webserver_http2.enabled=false

   3. Riavvia il componente del server di gestione:

      apigee-service edge-management-server restart

2. Aggiorna il processore di messaggi:

   1. Su ogni nodo del processore di messaggi, apri /opt/apigee/customer/application/message-processor.properties
   2. Aggiungi questa riga al file delle proprietà:

      conf_webserver_http2.enabled=false

   3. Riavvia il componente del processore di messaggi:

      apigee-service edge-message-processor restart

3. Aggiorna il router:

   1. Su ogni nodo del router, apri /opt/apigee/customer/application/router.properties
   2. Aggiungi questa riga al file delle proprietà:

      conf_webserver_http2.enabled=false

   3. Riavvia il componente del processore di messaggi:

      apigee-service edge-router restart

4. Aggiorna QPID:

   1. Su ogni nodo QPID, apri /opt/apigee/customer/application/qpid-server.properties
   2. Aggiungi questa riga al file delle proprietà:

      conf_webserver_http2.enabled=false

   3. Riavvia il componente del processore di messaggi:

      apigee-service edge-qpid-server restart

5. Aggiorna Postgres:

   1. Su ogni nodo Postgres, apri /opt/apigee/customer/application/postgres-server.properties
   2. Aggiungi questa riga al file delle proprietà:

      conf_webserver_http2.enabled=false

   3. Riavvia il componente del processore di messaggi:

      apigee-service edge-postgres-server restart

Segui questi passaggi se utilizzi le versioni di Edge for Private Cloud precedenti alla 4.51.00.11:

1. Aggiorna il server di gestione:

   1. Su ogni nodo del server di gestione, apri /opt/apigee/customer/application/management-server.properties
   2. Aggiungi le seguenti due righe al file delle proprietà:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Riavvia il componente del server di gestione:

      apigee-service edge-management-server restart

2. Aggiorna il processore di messaggi:

   1. Su ogni nodo del processore di messaggi, apri /opt/apigee/customer/application/message-processor.properties
   2. Aggiungi le seguenti due righe al file delle proprietà:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Riavvia il componente del processore di messaggi:

      apigee-service edge-message-processor restart

3. Aggiorna il router:

   1. Su ogni nodo del router, apri /opt/apigee/customer/application/router.properties
   2. Aggiungi le seguenti due righe al file delle proprietà:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Riavvia il componente del processore di messaggi:

      apigee-service edge-router restart

4. Aggiorna QPID:

   1. Su ogni nodo QPID, apri /opt/apigee/customer/application/qpid-server.properties
   2. Aggiungi le seguenti due righe al file delle proprietà:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Riavvia il componente del processore di messaggi:

      apigee-service edge-qpid-server restart

5. Aggiorna Postgres:

   1. Su ogni nodo Postgres, apri /opt/apigee/customer/application/postgres-server.properties
   2. Aggiungi le seguenti due righe al file delle proprietà:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Riavvia il componente del processore di messaggi:

      apigee-service edge-postgres-server restart

Apigee-postgresql presenta problemi con l'upgrade dalla versione 4.50 o 4.51 di Edge for Private Cloud alla versione 4.52. I problemi si verificano principalmente quando il numero di tabelle è superiore a 500.

Puoi controllare il numero totale di tabelle in Postgres eseguendo la seguente query SQL:

select count(*) from information_schema.tables

Soluzione temporanea: quando esegui l'aggiornamento di Apigee Edge 4.50.00 o 4.51.00 alla versione 4.52.00, assicurati di eseguire il passaggio preliminare prima di eseguire l'upgrade di Apigee-postgresql.

149245401: le impostazioni del pool di connessioni LDAP per JNDI configurate tramite la risorsa LDAP non vengono applicate e le impostazioni predefinite di JNDI causano connessioni monouso ogni volta. Di conseguenza, le connessioni vengono aperte e chiuse ogni volta per un singolo utilizzo, creando un numero elevato di connessioni all'ora al server LDAP.

Soluzione temporanea:

Per modificare le proprietà del pool di connessioni LDAP, segui i seguenti passaggi per impostare una modifica globale in tutti i criteri LDAP.

1. Crea un file di proprietà di configurazione, se non esiste già:

   /opt/apigee/customer/application/message-processor.properties

2. Aggiungi quanto segue al file (sostituisci i valori delle proprietà JNDI (Java Naming and Directory Interface) in base al requisito di configurazione della risorsa LDAP).

   bin_setenv_ext_jvm_opts="-Dcom.sun.jndi.ldap.connect.pool.maxsize=20
   -Dcom.sun.jndi.ldap.connect.pool.prefsize=2
   -Dcom.sun.jndi.ldap.connect.pool.initsize=2
   -Dcom.sun.jndi.ldap.connect.pool.timeout=120000
   -Dcom.sun.jndi.ldap.connect.pool.protocol=ssl"

3. Assicurati che il file /opt/apigee/customer/application/message-processor.properties sia di proprietà di apigee:apigee.
4. Riavvia ogni processore di messaggi.

Per verificare che le proprietà JNDI siano effettive, puoi eseguire un tcpdump per osservare il comportamento del pool di connessioni LDAP nel tempo.

139051927: le latenze elevate del trattamento dei proxy rilevate nel processore di messaggi interessano tutti i proxy API. I sintomi includono ritardi di 200-300 ms nei tempi di trattamento rispetto ai tempi di risposta API normali e possono verificarsi in modo casuale anche con TPS bassi. Questo può verificarsi quando il numero di server di destinazione a cui un processore di messaggi stabilisce connessioni è superiore a 50.

Causa principale: i processori di messaggi mantengono una cache che mappa l'URL del server di destinazione all'oggetto HTTPClient per le connessioni in uscita ai server di destinazione. Per impostazione predefinita, questa impostazione è impostata su 50, che potrebbe essere troppo bassa per la maggior parte dei deployment. Quando un deployment ha più combinazioni di organizzazione/ambiente in una configurazione, e un numero elevato di server di destinazione che superano complessivamente 50, gli URL dei server di destinazione continuano a essere rimossi dalla cache, causando latenze.

Convalida: per determinare se la rimozione dell'URL del server di destinazione sta causando il problema di latenza, cerca le parole chiave "onEvict" o "Eviction" nei log di sistema del processore di messaggi. La loro presenza nei log indica che gli URL dei server di destinazione vengono rimossi dalla cache HTTPClient perché la dimensione della cache è troppo piccola.

Soluzione temporanea: Per le versioni 19.01 e 19.06 di Edge for Private Cloud, puoi modificare e configurare la cache HTTPClient, /opt/apigee/customer/application/message-processor.properties:

conf/http.properties+HTTPClient.dynamic.cache.elements.size=500

Quindi riavvia il processore di messaggi. Apporta le stesse modifiche a tutti i processori di messaggi.

Il valore 500 è un esempio. Il valore ottimale per la tua configurazione deve essere maggiore di il numero di server di destinazione a cui il processore di messaggi si connetterà. Non ci sono effetti collaterali dall'impostazione di questa proprietà su un valore più alto e l'unico effetto sarebbe un miglioramento dei tempi di trattamento delle richieste proxy del processore di messaggi.

Nota: la versione 50.00 di Edge for Private Cloud ha l'impostazione predefinita di 500.

157933959: gli inserimenti e gli aggiornamenti simultanei alla stessa mappa chiave-valore (KVM) con ambito a livello di organizzazione o ambiente causano dati incoerenti e aggiornamenti persi.

Nota: questa limitazione si applica solo a Edge for Private Cloud. Edge for Public Cloud e Hybrid non hanno questa limitazione.

Per una soluzione temporanea in Edge for Private Cloud, crea la KVM nell'ambito apiproxy.