Lokalny WSDL nadal może wysłać SoapClient do sieci

Śledź przechodnie importy WSDL i XML Schema, gdy lokalna definicja usługi wciąż miesza wewnętrzne i zewnętrzne trasy proxy.

Lokalny service.wsdl nadal może sprawić, że SoapClient podczas konstruowania pobierze zdalne dokumenty. Uczynienie pierwszego pliku lokalnym usuwa tylko to pierwsze pobranie:

local service.wsdl
  → internal Common.xsd
  → external Types.xsd
       → another schema location

Zacznij od pierwszego nieudanego pobrania, przed pierwszym wywołaniem biznesowym SOAP. Wypisz każdy import WSDL i każdą lokalizację schematu, wraz z dokumentami, na które one z kolei wskazują. Zachowaj bazowy URL lub ścieżkę używaną do rozwiązywania każdego odwołania względnego. Oddziel hosty wewnętrzne od zasobów, które naprawdę potrzebują zewnętrznego proxy.

Jawny proxy SoapClient może wysłać wewnętrzny schemat przez pośrednika o innym widoku DNS lub innej polityce dostępu. Zmienna no_proxy na poziomie procesu nie dowodzi, że ta ścieżka ładowania ją czyta. Użyj opcji udokumentowanych dla Twojej wersji PHP; nazwanie opcji po zmiennej środowiskowej nie tworzy selektora dla każdego importu.

Aby wdrożyć definicje całkowicie lokalnie, pozyskaj zatwierdzone wersje całego zestawu zależności, zaktualizuj odpowiednie lokalizacje importów do lokalnego pakietu i zachowaj ich bazy ścieżek względnych. Wersjonuj te dokumenty razem, aby nowy główny WSDL nie używał nieaktualnych typów.

Nie ruszaj identyfikatorów przestrzeni nazw. Mogą wyglądać jak URL-e, ale identyfikują słownik schematu, a nie mówią ładowaczowi, skąd pobrać plik. Ich zamiana może zmienić kontrakt usługi.

Przetestuj ponownie konstruowanie z zapisanym stanem pamięci podręcznej: zbuforowane definicje mogą ukryć brakującą zależność na jednej maszynie. Nadpisanie URL usługi dotyczy późniejszego etapu, a niestandardowy __doRequest() obsługuje wymianę SOAP; nie należy zakładać, że którekolwiek z nich przepisuje lub przechwytuje wszystkie pobrania schematu w czasie konstruowania.

Powiązane artykuły