Azure Storage Java: proxy-roetes vir API- en tokenversoeke
Kontroleer beide Azure Storage-versoeke en tokenversoeke vir geloofsbriewe wanneer jy 'n Java SDK-proxy opstel.
Om 'n proxy op 'n stoorclient se HTTP-transport te configureer, beantwoord een vraag: hoe daardie transport stoorversoeke stuur. 'n Identiteitsgeloofsbrief kan 'n ander HTTP-client hê om tokens te verkry.
Daardie onderskeid verduidelik 'n oënskynlik algemene teenstrydigheid: die stoor-eindpunt is deur die proxy bereikbaar, maar die SDK misluk voordat die verwagte bewerking gestuur word. Die mislukking kan by geloofsbriefverkryging teen 'n identiteits-eindpunt hoort.
Teken eers aan watter bestemming misluk het. Ondersoek dan die HTTP-client wat aan die stoorbouer verskaf is en die konfigurasie wat die geloofsbriefimplementering gebruik. Volg die ondersteunde proxy-opsies van elke transport. Vir publiek bereikbare stoor- en token-eindpunte op 'n toegelate publieke proxy-roete bied die HTTP-proxylys eindpuntkandidate; moenie aanneem dat een bouer se instelling elke objek in die toepassing herkonfigureer nie.
| Fase | Nuttige bewyse |
|---|---|
| Tokenverkryging | Identiteits-eindpunt, gekose client, proxy-uitdaging of verbindingsfout |
| Stoorversoek | Stoor-eindpunt, geconfigureerde pyplyn, finale antwoord of oordragfout |
Hou die proxy-rekening apart van die Azure-geloofsbrief. 'n Suksesvolle proxy-aanmelding verleen 'n roete; die bestemmingdiens magtig steeds die Azure-bewerking.
Historiese antwoorde gebruik verskeie generasies Azure Storage Java-klasse, insluitend ouer OperationContext- en pyplyn-API's. Pas 'n voorbeeld aan by die SDK en HTTP-transport wat die toepassing tans gebruik. Vir die Data Lake SDK wys 'n gedeelde HTTP-client-opstelling vir stoor en identiteit albei bouer-insette. Om 'n verouderde clienttipe weer in te voer om 'n proxyprobleem op te los, skep nog 'n konfigurasiepad om te ontfout.
Gebruik veilige eindpunt-identifiseerders in logs. Stoor-URL's kan toegangstokens bevat, en 'n volledige proxy-URL kan 'n wagwoord bevat.