خطای ناشناخته در پانل «امتحان کردن این میانای برنامه‌سازی کاربردی»

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

نشانه

فراخوانی API از درگاه توسعه‌دهنده یکپارچه‌شده با Unknown Error یا پاسخ خالی در پانل امتحان کردن این API ناموفق است.

پیام‌های خطا

ممکن است برای درخواست‌های میانای برنامه‌سازی کاربردی در درگاه یکپارچه، پاسخ خالی یا پیام خطای زیر را ببینید:

Unknown Error

در برگه ابزارهای توسعه‌دهندگان > کنسول، خطای زیر را خواهید دید: خطا:

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.

پیام خطای عمومی که در «ابزارهای توسعه‌دهندگان > برگه کنسول» دیده می‌شود به این صورت است:

علل احتمالی

دلیل: خطای خط‌مشی مدیریت‌نشده

تشخیص

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

نماگرفت‌های زیر پیام خطای نمونه و پیام موفقیت نمونه را نمایش می‌دهد.

پیام خطای نمونه در پانل امتحان کردن این میانای برنامه‌سازی کاربردی در درگاه یکپارچه و در پنجره ردیابی کارگزار:

مثال پیام موفقیت در درگاه یکپارچه امتحان کردن این میانای برنامه‌سازی کاربردی پانل و در پنجره پراکسی ردیابی:

وضوح

1. به‌جای تکیه کردن بر پیام خطای پیش‌فرض، باید قانون خطا پیاده‌سازی شود تا پاسخ خطا را مدیریت کند. خط‌مشی CORS «تخصیص پیام» را با سرایندهای مناسب اضافه کنید و آن را در FaultRule فراخوانی کنید.
2. گاهی اوقات ممکن است تعریف قانون خطا برای هر خطا امکان‌پذیر نباشد؛ بنابراین، می‌توان قانون خطای پیش‌فرضی را برای اجرای خط‌مشی 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 در ردیابی به‌صورت زیر باشد:
   *,*
یعنی هم سرور هدف و هم خط‌مشی CORS مربوط به AssignMessage مقدار آن را تنظیم می‌کنند.
4. این می‌تواند زمانی اتفاق بیفتد که کاربر از <Add> element برای Access-Control-Allow-Origin در خط‌مشی استفاده کرده باشد، یا خود زیرینه چندین مقدار را تنظیم کرده باشد.

مثال 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» نیاز دارید، به باید اطلاعات تشخیصی را جمع‌آوری کنید بروید.

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

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

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