Azure Storage Java: proxy-ruter for API- og tokenførespurnader
Kontroller både Azure Storage-førespurnader og tokenførespurnader for legitimasjon når du konfigurerer ein Java SDK-proxy.
Å konfigurere ein proxy på HTTP-transporten til ein lagringsklient svarar på eitt spørsmål: korleis denne transporten sender lagringsførespurnader. Ein identitetslegitimasjon kan ha ein annan HTTP-klient for å hente tokens.
Den skilnaden forklarar ein tilsynelatande vanleg motsetnad: lagringsendepunktet er tilgjengeleg gjennom proxyen, men SDK-en feilar før han sender den venta operasjonen. Feilen kan høyre til henting av legitimasjon mot eit identitetsendepunkt.
Noter først kva mål som feila. Undersøk deretter HTTP-klienten som vart gitt til lagringsbyggjaren, og konfigurasjonen legitimasjonsimplementasjonen brukar. Følg dei støtta proxyvala for kvar transport. For offentleg tilgjengelege lagrings- og tokenendepunkt på ei tillaten offentleg proxy-rute tilbyr HTTP-proxylista endepunktkandidatar; ikkje gå ut frå at innstillinga til éin byggjar omkonfigurerer kvart objekt i applikasjonen.
| Trinn | Nyttige prov |
|---|---|
| Henting av token | Identitetsendepunkt, vald klient, proxy-utfordring eller tilkoplingsfeil |
| Lagringsførespurnad | Lagringsendepunkt, konfigurert pipeline, endeleg svar eller overføringsfeil |
Hald proxykontoen skild frå Azure-legitimasjonen. Ei vellukka proxy-innlogging gir ei rute; tenesta på målet autoriserer framleis Azure-operasjonen.
Historiske svar brukar fleire generasjonar Azure Storage Java-klassar, mellom anna eldre OperationContext- og pipeline-API. Tilpass eit døme til SDK-en og HTTP-transporten applikasjonen brukar no. For Data Lake SDK viser eit felles HTTP-klientoppsett for lagring og identitet begge byggjarinndata. Å innføre ein utdatert klienttype på nytt for å løyse eit proxyproblem lagar nok ei konfigurasjonsvei å feilsøkje.
Bruk trygge endepunktidentifikatorar i loggar. Lagrings-URL-ar kan innehalde tilgangstokens, og ein full proxy-URL kan innehalde eit passord.