22.03.14 – informacje o wersji Apigee Edge dla Public Cloud

Skrócono czas oczekiwania na utworzenie aplikacji, gdy w ładunku znajduje się wiele produktów API.

Skrócono czas wdrażania pakietu proxy z dużym plikiem zasobów OAS.

Użyj prawidłowego dozwolonego czasu trwania planu taryfowego freemium w Apigee Monetization.

Rozwiązaliśmy problem, który powodował, że Apigee Monetization nie uwzględniało czasu trwania freemium. Dzięki tej poprawce deweloperzy aplikacji mogą bezpłatnie korzystać z planu taryfowego przez skonfigurowany czas. Przed tą poprawką czas trwania był nieprawidłowo obliczany na backendzie. Zobacz Konfigurowanie planu freemium.

Uaktualnienie biblioteki SwaggerParser powoduje, że podczas wdrażania proxy dla zasady OASValidation zgłaszane są bardziej rygorystyczne błędy weryfikacji.

Rozwiązaliśmy problem, który powodował, że włączenie debugowania Apigee powodowało pomijanie przez środowisko wykonawcze niektórych zasad wykonywanych asynchronicznie.

Rozwiązaliśmy problem, który powodował, że w zasadzie GenerateJWT, gdy jako dodatkowe roszczenie nagłówka określono jwk, zasada nieprawidłowo obsługiwała ładunek.

Gdy między procesorem komunikatów a serwerem docelowym używany był serwer proxy przekazujący, w Analytics rejestrowano niespójne szczegóły docelowe. Szczegóły docelowe w Analytics były czasami szczegółami rzeczywistego celu, a czasami serwera proxy. Rozwiązaliśmy ten problem, aby szczegóły docelowe rejestrowane w Analytics zawsze były szczegółami rzeczywistego celu.

Rozwiązaliśmy problem w zasadzie DecodeJWT, który powodował, że gdy AdditionalClaims było deklarowane jako map, a roszczenie było dodawane wewnątrz <AdditionalClaims>....</AdditionalClaims>, zasada dekodowała je jako typy double zamiast integer.

Poprawiliśmy odporność i rejestrowanie kodu zarządzania DNS w procesorach komunikatów.

Rozwiązaliśmy problem, który powodował, że zasada VerifyJWT nie zezwalała na atrybut use:sig w kluczu publicznym JWKS. Teraz atrybut use:sig jest dozwolony.

Rozwiązaliśmy problem, który powodował, że żądania do wywołania Pythona we współdzielonym przepływie kończyły się niepowodzeniem z powodu błędu java.lang.NoClassDefFoundError.

Błędy weryfikacji OAS powodują teraz zwracanie stanu HTTP 400. Wcześniej zwracany był stan 500.

Różne aktualizacje zabezpieczeń i poprawki.

Rozwiązaliśmy problem, który powodował, że nieudane połączenie z serwerem Syslog mogło spowodować ponowne uruchomienie procesora komunikatów.

Rozwiązaliśmy problem, który powodował, że zasada JavaScript nie była wykonywana, jeśli próbowała zmodyfikować zmienną apigee_javascript.

Rozwiązaliśmy problem, który powodował, że zasada DeleteOAuthV2Info nie usuwała tokena dostępu.

Rozwiązaliśmy problem, który powodował, że procesor komunikatów czasami uruchamiał się prawidłowo, mimo że nie mógł wczytać wszystkich bazowych repozytoriów.

Rozwiązaliśmy problem, który powodował, że uprawnienia zawierające zarówno symbol wieloznaczny (*), jak i znak specjalny, np. przecinek (,), nie działały zgodnie z oczekiwaniami.

Wersja proxy zwracała błąd stanu HTTP 400, gdy była używana jako cel z LocalTargetConnection.

Procesor komunikatów będzie teraz ponownie używać istniejących docelowych adresów IP, jeśli podczas odświeżania pamięci podręcznej DNS nie uda się rozpoznać nazw DNS.

Zmienna przepływu servicecallout.requesturi jest prawidłowo odzwierciedlana, jeśli identyfikator URI jest tworzony przy użyciu wielu zmiennych.

Rozwiązaliśmy problem, który powodował, że zasada AccessControl zgłaszała błędy, gdy x-forwarded-for nagłówki zawierały ip:port format.

Rozwiązaliśmy problem, który powodował, że zasada JWS zgłaszała błąd steps.jws.GenerationFailed, gdy ostatni parametr JSON był pusty.