Konfiguracija proxyja na transportu HTTP odjemalca shrambe odgovarja na eno vprašanje: kako ta transport pošilja zahteve shrambe. Poverilnica identitete ima lahko drugega odjemalca HTTP za pridobivanje žetonov.

Ta razlika pojasnjuje na videz običajno protislovje: končna točka shrambe je dosegljiva prek proxyja, vendar SDK spodleti, preden pošlje pričakovano operacijo. Napaka lahko pripada pridobivanju poverilnic proti končni točki identitete.

Najprej zabeležite, kateri cilj je spodletel. Nato preglejte odjemalca HTTP, predanega graditelju shrambe, in konfiguracijo, ki jo uporablja izvedba poverilnic. Sledite podprtim možnostim proxyja vsakega transporta. Za javno dosegljive končne točke shrambe in žetonov na dovoljeni javni poti proxyja seznam proxyjev HTTP ponuja kandidate za končne točke; ne predpostavljajte, da nastavitev enega graditelja znova konfigurira vsak objekt v aplikaciji.

FazaKoristni dokazi
Pridobivanje žetonaKončna točka identitete, izbrani odjemalec, izziv proxyja ali napaka povezave
Zahteva za shramboKončna točka shrambe, konfigurirani cevovod, končni odgovor ali napaka prenosa

Račun proxyja hranite ločeno od poverilnice Azure. Uspešna prijava v proxy dodeli pot; ciljna storitev še vedno odobri operacijo Azure.

Zgodovinski odgovori uporabljajo več generacij razredov Azure Storage Java, vključno s starejšimi API OperationContext in cevovoda. Primer uskladite s SDK in transportom HTTP, ki ju aplikacija zdaj uporablja. Za SDK Data Lake skupna nastavitev odjemalca HTTP za shrambo in identiteto prikazuje oba vhoda graditelja. Ponovno uvajanje zastarelega tipa odjemalca za rešitev težave s proxyjem ustvari še eno pot konfiguracije za odpravljanje napak.

V dnevnikih uporabljajte varne identifikatorje končnih točk. URL-ji shrambe lahko vsebujejo žetone za dostop, popoln URL proxyja pa lahko vsebuje geslo.

Sorodni članki