Masalah umum pada Apigee

Anda sedang melihat dokumentasi Apigee Edge.
Buka dokumentasi Apigee X.
info

Bagian berikut menjelaskan masalah umum pada Apigee Edge dan Edge untuk Private Cloud. Umumnya, masalah yang tercantum akan diperbaiki pada rilis mendatang.

Miscellaneous Edge known issues

The following sections describe miscellaneous known issues with Edge.

Area/Summary Known issues
Cache expire results in incorrect cachehit value

When the cachehit flow variable is used after the LookupCache policy, due to the way debug points are dispatched for asynchronous behavior, the LookupPolicy populates the DebugInfo object before the call back has executed, resulting in an error.

Workaround: Repeat the process (make second call) again right after the first call.

Setting InvalidateCache Policy PurgeChildEntries to true does not work correctly

Setting PurgeChildEntries in the InvalidateCache policy should purge the KeyFragment element values only but clears the entire cache.

Workaround: Use the KeyValueMapOperations policy to iterate cache versioning and bypass the need for cache invalidation.

Concurrent deployment requests for a SharedFlow or API proxy can result in an inconsistent state in the Management Server where multiple revisions are shown as deployed.

This can happen, for example, when concurrent runs of a CI/CD deployment pipeline occur using different revisions. To avoid this problem, avoid deploying API proxies or SharedFlows before the current deployment is complete.

Workaround: Avoid concurrent API proxy or SharedFlow deployments.

API call counts shown in Edge API Analytics might contain duplicate data.

Edge API Analytics can sometimes contain duplicate data for API calls. In that case the counts shown for API calls in Edge API Analytics are higher than the comparable values shown in third-party analytics tools.

Workaround: Export the analytics data and use the gateway_flow_id field to de-duplicate the data.

Masalah umum pada UI Edge

Bagian berikut menjelaskan masalah umum pada UI Edge.

Area/Ringkasan Masalah umum
Tidak dapat mengakses halaman Administrasi Zona SSO Edge dari menu navigasi setelah organisasi dipetakan ke zona identitas

Saat Anda menghubungkan organisasi ke zona identitas, Anda tidak lagi dapat mengakses halaman Administrasi Zona SSO Edge dari menu navigasi kiri dengan memilih Admin > SSO.

Solusi: Buka halaman secara langsung menggunakan URL berikut: https://apigee.com/sso

Konfigurasi TLS Edge UI

Opsi TLS_DISABLED_ALGO dan TLS_ENABLED_CIPHERS tidak berfungsi dengan benar.

Solusi: Ikuti langkah-langkah di bawah untuk mengaktifkan sandi tertentu untuk UI Edge:

  1. Buka file konfigurasi /opt/apigee/etc/edge-ui.d/SSL.sh.
  2. Tambahkan properti -Djdk.tls.server.cipherSuites dengan daftar cipher suite yang dipisahkan koma dalam notasi IANA di dalam UI_OPTIONS. Contoh:
    UI_OPTIONS=" -Dhttp.port=disabled -Dhttps.port=9433 -Dhttps.keyStoreType=JKS -Dhttps.keyStore=/opt/apigee/customer/conf/keystore.jks -Dplay.http.sslengineprovider=services.CustomSSLEngineProvider -Dhttps.keyStorePasswordEncrypted=mypass -Djdk.tls.server.cipherSuites=TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384"
  3. Simpan perubahan Anda pada file konfigurasi.
  4. Mulai ulang UI Edge:
    /opt/apigee/apigee-service/bin/apigee-service edge-ui restart

Known issues with the integrated portal

The following sections describe the known issues with the integrated portal.

Area Known issues
SmartDocs
  • Apigee Edge supports OpenAPI Specification 3.0 when you create specifications using the spec editor and publish APIs using SmartDocs on your portal, though a subset of features are not yet supported.

    For example, the following features from the OpenAPI Specification 3.0 are not yet supported:

    • allOf properties for combining and extending schemas
    • Remote references

    If an unsupported feature is referenced in your OpenAPI Specification, in some cases the tools will ignore the feature but still render the API reference documentation. In other cases, an unsupported feature will cause errors that prevent the successful rendering of the API reference documentation. In either case, you will need to modify your OpenAPI Specification to avoid use of the unsupported feature until it is supported in a future release.

    Note: Because the spec editor is less restrictive than SmartDocs when rendering API reference documentation, you may experience different results between the tools.

  • When using Try this API in the portal, the Accept header is set to application/json regardless of the value set for consumes in the OpenAPI Specification.
  • 138438484: Multiple servers are not supported.
SAML identity provider Single logout (SLO) with the SAML identity provider is not supported for custom domains. To enable a custom domain with a SAML identity provider, leave the Sign-out URL field blank when you configure SAML settings.
Portal admin
  • Simultaneous portal updates (such as page, theme, CSS, or script edits) by multiple users is not supported at this time.
  • If you delete an API reference documentation page from the portal, there is no way to recreate it; you'll need to delete and re-add the API product, and regenerate the API reference documentation.
  • When configuring the content security policy, it may take up to 15 minutes for changes to fully apply.
  • When customizing your portal theme, it may take up to 5 minutes for changes to fully apply.
Portal features
  • Search will be integrated into the integrated portal in a future release.

Masalah umum terkait Edge untuk Private Cloud

Bagian berikut menjelaskan masalah umum pada Edge untuk Private Cloud.

Area Masalah umum
Edge untuk Private Cloud 4.53.01 Penilaian Kerentanan NGINX (CVE-2026-42945)

Kerentanan (CVE-2026-42945) telah diungkapkan yang memengaruhi ngx_http_rewrite_module di NGINX. Alat pemindaian keamanan dapat menandai biner NGINX yang disertakan dengan Apigee Edge untuk Private Cloud karena modul ini dikompilasi secara statis ke dalam NGINX.

Dampak pada Apigee Edge untuk Private Cloud:

Apigee Edge untuk Private Cloud tidak terpengaruh oleh kerentanan ini dalam konfigurasi default yang dikirimkannya. Kemungkinan eksploitasi CVE-2026-42945 bergantung pada pola konfigurasi NGINX tertentu, terutama penggunaan direktif rewrite dalam urutan tertentu. Pola ini tidak ada dalam konfigurasi NGINX Apigee Edge untuk Private Cloud standar.

Tindakan Diperlukan:

  • Untuk Konfigurasi Default Apigee Edge untuk Private Cloud: Tidak ada patch, upgrade, atau perubahan operasional yang diperlukan. Temuan pemindai terkait CVE-2026-42945 dapat dianggap sebagai positif palsu untuk penginstalan default. Anda dapat menggunakan teks berikut untuk mendokumentasikan pengecualian ini dalam sistem manajemen kerentanan Anda:

    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.

  • Untuk Konfigurasi NGINX yang Disesuaikan: Jika Anda telah mengubah file konfigurasi NGINX secara manual dalam penginstalan Apigee Edge untuk Private Cloud (misalnya, di bagian /opt/nginx), Anda harus melakukan pemeriksaan mandiri berikut untuk memastikan penyesuaian Anda tidak secara tidak sengaja memperkenalkan pola yang rentan:
    1. Periksa direktif penulisan ulang: Di setiap node NGINX, jalankan perintah:
      sudo grep -rnI '^\s*rewrite\b' /opt/nginx
    2. Analisis Hasil:
      • Jika perintah tidak menampilkan output, berarti sistem Anda tidak terpengaruh.
      • Jika kecocokan ditemukan, tinjau setiap instance. Kerentanan ini hanya ada jika semua kondisi berikut terpenuhi untuk blok tertentu:
        • Perintah rewrite digunakan.
        • Segera diikuti oleh direktif rewrite, if, atau set lain dalam blok konfigurasi yang sama.
        • Grup tangkapan PCRE tanpa nama (misalnya, $1, $2, dll.) digunakan dalam direktif.
        • String pengganti dalam direktif berisi tanda tanya (?).
    3. Mitigasi (jika rentan): Jika semua kondisi di atas terpenuhi untuk bagian mana pun dari konfigurasi kustom Anda, lakukan mitigasi dengan:
      • Menghapus tanda tanya (?) dari string pengganti.
      • Menggunakan grup pengambilan PCRE bernama, bukan yang tidak bernama.
      • Mengevaluasi ulang kebutuhan untuk arahan berantai.
Edge untuk Private Cloud 4.53.00 440148595: Peringatan Pop-up Akhir Masa Pakai Ditampilkan Secara Berlebihan

Di Edge untuk Private Cloud 4.53.00 dan yang lebih baru, UI menampilkan pop-up peringatan"Akhir Siklus Proses" (EOL). Peringatan ini muncul
berulang kali dan tidak dapat dicegah atau dikurangi frekuensinya.

Saat ini tidak ada metode yang tersedia bagi pengguna untuk menonaktifkan atau mengurangi frekuensi peringatan EOL ini.

Edge untuk Private Cloud 4.53.01 Panggilan Java

Panggilan Java pelanggan yang mencoba memuat penyedia kriptografi Bouncy Castle menggunakan nama "BC" mungkin gagal karena penyedia default telah diubah menjadi Bouncy Castle FIPS untuk mendukung FIPS. Nama penyedia baru yang akan digunakan adalah "BCFIPS".

Edge untuk Private Cloud 4.53.00 Panggilan Java

Panggilan Java pelanggan yang mencoba memuat penyedia kriptografi Bouncy Castle menggunakan nama "BC" mungkin gagal karena penyedia default telah diubah menjadi Bouncy Castle FIPS untuk mendukung FIPS. Nama penyedia baru yang akan digunakan adalah "BCFIPS".

Update Mint Edge for Private Cloud 4.52.01

Masalah ini hanya memengaruhi pengguna yang menggunakan MINT atau telah mengaktifkan MINT di penginstalan Edge untuk Private Cloud.

Komponen yang terpengaruh: edge-message-processor

Masalah: Jika Anda mengaktifkan monetisasi dan menginstal 4.52.01 sebagai penginstalan baru atau mengupgrade dari versi Private Cloud sebelumnya, Anda akan mengalami masalah pada pemroses pesan. Jumlah thread terbuka akan meningkat secara bertahap yang menyebabkan kelelahan resource. Pengecualian berikut terlihat di system.log edge-message-processor:

Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread
Kerentanan HTTP/2 Apigee

Kerentanan Penolakan Layanan (DoS) baru-baru ini ditemukan di beberapa penerapan protokol HTTP/2 (CVE-2023-44487), termasuk di Apigee Edge untuk Private Cloud. Kerentanan ini dapat menyebabkan DoS pada fungsi pengelolaan API Apigee. Untuk mengetahui detail selengkapnya, lihat Buletin Keamanan Apigee GCP-2023-032.

Komponen router dan server pengelolaan Edge untuk Private Cloud diekspos ke internet dan berpotensi rentan. Meskipun HTTP/2 diaktifkan di port pengelolaan komponen khusus Edge lainnya dari Edge untuk Private Cloud, tidak ada komponen tersebut yang diekspos ke internet. Di komponen non-Edge, seperti Cassandra, Zookeeper, dan lainnya, HTTP/2 tidak diaktifkan. Sebaiknya lakukan langkah-langkah berikut untuk mengatasi kerentanan Edge untuk Private Cloud:

Ikuti langkah-langkah berikut jika Anda menggunakan Edge Private Cloud versi 4.51.00.11 atau yang lebih baru:

  1. Perbarui server pengelolaan:

    1. Di setiap node server pengelolaan, buka /opt/apigee/customer/application/management-server.properties
    2. Tambahkan baris ini ke file properti:
      conf_webserver_http2.enabled=false
    3. Mulai ulang komponen server pengelolaan:
      apigee-service edge-management-server restart
  2. Perbarui pemroses pesan:

    1. Di setiap node pemroses pesan, buka /opt/apigee/customer/application/message-processor.properties
    2. Tambahkan baris ini ke file properti:
      conf_webserver_http2.enabled=false
    3. Mulai ulang komponen pemroses pesan:
      apigee-service edge-message-processor restart
  3. Perbarui router:

    1. Di setiap node router, buka /opt/apigee/customer/application/router.properties
    2. Tambahkan baris ini ke file properti:
      conf_webserver_http2.enabled=false
    3. Mulai ulang komponen pemroses pesan:
      apigee-service edge-router restart
  4. Memperbarui QPID:

    1. Di setiap node QPID, buka /opt/apigee/customer/application/qpid-server.properties
    2. Tambahkan baris ini ke file properti:
      conf_webserver_http2.enabled=false
    3. Mulai ulang komponen pemroses pesan:
      apigee-service edge-qpid-server restart
  5. Memperbarui Postgres:

    1. Di setiap node Postgres, buka /opt/apigee/customer/application/postgres-server.properties
    2. Tambahkan baris ini ke file properti:
      conf_webserver_http2.enabled=false
    3. Mulai ulang komponen pemroses pesan:
      apigee-service edge-postgres-server restart

Ikuti langkah-langkah berikut jika Anda menggunakan Edge for Private Cloud versi yang lebih lama dari 4.51.00.11:

  1. Perbarui server pengelolaan:

    1. Di setiap node server pengelolaan, buka /opt/apigee/customer/application/management-server.properties
    2. Tambahkan dua baris berikut ke file properti:
      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false
    3. Mulai ulang komponen server pengelolaan:
      apigee-service edge-management-server restart
  2. Perbarui pemroses pesan:

    1. Di setiap node pemroses pesan, buka /opt/apigee/customer/application/message-processor.properties
    2. Tambahkan dua baris berikut ke file properti:
      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false
    3. Mulai ulang komponen pemroses pesan:
      apigee-service edge-message-processor restart
  3. Perbarui router:

    1. Di setiap node router, buka /opt/apigee/customer/application/router.properties
    2. Tambahkan dua baris berikut ke file properti:
      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false
    3. Mulai ulang komponen pemroses pesan:
      apigee-service edge-router restart
  4. Memperbarui QPID:

    1. Di setiap node QPID, buka /opt/apigee/customer/application/qpid-server.properties
    2. Tambahkan dua baris berikut ke file properti:
      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false
    3. Mulai ulang komponen pemroses pesan:
      apigee-service edge-qpid-server restart
  5. Memperbarui Postgres:

    1. Di setiap node Postgres, buka /opt/apigee/customer/application/postgres-server.properties
    2. Tambahkan dua baris berikut ke file properti:
      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false
    3. Mulai ulang komponen pemroses pesan:
      apigee-service edge-postgres-server restart
Upgrade Postgresql saat mengupdate ke versi 4.52

Apigee-postgresql mengalami masalah saat mengupgrade dari Edge untuk Private Cloud versi 4.50 atau 4.51 ke versi 4.52. Masalah ini terutama terjadi jika jumlah tabel lebih dari 500.

Anda dapat memeriksa jumlah total tabel di Postgres dengan menjalankan kueri SQL di bawah:

select count(*) from information_schema.tables

Solusi: Saat Mengupdate Apigee Edge 4.50.00 atau 4.51.00 ke 4.52.00, pastikan untuk melakukan langkah awal sebelum mengupgrade Apigee-postgresql.

Kebijakan LDAP

149245401: Setelan kumpulan koneksi LDAP untuk JNDI yang dikonfigurasi melalui resource LDAP tidak tercermin, dan default JNDI menyebabkan koneksi sekali pakai setiap kali. Akibatnya, koneksi dibuka dan ditutup setiap kali untuk penggunaan tunggal, sehingga membuat banyak koneksi per jam ke server LDAP.

Solusi:

Untuk mengubah properti pool koneksi LDAP, lakukan langkah-langkah berikut untuk menetapkan perubahan global di semua kebijakan LDAP.

  1. Buat file properti konfigurasi jika belum ada:
    /opt/apigee/customer/application/message-processor.properties
  2. Tambahkan kode berikut ke file (ganti nilai properti Java Naming and Directory Interface (JNDI) berdasarkan persyaratan konfigurasi resource LDAP Anda).
    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. Pastikan file /opt/apigee/customer/application/message-processor.properties dimiliki oleh apigee:apigee.
  4. Mulai ulang setiap pemroses pesan.

Untuk memverifikasi bahwa properti JNDI pool koneksi Anda diterapkan, Anda dapat melakukan tcpdump untuk mengamati perilaku pool koneksi LDAP dari waktu ke waktu.

Latensi Pemrosesan Permintaan Tinggi

139051927: Latensi pemrosesan proxy yang tinggi ditemukan di Message Processor memengaruhi semua Proxy API. Gejalanya mencakup penundaan 200-300 md dalam waktu pemrosesan dibandingkan waktu respons API normal dan dapat terjadi secara acak meskipun dengan TPS rendah. Hal ini dapat terjadi jika ada lebih dari 50 server target yang terhubung ke pemroses pesan.

Penyebab utama: Pemroses pesan menyimpan cache yang memetakan URL server target ke objek HTTPClient untuk koneksi keluar ke server target. Secara default, setelan ini ditetapkan ke 50 yang mungkin terlalu rendah untuk sebagian besar deployment. Jika deployment memiliki beberapa kombinasi org/env dalam penyiapan, dan memiliki sejumlah besar server target yang secara keseluruhan melebihi 50, URL server target akan terus dikeluarkan dari cache, sehingga menyebabkan latensi.

Validasi: Untuk menentukan apakah pengusiran URL server target menyebabkan masalah latensi, telusuri Message Processor system.logs untuk kata kunci "onEvict" atau "Eviction". Keberadaannya dalam log menunjukkan bahwa URL server target dikeluarkan dari cache HTTPClient karena ukuran cache terlalu kecil.

Solusi: Untuk Edge for Private Cloud versi 19.01 dan 19.06, Anda dapat mengedit dan mengonfigurasi cache HTTPClient, /opt/apigee/customer/application/message-processor.properties:

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

Kemudian, mulai ulang pemroses pesan. Lakukan perubahan yang sama untuk semua pemroses pesan.

Nilai 500 adalah contoh. Nilai optimal untuk penyiapan Anda harus lebih besar daripada jumlah server target yang akan dihubungkan oleh pemroses pesan. Tidak ada efek samping dari menyetel properti ini lebih tinggi, dan satu-satunya efeknya adalah peningkatan waktu pemrosesan permintaan proxy pemroses pesan.

Catatan: Edge untuk Private Cloud versi 50.00 memiliki setelan default 500.

Beberapa entri untuk peta nilai kunci

157933959: Penyisipan dan update serentak ke peta nilai kunci (KVM) yang sama yang dicakup ke tingkat organisasi atau lingkungan menyebabkan data tidak konsisten dan update hilang.

Catatan: Batasan ini hanya berlaku untuk Edge for Private Cloud. Edge for Public Cloud dan Hybrid tidak memiliki batasan ini.

Untuk solusi sementara di Edge untuk Private Cloud, buat KVM di cakupan apiproxy.