مشکلات شناخته شده با Apigee

هنگامی که متغیر جریان cachehit بعد از خط مشی LookupCache استفاده می شود، به دلیل نحوه ارسال نقاط اشکال زدایی برای رفتار ناهمزمان، LookupPolicy شی DebugInfo را قبل از اجرای تماس مجدد پر می کند، که منجر به خطا می شود.

راه حل: بلافاصله پس از اولین تماس، فرآیند را تکرار کنید (تماس دوم را برقرار کنید).

تنظیم PurgeChildEntries در خط مشی InvalidateCache باید فقط مقادیر عنصر KeyFragment را پاک کند اما کل حافظه پنهان را پاک می کند.

راه حل: از خط مشی KeyValueMapOperations برای تکرار نسخه کش و دور زدن نیاز به باطل کردن حافظه پنهان استفاده کنید.

برای مثال، زمانی که اجرای همزمان یک خط لوله استقرار CI/CD با استفاده از تجدید نظرهای مختلف انجام می شود، ممکن است اتفاق بیفتد. برای جلوگیری از این مشکل، از استقرار پراکسی های API یا SharedFlows قبل از تکمیل استقرار فعلی خودداری کنید.

راه حل: از استقرار پروکسی API یا SharedFlow همزمان خودداری کنید.

Edge API Analytics گاهی اوقات می‌تواند حاوی داده‌های تکراری برای تماس‌های API باشد. در آن صورت، تعداد نشان داده شده برای تماس های API در Edge API Analytics بیشتر از مقادیر قابل مقایسه نشان داده شده در ابزارهای تجزیه و تحلیل شخص ثالث است.

راه حل: داده های تجزیه و تحلیل را صادر کنید و از فیلد gateway_flow_id برای حذف داده ها استفاده کنید.

گزینه‌های TLS_DISABLED_ALGO و TLS_ENABLED_CIPHERS به درستی کار نمی‌کنند. برای فعال کردن رمزهای خاص برای رابط کاربری Edge، راه حل زیر را دنبال کنید:

1. فایل پیکربندی /opt/apigee/etc/edge-ui.d/SSL.sh را باز کنید.
2. ویژگی -Djdk.tls.server.cipherSuites را به همراه لیستی از مجموعه‌های رمز که با کاما از هم جدا شده‌اند، با نماد IANA در داخل UI_OPTIONS اضافه کنید. برای مثال:

   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. تغییرات خود را در فایل پیکربندی ذخیره کنید.
4. رابط کاربری Edge را مجدداً راه‌اندازی کنید:

   /opt/apigee/apigee-service/bin/apigee-service edge-ui restart

• Apigee Edge از OpenAPI Specification 3.0 پشتیبانی می‌کند زمانی که مشخصاتی را با استفاده از ویرایشگر مشخصات ایجاد می‌کنید و APIها را با استفاده از SmartDocs در پورتال خود منتشر می‌کنید ، اگرچه زیر مجموعه‌ای از ویژگی‌ها هنوز پشتیبانی نمی‌شوند.

  برای مثال، ویژگی‌های زیر از OpenAPI Specification 3.0 هنوز پشتیبانی نمی‌شوند:

  • allOf ویژگی ها برای ترکیب و گسترش طرحواره ها
  • مراجع از راه دور

  اگر یک ویژگی پشتیبانی‌نشده در مشخصات OpenAPI شما ارجاع داده شود، در برخی موارد ابزارها این ویژگی را نادیده می‌گیرند اما همچنان مستندات مرجع API را ارائه می‌کنند. در موارد دیگر، یک ویژگی پشتیبانی نشده باعث بروز خطاهایی می شود که از ارائه موفقیت آمیز اسناد مرجع API جلوگیری می کند. در هر صورت، باید مشخصات OpenAPI خود را تغییر دهید تا از استفاده از ویژگی پشتیبانی نشده تا زمانی که در نسخه بعدی پشتیبانی نشود، خودداری کنید.

  توجه : از آنجایی که ویرایشگر مشخصات در هنگام ارائه اسناد مرجع API محدودتر از SmartDocs است، ممکن است نتایج متفاوتی را بین ابزارها تجربه کنید.

• هنگام استفاده از Try this API در پورتال، هدر Accept بدون توجه به مقدار تنظیم شده برای consumes در مشخصات OpenAPI، روی application/json تنظیم می شود.
• 138438484: چند سرور پشتیبانی نمی شود.

• به‌روزرسانی‌های همزمان پورتال (مانند ویرایش صفحه، موضوع، CSS یا اسکریپت) توسط چندین کاربر در حال حاضر پشتیبانی نمی‌شود.
• اگر یک صفحه مستندات مرجع API را از پورتال حذف کنید، راهی برای ایجاد مجدد آن وجود ندارد. شما باید محصول API را حذف و دوباره اضافه کنید و اسناد مرجع API را دوباره ایجاد کنید.
• هنگام پیکربندی خط‌مشی امنیت محتوا ، ممکن است حداکثر 15 دقیقه طول بکشد تا تغییرات به طور کامل اعمال شوند.
• هنگام سفارشی کردن تم پورتال خود ، ممکن است تا 5 دقیقه طول بکشد تا تغییرات به طور کامل اعمال شوند.

• جستجو در نسخه آینده در پورتال یکپارچه ادغام خواهد شد.

یک آسیب‌پذیری ( CVE-2026-42945 ) که ماژول ngx_http_rewrite_module در NGINX را تحت تأثیر قرار می‌دهد، افشا شد. ابزارهای اسکن امنیتی ممکن است فایل‌های باینری NGINX موجود در Apigee Edge for Private Cloud را علامت‌گذاری کنند، زیرا این ماژول به صورت ایستا در NGINX کامپایل می‌شود.

تأثیر بر Apigee Edge برای ابر خصوصی:

Apigee Edge برای Private Cloud در پیکربندی پیش‌فرض و آماده‌ی خود تحت تأثیر این آسیب‌پذیری قرار نمی‌گیرد . قابلیت بهره‌برداری از CVE-2026-42945 به الگوهای خاص پیکربندی NGINX، به‌ویژه استفاده از دستورالعمل rewrite در یک توالی خاص، بستگی دارد. این الگوها در هیچ یک از پیکربندی‌های استاندارد Apigee Edge برای Private Cloud NGINX وجود ندارند.

اقدام مورد نیاز:

• برای پیکربندی‌های پیش‌فرض Apigee Edge برای ابر خصوصی: هیچ وصله، ارتقاء یا تغییر عملیاتی لازم نیست. یافته‌های اسکنر در مورد CVE-2026-42945 را می‌توان به عنوان مثبت کاذب برای نصب‌های پیش‌فرض در نظر گرفت. می‌توانید از متن زیر برای مستندسازی این استثنا در سیستم مدیریت آسیب‌پذیری خود استفاده کنید:

  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.

• برای پیکربندی‌های سفارشی NGINX: اگر فایل‌های پیکربندی NGINX را در نصب Apigee Edge for Private Cloud خود به صورت دستی تغییر داده‌اید (برای مثال، در /opt/nginx )، باید بررسی خودکار زیر را انجام دهید تا مطمئن شوید که سفارشی‌سازی‌های شما سهواً الگوی آسیب‌پذیر را ایجاد نکرده‌اند:
  1. بررسی دستورالعمل بازنویسی: در هر گره NGINX، دستور زیر را اجرا کنید:

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

  2. نتایج را تجزیه و تحلیل کنید:
     • اگر دستور هیچ خروجی برنگرداند، سیستم شما تحت تأثیر قرار نمی‌گیرد .
     • اگر تطابقی یافت شد، هر نمونه را بررسی کنید. این آسیب‌پذیری تنها در صورتی وجود دارد که تمام شرایط زیر برای یک بلوک مشخص برقرار باشد:
       • از دستورالعمل rewrite استفاده می‌شود.
       • بلافاصله پس از آن، دستورالعمل‌های rewrite ، if یا set دیگری در همان بلوک پیکربندی قرار می‌گیرند.
       • یک گروه ضبط PCRE بدون نام (برای مثال، $1 ، $2 و غیره) در دستورالعمل‌ها استفاده می‌شود.
       • رشته جایگزین در دستورالعمل شامل یک علامت سوال ( ? ) است.
  3. کاهش (در صورت آسیب‌پذیر بودن): اگر تمام شرایط فوق برای هر بخشی از پیکربندی سفارشی شما صادق است، با اقدامات زیر خطر را کاهش دهید:
     • حذف علامت سوال ( ? ) از رشته جایگزین.
     • استفاده از گروه‌های ضبط PCRE با نام به جای گروه‌های بدون نام.
     • ارزیابی مجدد نیاز به دستورالعمل‌های زنجیره‌ای.

در Edge برای Private Cloud نسخه ۴.۵۳.۰۰ و بالاتر، رابط کاربری یک پنجره هشدار «پایان عمر» (EOL) نمایش می‌دهد. این هشدار ظاهر می‌شود.
مکرراً رخ می‌دهد و نمی‌توان از آن جلوگیری کرد یا فراوانی آن را کاهش داد.

در حال حاضر هیچ روشی برای غیرفعال کردن یا کاهش دفعات نمایش این هشدار EOL برای کاربران وجود ندارد.

فراخوانی‌های جاوای مشتری که سعی در بارگذاری ارائه‌دهنده رمزنگاری Bouncy Castle با استفاده از نام "BC" دارند، ممکن است با شکست مواجه شوند، زیرا ارائه‌دهنده پیش‌فرض برای پشتیبانی از FIPS به Bouncy Castle FIPS تغییر یافته است. نام ارائه‌دهنده جدید مورد استفاده "BCFIPS" است.

فراخوانی‌های جاوای مشتری که سعی در بارگذاری ارائه‌دهنده رمزنگاری Bouncy Castle با استفاده از نام "BC" دارند، ممکن است با شکست مواجه شوند، زیرا ارائه‌دهنده پیش‌فرض برای پشتیبانی از FIPS به Bouncy Castle FIPS تغییر یافته است. نام ارائه‌دهنده جدید مورد استفاده "BCFIPS" است.

این مشکل فقط کسانی را تحت تأثیر قرار می‌دهد که از MINT استفاده می‌کنند یا MINT را در نصب‌های Edge برای Private Cloud فعال کرده‌اند.

مؤلفه آسیب‌دیده: پردازنده پیام لبه

مشکل: اگر قابلیت کسب درآمد را فعال کرده‌اید و نسخه ۴.۵۲.۰۱ را به عنوان یک نصب جدید یا ارتقا از نسخه‌های قبلی Private Cloud نصب می‌کنید، با مشکلی در پردازنده‌های پیام مواجه خواهید شد. افزایش تدریجی تعداد رشته‌های باز منجر به اتمام منابع می‌شود. استثنای زیر در edge-message-processor system.log مشاهده می‌شود:

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

اخیراً یک آسیب‌پذیری انکار سرویس (DoS) در چندین پیاده‌سازی پروتکل HTTP/2 (CVE-2023-44487)، از جمله در Apigee Edge برای Private Cloud، کشف شده است. این آسیب‌پذیری می‌تواند منجر به DoS در عملکرد مدیریت API Apigee شود. برای جزئیات بیشتر، به بولتن امنیتی Apigee GCP-2023-032 مراجعه کنید.

روتر و اجزای سرور مدیریت Edge for Private Cloud در معرض اینترنت هستند و می‌توانند به طور بالقوه آسیب‌پذیر باشند. اگرچه HTTP/2 در پورت مدیریت سایر اجزای مخصوص Edge در Edge for Private Cloud فعال است، اما هیچ یک از این اجزا در معرض اینترنت نیستند. در اجزای غیر Edge، مانند Cassandra، Zookeeper و سایر موارد، HTTP/2 فعال نیست. توصیه می‌کنیم برای رفع آسیب‌پذیری Edge for Private Cloud مراحل زیر را انجام دهید:

• مراحل مربوط به Edge برای نسخه‌های Private Cloud 4.51.00.11 یا جدیدتر
• مراحل مربوط به Edge برای نسخه‌های Private Cloud قدیمی‌تر از ۴.۵۱.۰۰.۱۱

اگر از نسخه‌های ۴.۵۱.۰۰.۱۱ یا جدیدتر Edge Private Cloud استفاده می‌کنید، این مراحل را دنبال کنید:

1. سرور مدیریت را به‌روزرسانی کنید:

   1. در هر گره سرور مدیریت، /opt/apigee/customer/application/management-server.properties را باز کنید.
   2. این خط را به فایل properties اضافه کنید:

      conf_webserver_http2.enabled=false

   3. مؤلفه سرور مدیریت را مجدداً راه اندازی کنید:

      apigee-service edge-management-server restart

2. پردازشگر پیام را به‌روزرسانی کنید:

   1. در هر گره پردازنده پیام، /opt/apigee/customer/application/message-processor.properties را باز کنید
   2. این خط را به فایل properties اضافه کنید:

      conf_webserver_http2.enabled=false

   3. مؤلفه پردازنده پیام را مجدداً راه اندازی کنید:

      apigee-service edge-message-processor restart

3. روتر را به‌روزرسانی کنید:

   1. در هر گره روتر، /opt/apigee/customer/application/router.properties را باز کنید.
   2. این خط را به فایل properties اضافه کنید:

      conf_webserver_http2.enabled=false

   3. مؤلفه پردازنده پیام را مجدداً راه اندازی کنید:

      apigee-service edge-router restart

4. به‌روزرسانی QPID:

   1. در هر گره QPID، /opt/apigee/customer/application/qpid-server.properties را باز کنید.
   2. این خط را به فایل properties اضافه کنید:

      conf_webserver_http2.enabled=false

   3. مؤلفه پردازنده پیام را مجدداً راه اندازی کنید:

      apigee-service edge-qpid-server restart

5. به‌روزرسانی پستگرس:

   1. در هر گره Postgres، /opt/apigee/customer/application/postgres-server.properties را باز کنید.
   2. این خط را به فایل properties اضافه کنید:

      conf_webserver_http2.enabled=false

   3. مؤلفه پردازنده پیام را مجدداً راه اندازی کنید:

      apigee-service edge-postgres-server restart

اگر از نسخه‌های قدیمی‌تر از ۴.۵۱.۰۰.۱۱ مرورگر اج برای فضای ابری خصوصی استفاده می‌کنید، این مراحل را دنبال کنید:

1. سرور مدیریت را به‌روزرسانی کنید:

   1. در هر گره سرور مدیریت، /opt/apigee/customer/application/management-server.properties را باز کنید.
   2. دو خط زیر را به فایل properties اضافه کنید:

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

   3. مؤلفه سرور مدیریت را مجدداً راه اندازی کنید:

      apigee-service edge-management-server restart

2. پردازشگر پیام را به‌روزرسانی کنید:

   1. در هر گره پردازنده پیام، /opt/apigee/customer/application/message-processor.properties را باز کنید
   2. دو خط زیر را به فایل properties اضافه کنید:

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

   3. مؤلفه پردازنده پیام را مجدداً راه اندازی کنید:

      apigee-service edge-message-processor restart

3. روتر را به‌روزرسانی کنید:

   1. در هر گره روتر، /opt/apigee/customer/application/router.properties را باز کنید.
   2. دو خط زیر را به فایل properties اضافه کنید:

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

   3. مؤلفه پردازنده پیام را مجدداً راه اندازی کنید:

      apigee-service edge-router restart

4. به‌روزرسانی QPID:

   1. در هر گره QPID، /opt/apigee/customer/application/qpid-server.properties را باز کنید.
   2. دو خط زیر را به فایل properties اضافه کنید:

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

   3. مؤلفه پردازنده پیام را مجدداً راه اندازی کنید:

      apigee-service edge-qpid-server restart

5. به‌روزرسانی پستگرس:

   1. در هر گره Postgres، /opt/apigee/customer/application/postgres-server.properties را باز کنید.
   2. دو خط زیر را به فایل properties اضافه کنید:

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

   3. مؤلفه پردازنده پیام را مجدداً راه اندازی کنید:

      apigee-service edge-postgres-server restart

Apigee-postgresql در ارتقاء از نسخه ۴.۵۰ یا ۴.۵۱ مرورگر Edge برای فضای ابری خصوصی به نسخه ۴.۵۲ با مشکل مواجه شده است. این مشکلات عمدتاً زمانی رخ می‌دهند که تعداد جداول بیشتر از ۵۰۰ باشد.

شما می‌توانید با اجرای کوئری SQL زیر، تعداد کل جداول موجود در Postgres را بررسی کنید:

select count(*) from information_schema.tables

راه حل: هنگام به‌روزرسانی Apigee Edge از نسخه‌های ۴.۵۰.۰۰ یا ۴.۵۱.۰۰ به ۴.۵۲.۰۰ ، حتماً مرحله مقدماتی را قبل از به‌روزرسانی Apigee-postgresql انجام دهید.

۱۴۹۲۴۵۴۰۱: تنظیمات مجموعه اتصال LDAP برای JNDI که از طریق منبع LDAP پیکربندی شده است، منعکس نمی‌شود و پیش‌فرض‌های JNDI هر بار باعث ایجاد اتصالات تک‌کاربره می‌شوند. در نتیجه، اتصالات هر بار برای یک بار استفاده باز و بسته می‌شوند و تعداد زیادی اتصال در ساعت به سرور LDAP ایجاد می‌کنند.

راه حل:

برای تغییر ویژگی‌های مجموعه اتصال LDAP، مراحل زیر را برای اعمال یک تغییر سراسری در تمام سیاست‌های LDAP انجام دهید.

1. اگر فایل ویژگی‌های پیکربندی از قبل وجود ندارد، آن را ایجاد کنید:

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

2. موارد زیر را به فایل اضافه کنید (مقادیر ویژگی‌های Java Naming و Directory Interface (JNDI) را بر اساس نیاز پیکربندی منابع 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. مطمئن شوید که فایل /opt/apigee/customer/application/message-processor.properties متعلق به apigee:apigee است.
4. هر پردازنده پیام را مجدداً راه اندازی کنید.

برای تأیید اینکه ویژگی‌های JNDI مربوط به connection pool شما فعال هستند، می‌توانید یک tcpdump اجرا کنید تا رفتار connection pool LDAP را در طول زمان مشاهده کنید.

۱۳۹۰۵۱۹۲۷: تأخیر بالای پردازش پروکسی که در پردازشگر پیام یافت می‌شود، بر همه پروکسی‌های API تأثیر می‌گذارد. علائم شامل تأخیر ۲۰۰ تا ۳۰۰ میلی‌ثانیه‌ای در زمان پردازش نسبت به زمان پاسخگویی معمول API است و می‌تواند به طور تصادفی حتی با TPS پایین نیز رخ دهد. این می‌تواند زمانی رخ دهد که بیش از ۵۰ سرور هدف وجود داشته باشد که پردازشگر پیام در آنها ارتباط برقرار می‌کند.

علت ریشه‌ای: پردازنده‌های پیام، یک حافظه پنهان (cache) را نگه می‌دارند که URL سرور هدف را برای اتصالات خروجی به سرورهای هدف، به شیء HTTPClient نگاشت می‌کند. به طور پیش‌فرض، این تنظیم روی ۵۰ تنظیم شده است که ممکن است برای اکثر پیاده‌سازی‌ها خیلی کم باشد. هنگامی که یک پیاده‌سازی دارای چندین ترکیب org/env در یک راه‌اندازی است و تعداد زیادی سرور هدف دارد که در مجموع از ۵۰ تجاوز می‌کنند، URLهای سرور هدف مرتباً از حافظه پنهان (cache) حذف می‌شوند و باعث تأخیر می‌شوند.

اعتبارسنجی: برای تعیین اینکه آیا حذف URL سرور هدف باعث مشکل تأخیر می‌شود یا خیر، در سیستم پردازشگر پیام system.logs کلمات کلیدی "onEvict" یا "Eviction" را جستجو کنید. وجود آنها در گزارش‌ها نشان می‌دهد که URL های سرور هدف از حافظه پنهان HTTPClient حذف می‌شوند زیرا اندازه حافظه پنهان بسیار کوچک است.

راه حل: برای نسخه‌های ۱۹.۰۱ و ۱۹.۰۶ مرورگر اج برای فضای ابری خصوصی، می‌توانید کش HTTPClient را ویرایش و پیکربندی کنید، /opt/apigee/customer/application/message-processor.properties :

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

سپس پردازشگر پیام را مجدداً راه‌اندازی کنید. همین تغییرات را برای همه پردازشگرهای پیام اعمال کنید.

مقدار ۵۰۰ یک مثال است. مقدار بهینه برای تنظیمات شما باید بیشتر از تعداد سرورهای هدفی باشد که پردازنده پیام به آنها متصل می‌شود. هیچ عارضه جانبی از تنظیم این ویژگی بالاتر وجود ندارد و تنها تأثیر آن بهبود زمان پردازش درخواست پروکسی پردازنده پیام خواهد بود.

توجه: نسخه ۵۰.۰۰ مرورگر اج برای فضای ابری خصوصی، تنظیمات پیش‌فرض ۵۰۰ را دارد.

۱۵۷۹۳۳۹۵۹: درج و به‌روزرسانی همزمان در یک نقشه ارزش کلیدی (KVM) که در سطح سازمان یا محیط قرار دارد، باعث داده‌های متناقض و از دست رفتن به‌روزرسانی‌ها می‌شود.

توجه: این محدودیت فقط برای Edge برای Private Cloud اعمال می‌شود. Edge برای Public Cloud و Hybrid این محدودیت را ندارند.

برای یک راه حل موقت در Edge برای Private Cloud، KVM را در محدوده apiproxy ایجاد کنید.