Dalam aplikasi lama HttpClient 4.2.2, pembekal kelayakan dan cache pengesahan melakukan kerja yang berbeza. Pembekal membekalkan akaun; cache membolehkan skema pengesahan yang sengaja dikonfigurasikan awal menyertai sebelum cabaran seterusnya tiba.

Bagi pembina BasicScheme lama yang khusus proksi, penyerahan itu kelihatan seperti ini:

AuthCache cache = new BasicAuthCache();
cache.put(proxy, new BasicScheme(ChallengeState.PROXY));

HttpContext context = new BasicHttpContext();
context.setAttribute(ClientContext.AUTH_CACHE, cache);
HttpResponse response = client.execute(request, context);

Fragmen ini menganggap client sudah mempunyai laluan proksi yang sepadan dan pembekal kelayakan. proxy ialah HttpHostnya, dan request ialah operasi sebenar. Kunci cache mesti menerangkan perantara itu, bukan laman web destinasi.

Serahkan konteks yang telah diisi kepada execute. Membinanya dan kemudian menggunakan limpahan yang mencipta konteks lain membiarkan cache di luar pertukaran. Untuk operasi seterusnya yang perlu berkongsi keadaan pengesahan itu, kekalkan konteks yang sesuai dan bukannya membina semula yang kosong setiap kali.

Keadaan PROXY yang eksplisit tergolong dalam API lama ini. TARGET berkaitan pengesahan destinasi. Generasi HttpClient yang lebih baharu telah menukar pakej dan API pengesahan, jadi gunakan ini sebagai panduan penyelenggaraan untuk kod 4.2 sedia ada, bukan sebagai resipi untuk client baharu.

Pertukaran biasa yang dipacu cabaran masih boleh betul. Taburkan pengesahan Basic hanya untuk proksi yang diketahui dan dimaksudkan, dan gunakan atau lepaskan setiap respons sebelum operasi seterusnya memerlukan sambungannya. Hasil yang berguna ialah akaun dan skema yang di-cache terikat pada pelaksanaan yang benar-benar menghantar permintaan.

Artikel berkaitan