Azure Storage Java: proxy trasy pro požadavky API a tokenů
Při konfiguraci proxy pro Java SDK zkontrolujte jak požadavky Azure Storage, tak požadavky na tokeny přihlašovacích údajů.
Konfigurace proxy na HTTP transportu klienta úložiště odpovídá na jednu otázku: jak tento transport odesílá požadavky na úložiště. Přihlašovací údaj identity může mít jiného HTTP klienta pro získávání tokenů.
Tento rozdíl vysvětluje zdánlivě běžný rozpor: koncový bod úložiště je přes proxy dostupný, ale SDK selže dříve, než odešle očekávanou operaci. Selhání může patřit získávání přihlašovacích údajů proti koncovému bodu identity.
Nejprve zaznamenejte, která destinace selhala. Poté prozkoumejte HTTP klienta předaného tvůrci úložiště a konfiguraci, kterou používá implementace přihlašovacích údajů. Postupujte podle podporovaných možností proxy každého transportu. Pro veřejně dostupné koncové body úložiště a tokenů na povolené trase veřejného proxy nabízí seznam HTTP proxy kandidáty koncových bodů; nepředpokládejte, že nastavení jednoho tvůrce překonfiguruje každý objekt v aplikaci.
| Fáze | Užitečné důkazy |
|---|---|
| Získání tokenu | Koncový bod identity, zvolený klient, výzva proxy nebo chyba připojení |
| Požadavek na úložiště | Koncový bod úložiště, nakonfigurovaný pipeline, konečná odpověď nebo selhání přenosu |
Udržujte účet proxy oddělený od přihlašovacích údajů Azure. Úspěšné přihlášení k proxy uděluje trasu; cílová služba stále autorizuje operaci Azure.
Historické odpovědi používají několik generací tříd Azure Storage Java, včetně starších API OperationContext a pipeline. Příklad slučte se SDK a HTTP transportem, které aplikace právě používá. Pro Data Lake SDK společné nastavení HTTP klienta pro úložiště a identitu ukazuje oba vstupy tvůrce. Znovuzavedení zastaralého typu klienta k vyřešení problému s proxy vytváří další cestu konfigurace k ladění.
V protokolech používejte bezpečné identifikátory koncových bodů. Adresy URL úložiště mohou obsahovat přístupové tokeny a úplná adresa URL proxy může obsahovat heslo.