ຊື່ຜູ້ໃຊ້ທີ່ມີໂດເມນໃນຂໍ້ມູນຢືນຢັນຂອງ proxy
ແຍກຊື່ບັນຊີທີ່ບໍ່ຊັດເຈນອອກຈາກ API ທີ່ມີຊ່ອງໂດເມນແຍກຕ່າງຫາກ, ແລະ ຫຼີກລ່ຽງການປ່ຽນຕົວຕົນບັນຊີພຽງເພື່ອໃຫ້ຕົງກັບໄວຍະກອນ URL.
ຄຳຕອບໜຶ່ງບອກໃຫ້ລຶບ DOMAIN\ ອອກ. ອີກຄຳຕອບໜຶ່ງບອກໃຫ້ເພີ່ມມັນ. ທັງສອງການປ່ຽນແປງອາດຜິດສຳລັບ proxy ຂອງທ່ານ.
ມີສອງຄຳຖາມ: ບໍລິການຄາດຫວັງຕົວຕົນໃດ, ແລະ API ທີ່ເລືອກສະແດງຕົວຕົນນັ້ນແນວໃດ.
| ສ່ວນຕິດຕໍ່ | ສິ່ງທີ່ຕ້ອງກຳນົດ |
|---|---|
| ຊ່ອງຊື່ບັນຊີດຽວ | ໄວຍະກອນບັນຊີທີ່ແນ່ນອນທີ່ຜູ້ດຳເນີນການຮັບ |
| API ຂໍ້ມູນຢືນຢັນທີ່ມີຊ່ອງໂດເມນ | ຄວນສະໜອງໂດເມນ ແລະ ຊື່ຜູ້ໃຊ້ແຍກກັນຫຼືບໍ່ |
| ອົງປະກອບຂໍ້ມູນຢືນຢັນພາຍໃນ URI | ຄ່າທີ່ຕັ້ງໃຈຄວນຖືກເຂົ້າລະຫັດສຳລັບພາຊະນະນັ້ນແນວໃດ |
ຕົວຢ່າງ, .NET ສະເໜີ constructor NetworkCredential ທີ່ມີອາກູເມັນຊື່ຜູ້ໃຊ້, ລະຫັດຜ່ານ ແລະ ໂດເມນແຍກກັນ. ການໃສ່ໂດເມນໃນສອງຊ່ອງໂດຍບໍ່ແຍກແຍະບໍ່ແມ່ນວິທີທີ່ຍ້າຍໄດ້ເພື່ອຕັ້ງຄ່າການພິສູດຕົວຕົນແບບລວມ.
ການພິສູດຕົວຕົນ Basic ເປັນອີກກໍລະນີ: ເຊີບເວີຕີຄວາມໝາຍຂໍ້ຄວາມບັນຊີທີ່ສະໜອງໃຫ້ຕາມນະໂຍບາຍຂອງຕົນ. ການຢູ່ໃນເຄືອຂ່າຍດຽວກັນບໍ່ໄດ້ພິສູດວ່າມີຄຳນຳໜ້າໂດເມນໂດຍນັບເປັນນັຍ. ແລະ ຊື່ທີ່ມີໂດເມນກໍບໍ່ແມ່ນໂປຣໂຕຄອນພິສູດຕົວຕົນຕ່າງກັນໂດຍອັດຕະໂນມັດ.
ການ escape URL ຄວນຮັກສາບັນຊີທີ່ຕັ້ງໃຈ ບໍ່ແມ່ນປ່ຽນມັນ. ເຄື່ອງໝາຍທັບຫຼັງໃນສາຍອັກສອນຂອງພາສາຕົ້ນທາງ, ເຄື່ອງໝາຍທັບຫຼັງໃນຊື່ບັນຊີ ແລະ ການເຂົ້າລະຫັດເປີເຊັນຂອງມັນພາຍໃນ URI ແມ່ນຊັ້ນຕ່າງກັນ.
ຂໍຮູບແບບຕົວຕົນ ແລະ ແຜນທີ່ຍອມຮັບຈາກຜູ້ດຳເນີນການ, ແລ້ວໃຊ້ສ່ວນຕິດຕໍ່ຂໍ້ມູນຢືນຢັນທີ່ກົງກັນ. ການສະຫຼັບແບບສຸ່ມລະຫວ່າງຊື່ສັ້ນ, ຊື່ໂດເມນ ແລະ ຊື່ຄ້າຍອີເມວສ້າງຫຼັກຖານອ່ອນແອກ່ຽວກັບ 407 ເດີມ.