ໃນແອັບພລິເຄຊັນ HttpClient 4.2.2 ແບບເກົ່າ, ຜູ້ໃຫ້ຂໍ້ມູນຢືນຢັນ ແລະ ແຄຊການຢືນຢັນ ເຮັດວຽກຕ່າງກັນ. ຜູ້ໃຫ້ບໍລິການສະໜອງບັນຊີ; ແຄຊເປີດໃຫ້ແຜນການຢືນຢັນທີ່ຕັ້ງໄວ້ລ່ວງໜ້າຢ່າງເຈດຕະນາເຂົ້າຮ່ວມກ່ອນທີ່ສິ່ງທ້າທາຍຕໍ່ໄປຈະມາຮອດ.

ສຳລັບ constructor 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. ການສ້າງມັນແລ້ວໃຊ້ overload ທີ່ສ້າງບໍລິບົດອື່ນ ຈະເຮັດໃຫ້ແຄຊຢູ່ນອກການແລກປ່ຽນ. ສຳລັບການດຳເນີນການຕໍ່ໄປທີ່ຕ້ອງແບ່ງປັນສະຖານະການຢືນຢັນນັ້ນ, ໃຫ້ເກັບບໍລິບົດທີ່ເໝາະສົມໄວ້ ແທນທີ່ຈະສ້າງອັນຫວ່າງໃໝ່ທຸກຄັ້ງ.

ສະຖານະ PROXY ທີ່ຊັດເຈນເປັນຂອງ API ເກົ່ານີ້. TARGET ກ່ຽວຂ້ອງກັບການຢືນຢັນປາຍທາງ. HttpClient ລຸ້ນໃໝ່ໄດ້ປ່ຽນແພັກເກັດ ແລະ API ການຢືນຢັນ, ດັ່ງນັ້ນຈົ່ງໃຊ້ສິ່ງນີ້ເປັນຄຳແນະນຳການບຳລຸງຮັກສາສຳລັບໂຄ້ດ 4.2 ທີ່ມີຢູ່, ບໍ່ແມ່ນສູດສຳລັບ client ໃໝ່.

ການແລກປ່ຽນປົກກະຕິທີ່ຂັບເຄື່ອນດ້ວຍສິ່ງທ້າທາຍຍັງສາມາດຖືກຕ້ອງໄດ້. ຫວ່ານການຢືນຢັນ Basic ສຳລັບພຣັອກຊີທີ່ຮູ້ຈັກ ແລະ ຕັ້ງໃຈເທົ່ານັ້ນ, ແລະ ບໍລິໂພກ ຫຼື ປ່ອຍແຕ່ລະການຕອບສະໜອງກ່ອນທີ່ການດຳເນີນການຕໍ່ໄປຈະຕ້ອງການການເຊື່ອມຕໍ່ຂອງມັນ. ຜົນທີ່ເປັນປະໂຫຍດແມ່ນບັນຊີ ແລະ ແຜນການທີ່ເກັບໄວ້ ຊຶ່ງຜູກກັບການປະຕິບັດທີ່ສົ່ງຄຳຮ້ອງຕົວຈິງ.

ບົດຄວາມທີ່ກ່ຽວຂ້ອງ