خطای ناشناخته در Try this panel API

شما در حال مشاهده اسناد Apigee Edge هستید.
به مستندات Apigee X بروید . اطلاعات

علامت

تماس API از پورتال توسعه‌دهنده یکپارچه با Unknown Error یا پاسخ خالی در پنل Try this API با شکست مواجه می‌شود.

پیام های خطا

ممکن است یک پاسخ خالی یا پیام خطای زیر را برای درخواست های API در پورتال یکپارچه مشاهده کنید:

Unknown Error

در تب Developer Tools > Console ، خطای زیر را مشاهده خواهید کرد:

Access to XMLHTTPRequest at 'API_URL' from origin 'URL_of_Integrated_DevPortal'
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is
present on the requested resource.

یک پیام خطای عمومی همانطور که در تب Developer Tools > Console مشاهده می شود به شرح زیر است:

علل احتمالی

علت: خطای سیاست کنترل نشده

تشخیص

1. بررسی کنید که مشکل فقط در صورتی رخ دهد که پاسخ غیر 2XX مورد انتظار باشد.
2. برای درخواست‌های ناموفق، بررسی کنید که خط‌مشی‌هایی در جریان پروکسی وجود دارد.
3. درخواست را ردیابی کنید و بررسی کنید که آیا یک خط مشی با continueOnError="false" ناموفق است و خطا را افزایش می دهد.
1. اگر بله، بررسی کنید که آیا خط مشی AssignMessage CORS در جریان پاسخ به خطا اجرا شده است یا خیر.
2. اگر نه، پس دلیل این موضوع همین است.
   این به این دلیل است که وقتی هر خط مشی با عنصر continueOnError="false" ناموفق باشد، درخواست وارد جریان پاسخ خطا می شود. اگر در جریان پاسخ به خطا هیچ گونه رسیدگی صریحی به خطا وجود نداشته باشد، پاسخ خطای پیش‌فرض مربوط به خط‌مشی برگردانده می‌شود. این پاسخ خطا هیچ عنوان CORS ندارد. در نتیجه، تماس API از پورتال توسعه‌دهنده یکپارچه با Unknown error با شکست مواجه می‌شود.

اسکرین شات های زیر یک نمونه پیغام خطا و یک نمونه پیغام موفقیت را نشان می دهند.

نمونه پیام خطا در پورتال یکپارچه این پانل API و در پنجره Trace پروکسی را امتحان کنید:

نمونه پیام موفقیت در پورتال یکپارچه این پانل API و در پنجره Trace پروکسی را امتحان کنید:

قطعنامه

1. به جای تکیه بر پیام خطای پیش‌فرض، باید یک قانون خطا برای رسیدگی به پاسخ خطا اجرا شود. یک خط مشی AssignMessage CORS را با هدرهای مناسب اضافه کنید و آن را در FaultRule فراخوانی کنید.
2. در مواقعی ممکن است تعریف یک قانون خطا برای هر خطا امکان پذیر نباشد. بنابراین، یک قانون خطای پیش‌فرض می‌تواند برای اجرای سیاست AssignMessage CORS پیاده‌سازی شود:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ProxyEndpoint name="proxy-endpoint-name">
    <Description/>
    <!-- Add a default fault rule to add CORS -->
    <DefaultFaultRule name="fault-rule">
        <Step>
            <Name>add-cors</Name>
        </Step>
    </DefaultFaultRule>
    <FaultRules/>
    <!--
    <Flows />
    Rest of the proxy definition
    -->
</ProxyEndpoint>

علت: چندین مقدار برای Access-Control-Allow-Origin

تشخیص

1. مقدار هدر Access-Control-Allow-Origin را در یک جلسه ردیابی بررسی کنید.
2. هدر Access-Control-Allow-Origin اجازه می دهد تنها یک مقدار تنظیم شود. تنظیم بیش از یک مقدار می‌تواند باعث مشکل CORS شود و پورتال توسعه‌دهنده هیچ پاسخی را ارائه ندهد.
3. اگر مقدار هدر Access-Control-Allow-Origin در trace به نظر می رسد:
   *,*
این بدان معناست که هم سرور هدف و هم خط مشی AssignMessage CORS مقدار آن را تنظیم می کنند.
4. این ممکن است زمانی اتفاق بیفتد که کاربر <Add> element برای Access-Control-Allow-Origin در یک خط مشی استفاده کرده باشد، یا خود backend در حال تنظیم چندین مقدار باشد.

مثال Access-Control-Allow-Origin برابر با *,* :

مثال Access-Control-Allow-Origin برابر با * :

مثال با استفاده از <Add> :

مثال با استفاده از <Set> :

قطعنامه

1. رویکرد توصیه شده استفاده از <Set> element (به جای <Add> element ) برای Access-Control-Allow-Origin است زیرا فقط یک مقدار مجاز است.
2. همچنین، هدر Access-Control-Allow-Origin را فقط در یک مکان تنظیم کنید. خط مشی AssignMessage CORS یا سرور مورد نظر.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage async="false" continueOnError="false" enabled="true" name="set-cors">
    <DisplayName>Set CORS</DisplayName>
    <FaultRules/>
    <Properties/>
    <Set>
        <Headers>
            <Header name="Access-Control-Allow-Origin">*</Header>
        </Headers>
    </Set>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
    <AssignTo createNew="false" transport="http" type="response"/>
</AssignMessage>

اگر همچنان به کمک پشتیبانی Apigee نیاز دارید، به Must collect information diagnostic بروید.

باید اطلاعات تشخیصی را جمع آوری کرد

اطلاعات تشخیصی زیر را جمع آوری کنید و سپس با پشتیبانی Apigee Edge تماس بگیرید:

• نام سازمان
• نام محیط زیست
• نام پروکسی API
• دستور کامل curl که برای بازتولید خطا استفاده می شود
• فایل ردیابی برای درخواست های API
• خروجی کامل پاسخ از سرور هدف/باطن همراه با اندازه بار