A proxy beállítása egy tárolási ügyfél HTTP-transzportján egy kérdésre ad választ: hogyan küldi ez a transzport a tárolási kéréseket. Egy identitás-hitelesítő adatnak lehet másik HTTP-ügyfele a tokenek beszerzéséhez.

Ez a megkülönböztetés magyaráz egy látszólag szokásos ellentmondást: a tárolási végpont elérhető a proxyn keresztül, de az SDK a várt művelet elküldése előtt meghiúsul. A hiba a hitelesítő adatok identitásvégponttól való beszerzéséhez tartozhat.

Először jegyezze fel, melyik célpont hiúsult meg. Ezután vizsgálja meg a tárolási építőnek átadott HTTP-ügyfelet és a hitelesítő adatok implementációja által használt konfigurációt. Kövesse az egyes transzportok támogatott proxybeállításait. A nyilvánosan elérhető tárolási és tokenvégpontokhoz engedélyezett nyilvános proxy-útvonalon a HTTP-proxylista végpontjelölteket kínál; ne feltételezze, hogy egy építő beállítása az alkalmazás minden objektumát újrakonfigurálja.

SzakaszHasznos bizonyíték
Token beszerzéseIdentitásvégpont, kiválasztott ügyfél, proxy-kihívás vagy kapcsolódási hiba
Tárolási kérésTárolási végpont, konfigurált folyamat, végső válasz vagy átviteli hiba

Tartsa a proxyfiókot külön az Azure-hitelesítő adattól. A sikeres proxybejelentkezés útvonalat ad; a cél szolgáltatás továbbra is engedélyezi az Azure-műveletet.

A történelmi válaszok az Azure Storage Java osztályainak több generációját használják, köztük a régebbi OperationContext- és folyamat-API-kat. Párosítsa a példát azzal az SDK-val és HTTP-transzporttal, amelyet az alkalmazás jelenleg használ. A Data Lake SDK-hoz egy tárolási és identitási közös HTTP-ügyfél-beállítás mutatja mindkét építőbevitelt. Egy elavult ügyféltípus visszavezetése egy proxyprobléma megoldására egy újabb hibakeresendő konfigurációs útvonalat hoz létre.

Használjon biztonságos végpontazonosítókat a naplókban. A tárolási URL-ek hozzáféréstokent tartalmazhatnak, a teljes proxy-URL pedig jelszót tartalmazhat.

Kapcsolódó cikkek