Apache HttpClient 4.2: прокси AuthCache-ийг хүсэлтийн контекстэд хадгал
HttpClient 4.2 проксийн Basic-auth кэшийг дараагийн хүсэлтүүд ашигладаг ижил гүйцэтгэлийн контекстэд хадгална уу.
Хуучин HttpClient 4.2.2 аппликейшнд итгэмжлэлийн нийлүүлэгч болон баталгаажуулалтын кэш өөр өөр ажил хийдэг. Нийлүүлэгч бүртгэлийг өгдөг; кэш нь санаатайгаар урьдчилан тохируулсан баталгаажуулалтын схем дараагийн сорилт ирэхээс өмнө оролцох боломж олгоно.
Проксид тусгайлсан хуучин BasicScheme конструкторын хувьд шилжүүлэлт иймэрхүү харагдана:
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);Энэ хэсэг нь client-д тохирох прокси маршрут болон итгэмжлэлийн нийлүүлэгч аль хэдийн байгаа гэж үздэг. proxy бол түүний HttpHost, request бол бодит үйлдэл юм. Кэшийн түлхүүр нь тухайн зуучлагчийг тодорхойлох ёстой, очих вэбсайтыг биш.
Дүүргэсэн контекстийг execute-д дамжуулна уу. Үүнийг бүтээгээд дараа нь өөр контекст үүсгэдэг хэт ачааллыг ашиглавал кэш солилцооноос гадуур үлдэнэ. Тэр баталгаажуулалтын төлөвийг хуваалцах дараагийн үйлдлүүдэд тус бүр хоосон контекстийг дахин бүтээхийн оронд тохирох контекстийг хадгална уу.
Тодорхой PROXY төлөв энэ хуучин API-д хамаарна. TARGET нь очих цэгийн баталгаажуулалтад хамаарна. Шинэ HttpClient үеүд багц болон баталгаажуулалтын API-г өөрчилсөн тул үүнийг одоо байгаа 4.2 кодын засвар үйлчилгээний удирдамж болгон ашиглана уу, шинэ client-ийн жор болгон биш.
Энгийн сорилтоор удирдуулсан солилцоо зөв хэвээр байж болно. Basic баталгаажуулалтыг зөвхөн мэдэгдэж, зориудсан проксид тарина уу, мөн дараагийн үйлдэлд түүний холболт хэрэг болохоос өмнө хариу бүрийг ашиглах эсвэл чөлөөлнө үү. Ашигтай үр дүн нь хүсэлтийг бодитоор илгээдэг гүйцэтгэлтэй холбогдсон бүртгэл ба кэшлэгдсэн схем юм.