Azure Storage Java: proxyvägar för API- och tokenbegäranden
Kontrollera både Azure Storage-begäranden och tokenbegäranden för autentiseringsuppgifter när du konfigurerar en Java SDK-proxy.
Att konfigurera en proxy på en lagringsklients HTTP-transport besvarar en fråga: hur den transporten skickar lagringsbegäranden. En identitetsautentiseringsuppgift kan ha en annan HTTP-klient för att hämta token.
Den skillnaden förklarar en till synes vanlig motsägelse: lagringsslutpunkten nås via proxyn, men SDK:t misslyckas innan den förväntade åtgärden skickas. Felet kan höra till hämtning av autentiseringsuppgifter mot en identitetsslutpunkt.
Anteckna först vilket mål som misslyckades. Granska sedan HTTP-klienten som gavs till lagringsbyggaren och den konfiguration som autentiseringsuppgiftsimplementeringen använder. Följ de proxyalternativ som stöds för varje transport. För offentligt nåbara lagrings- och tokenslutpunkter på en tillåten offentlig proxyväg erbjuder HTTP-proxylistan slutpunktskandidater; anta inte att en byggares inställning omkonfigurerar varje objekt i programmet.
| Steg | Användbara bevis |
|---|---|
| Hämta token | Identitetsslutpunkt, vald klient, proxyutmaning eller anslutningsfel |
| Lagringsbegäran | Lagringsslutpunkt, konfigurerad pipeline, slutligt svar eller överföringsfel |
Håll proxykontot åtskilt från Azure-autentiseringsuppgiften. En lyckad proxyinloggning ger en väg; måljänsten auktoriserar fortfarande Azure-åtgärden.
Historiska svar använder flera generationer av Azure Storage Java-klasser, inklusive äldre OperationContext- och pipeline-API:er. Matcha ett exempel mot det SDK och den HTTP-transport som programmet använder nu. För Data Lake SDK visar en delad HTTP-klientkonfiguration för lagring och identitet båda byggarindata. Att återinföra en föråldrad klienttyp för att lösa ett proxyproblem skapar ännu en konfigurationsväg att felsöka.
Använd säkra slutpunktsidentifierare i loggar. Lagrings-URL:er kan innehålla åtkomsttoken, och en fullständig proxy-URL kan innehålla ett lösenord.