Azure Storage Java: proksiaj itineroj por API- kaj ĵetonpetoj
Kontrolu kaj Azure Storage-petojn kaj ĵetonpetojn de akreditaĵoj kiam vi agordas proksion de Java SDK.
Agordi proksion sur la HTTP-transporto de stoka kliento respondas unu demandon: kiel tiu transporto sendas stokajn petojn. Identeca akreditaĵo povas havi alian HTTP-klienton por akiri ĵetonojn.
Tiu distingo klarigas ŝajne ordinaran kontraŭdiron: la stoka finpunkto estas atingebla tra la proksio, sed la SDK malsukcesas antaŭ ol sendi la atendatan operacion. La malsukceso povas aparteni al akiro de akreditaĵoj kontraŭ identeca finpunkto.
Unue notu, kiu celo malsukcesis. Poste ekzamenu la HTTP-klienton donitan al la stoka konstruilo kaj la agordon uzatan de la akreditaĵa efektivigo. Sekvu la subtenatajn proksiajn opciojn de ĉiu transporto. Por publike atingeblaj stokaj kaj ĵetonaj finpunktoj sur permesita publika proksia itinero, la HTTP-proksia listo proponas finpunktajn kandidatojn; ne supozu, ke agordo de unu konstruilo reagordas ĉiun objekton en la aplikaĵo.
| Etapo | Utilaj pruvoj |
|---|---|
| Akiro de ĵetono | Identeca finpunkto, elektita kliento, proksia defio aŭ konekta eraro |
| Stoka peto | Stoka finpunkto, agordita fluo, fina respondo aŭ transporta malsukceso |
Tenu la proksian konton aparte de la Azure-akreditaĵo. Sukcesa proksia ensaluto donas itineron; la cela servo ankoraŭ rajtigas la Azure-operacion.
Historiaj respondoj uzas plurajn generaciojn de Azure Storage Java-klasoj, inkluzive pli malnovajn OperationContext- kaj flupreajn API-ojn. Kongruigu ekzemplon al la SDK kaj HTTP-transporto, kiujn la aplikaĵo nun uzas. Por la Data Lake SDK, komuna HTTP-klienta agordo por stokado kaj identeco montras ambaŭ konstruilajn enigojn. Reenkonduki malaktualan klientotipon por solvi proksian problemon kreas plian agordan vojon por sencimigi.
Uzu sekurajn finpunktajn identigilojn en protokoloj. Stokaj URL-oj povas enhavi alirĵetonojn, kaj plena proksia URL-o povas enhavi pasvorton.