Nieznany błąd w tym panelu interfejsu API

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

Krótki opis problemu

Wywołanie interfejsu API ze zintegrowanego portalu dla deweloperów kończy się niepowodzeniem z powodu błędu Unknown Error lub pustą odpowiedzią w panelu Wypróbuj ten interfejs API.

Komunikaty o błędach

W zintegrowanym portalu możesz zobaczyć pustą odpowiedź lub ten komunikat o błędzie w przypadku żądań do interfejsu API:

Unknown Error

Na karcie Narzędzia dla programistów > Konsola zobaczysz ten błąd:

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.

Ogólny komunikat o błędzie, który widzisz na karcie Narzędzia dla programistów > Konsola, wygląda tak:

Możliwe przyczyny

Przyczyna	Opis	Instrukcje rozwiązywania problemów dotyczące
Błąd dotyczący nieobsłużonych zasad	Domyślna odpowiedź błędu jest wysyłana bez nagłówków CORS, gdy w przepływie środowiska wykonawczego żądania do interfejsu API wystąpi błąd jakiejkolwiek zasady.	Użytkownicy Edge Public Cloud
Wiele wartości parametru Access-Control-Allow-Origin	Użyj opcji Dodaj zamiast Ustaw w zasadach przypisywania wiadomości.	Użytkownicy Edge Public Cloud

Przyczyna: błąd dotyczący nieobsłużonych zasad

Diagnostyka

1. Sprawdź, czy problem występuje tylko wtedy, gdy spodziewana jest odpowiedź inna niż 2XX.
2. W przypadku nieudanych żądań sprawdź, czy w przepływie serwera proxy są zasady.
3. Prześledź żądanie i sprawdź, czy zasada z continueOnError="false" nie działa i zgłasza błąd.
1. Jeśli tak, sprawdź, czy zasada CORS w usłudze AssignMessage została wykonana w procesie odpowiedzi na błąd.
2. Jeśli nie, to jest przyczyną problemu.
   Wynika to z faktu, że gdy jakakolwiek zasada z elementem continueOnError="false" kończy się niepowodzeniem, żądanie wchodzi w przepływ odpowiedzi o błędzie. Jeśli w procesie odpowiadania na błędy nie występuje jawna obsługa błędów, zwracana jest domyślna odpowiedź błędu odpowiadająca zasadzie. Ta odpowiedź o błędzie nie ma żadnych nagłówków CORS. W związku z tym wywołanie interfejsu API ze zintegrowanego portalu dla programistów kończy się niepowodzeniem z wartością Unknown error.

Na poniższych zrzutach ekranu widać przykładowy komunikat o błędzie i przykładowy komunikat o powodzeniu.

Przykładowy komunikat o błędzie w panelu Wypróbuj ten interfejs API w zintegrowanym portalu i w oknie Trace serwera proxy:

Przykładowy komunikat o powodzeniu w zintegrowanym portalu Wypróbuj ten interfejs API i w oknie śledzenia serwera proxy:

Rozdzielczość

1. Zamiast polegać na domyślnym komunikacie o błędzie, trzeba wdrożyć regułę błędu do obsługi odpowiedzi o błędzie. Dołącz zasadę CORS z odpowiednimi nagłówkami i wywołaj ją w FaultRule.
2. Czasami zdefiniowanie reguły błędu dla każdego błędu może nie być możliwe. Dlatego można wdrożyć domyślną regułę błędu, aby wykonywać zasadę 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>

Przyczyna: wiele wartości parametru Access-Control-Allow-Origin

Diagnostyka

1. Sprawdź wartość nagłówka Access-Control-Allow-Origin w sesji śledzenia.
2. Nagłówek Access-Control-Allow-Origin pozwala ustawić tylko jedną wartość. Ustawienie więcej niż 1 wartości może spowodować problem CORS, a portal dla programistów nie będzie renderować żadnych odpowiedzi.
3. Jeśli wartość nagłówka Access-Control-Allow-Origin w logu czasu wygląda tak:
   *,*
, oznacza to, że zarówno serwer docelowy, jak i zasada CORS, która jest ustawiona na wartość AssignMessage.
4. Może się tak zdarzyć, gdy użytkownik użyje zasady <Add> element w zasadzie Access-Control-Allow-Origin lub gdy backend ustawi wiele wartości.

Przykładowy element Access-Control-Allow-Origin równy *,*:

Przykładowy element Access-Control-Allow-Origin równy *:

Przykład z użyciem parametru <Add>:

Przykład z użyciem parametru <Set>:

Rozdzielczość

1. Zalecamy użycie <Set> element (zamiast <Add> element) dla Access-Control-Allow-Origin, ponieważ dozwolona jest tylko 1 wartość.
2. Możesz też ustawić nagłówek Access-Control-Allow-Origin tylko w jednym miejscu: zasad CORS w usłudze AssignMessage lub na serwerze docelowym.

<?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>

Jeśli nadal będziesz potrzebować pomocy zespołu pomocy Apigee, przejdź do artykułu Wymagane jest zbieranie informacji diagnostycznych.

Musisz zebrać informacje diagnostyczne

Zbierz te informacje diagnostyczne, a następnie skontaktuj się z zespołem pomocy Apigee Edge:

• Nazwa organizacji
• Nazwa środowiska
• Nazwa serwera proxy interfejsu API
• Pełne polecenie curl użyte do odtworzenia błędu
• Plik śledzenia żądań interfejsu API
• Pełne dane wyjściowe odpowiedzi z serwera docelowego lub backendu wraz z rozmiarem ładunku