ສຳລັບ HTTP proxy ທີ່ໃຫ້ການພິສູດຢືນຢັນ Basic, proxyAuthenticator ຂອງ OkHttp ສາມາດສົ່ງຄືນຄຳຮ້ອງທີ່ພາເອົາຂໍ້ມູນຢືນຢັນ. ສົ່ງຄືນ null ຫຼັງຈາກຄວາມພະຍາຍາມອະນຸຍາດຖືກປະຕິເສດແລ້ວ ແທນທີ່ຈະສົ່ງຄຳຕອບເດີມຊ້ຳອີກ:

.proxyAuthenticator { _, response ->
    if (response.request.header("Proxy-Authorization") != null) {
        null
    } else {
        response.request.newBuilder()
            .header("Proxy-Authorization",
                    Credentials.basic(proxyUser, proxyPassword))
            .build()
    }
}

ແບບຮ່າງນີ້ໃຊ້ຄ່າບັນຊີຈາກການຕັ້ງຄ່າລັບຂອງແອັບພລິເຄຊັນ. ຕົວປ້ອງກັນອະນຸຍາດຄວາມພະຍາຍາມທຳອິດ ແລະ ຢຸດຄວາມພະຍາຍາມທີ່ເຮັດຊ້ຳ. ມັນຈັດຕັ້ງ Basic ບໍ່ແມ່ນທຸກຮູບແບບທີ່ proxy ອາດປະກາດ; ກວດເບິ່ງສິ່ງທ້າທາຍກ່ອນເລືອກຄຳຕອບນັ້ນ.

ຖ້າຜົນສຸດທ້າຍຍັງເປັນ 407, ປຽບທຽບ proxy ທີ່ເລືອກ, ຮູບແບບທີ່ປະກາດ ແລະ ຕົວຕົນບັນຊີທີ່ເອກະສານ. ລະຫັດຜ່ານທີ່ຖືກປະຕິເສດ, ວິທີທີ່ບໍ່ຮອງຮັບ ແລະ ຮູບແບບຊື່ຜູ້ໃຊ້ທີ່ຜິດຕ້ອງການການແກ້ໄຂຕ່າງກັນ. ເກັບຂໍ້ສັງເກດເຫຼົ່ານັ້ນ ແລະ ສະຖານະສຸດທ້າຍໄວ້ໃນການວິເຄາະທີ່ປັດແລ້ວ.

CONNECT ມີບໍລິບົດ callback ອີກອັນໜຶ່ງ: OkHttp ເອກະສານສິ່ງທ້າທາຍການພິສູດຢືນຢັນ proxy ແບບສັງເຄາະກ່ອນເປີດອຸໂມງ. ຈັດການບໍລິບົດນັ້ນຕາມ API ແທນທີ່ຈະສົມມຸດວ່າທຸກ callback ແມ່ນຄຳຕອບປາຍທາງປົກກະຕິ.

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

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

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