Jetty 12.0.x SPNEGO: ຕັ້ງຊື່ບໍລິການ ບໍ່ແມ່ນ principal ເຕັມ

ໃນການຕັ້ງຄ່າ SPNEGO ຂອງ Jetty ມີສາມຊື່: URI ທີ່ໃຊ້ຈັບຄູ່ການກວດສອບ, ຜູ້ໃຊ້ທີ່ເຂົ້າຜ່ານ JAAS ແລະ ບໍລິການທີ່ຮ້ອງຂໍປີ້. ແຕ່ລະອັນມີຈຸດປະສົງຕ່າງກັນ.

ສຳລັບການຈັດຕັ້ງ Jetty 12.0.x ສ່ວນຂອງວັດຖຸການກວດສອບແມ່ນ:

var auth = new org.eclipse.jetty.client.SPNEGOAuthentication(
    java.net.URI.create("http://proxy.example:8080"));
auth.setServiceName("HTTP");

ສ່ວນນີ້ສະແດງອົງປະກອບບໍລິການ ບໍ່ແມ່ນສູດການກວດສອບ proxy ເຕັມ. ການເຂົ້າ JAAS, ການເສັ້ນທາງ proxy ແລະ ການແລກປ່ຽນການກວດສອບຂອງຄຳຮ້ອງຍັງແຍກກັນຢູ່.

ໃນການຈັດຕັ້ງນີ້ Jetty ສ້າງຊື່ GSS ທີ່ອີງໃສ່ໂຮສໂດຍລວມ getServiceName(), ຕົວອັກສອນ @ ແລະ ໂຮສສຳລັບການແລກປ່ຽນການກວດສອບ. ການໃຫ້ [email protected] ເປັນອົງປະກອບບໍລິການຈະເພີ່ມໂຮສອີກອັນ. ອ່ານສັນຍາຂອງ setter ນີ້ ແທນການສົມມຸດວ່າມັນຮັບ principal Kerberos ເຕັມ.

ຊື່ GSS ທີ່ໄດ້ມີຮູບແບບແນວຄິດ HTTP@hostname. principal ບໍລິການທີ່ກົງກັນຂອງ KDC ມັກສະແດງເປັນ HTTP/hostname. ຊື່ proxy ທີ່ເລືອກຕ້ອງກົງກັບບໍລິການທີ່ລົງທະບຽນຕົວຈິງ ສຳລັບບັນຊີນັ້ນ; ທີ່ຢູ່ IP ຫຼືນາມແຝງອາດເລືອກເປົ້າໝາຍປີ້ອື່ນ.

ກວດເບິ່ງເສັ້ນທາງ 407 ນຳ

ໃນ Jetty 12.0.x authenticate() ໄດ້ຮັບຊື່ໂຮສ GSS ຈາກ request.getHost() ແລະ ສ້າງຜົນດ້ວຍຫົວຂໍ້ Authorization ຄ່າເລີ່ມຕົ້ນ. ການຈັບຄູ່ວັດຖຸການກວດສອບຕາມ proxy URI ບໍ່ໄດ້ປ່ຽນທາງເລືອກເຫຼົ່ານັ້ນເປັນຊື່ໂຮສຂອງ proxy ແລະ Proxy-Authorization ໂດຍຕົວມັນເອງ.

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

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