HTTP 407 ຫຼື 401: ການເຂົ້າລະບົບຝັ່ງໃດລົ້ມເຫຼວ?
ແຍກການຢືນຢັນຕົວຕົນຂອງພຣັອກຊີກັບເວັບໄຊ ກວດ header ທີ່ຖືກຕ້ອງ ແລະບໍ່ສົ່ງຂໍ້ມູນເຂົ້າລະບົບໃຫ້ຜິດຝັ່ງ.
407 ຂໍຢືນຢັນຕົວຕົນກັບພຣັອກຊີ. 401 ຂໍສຳລັບຊັບພະຍາກອນປາຍທາງ. ຄຳຂໍດຽວອາດເຈີທັງສອງ ຈຶ່ງຕ້ອງຮູ້ກ່ອນວ່າໃຜຂໍ ແລ້ວຈຶ່ງໃຫ້ລະຫັດຜ່ານ.
ປຽບທຽບສະຖານະແລະ header ທີ່ຂໍຢືນຢັນຕົວຕົນ
| ຄຳຕອບ | header ຂໍຢືນຢັນຕົວຕົນ | header ຂໍ້ມູນເຂົ້າລະບົບ | ຝ່າຍທີ່ກ່ຽວຂ້ອງ |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | ພຣັອກຊີຕົວກາງ |
| 401 Unauthorized | WWW-Authenticate | Authorization | ຂັ້ນຕອນຢືນຢັນຕົວຕົນຂອງຊັບພະຍາກອນຕົ້ນທາງ |
ສະຖານະເປັນເບາະແສທຳອິດທີ່ສຳຄັນ ແຕ່ຕ້ອງເບິ່ງການແລກປ່ຽນທັງໝົດ. ເລກ 407 ໃນເນື້ອຫາໜ້າເວັບບໍ່ເທົ່າກັບຄຳຕອບ HTTP 407 ຈິງ. ໜ້າເຂົ້າລະບົບສະເພາະກໍອາດຄືນ 200 ແຕ່ຍັງຂໍຢືນຢັນຕົວຕົນໃນຊັ້ນແອັບ.
ເປັນຫຍັງ HTTPS ອາດເຈີ 407 ກ່ອນເຖິງເວັບໄຊ?
ເມື່ອພຣັອກຊີ HTTP ທົ່ວໄປສົ່ງຕໍ່ HTTPS, client ມັກຂໍສ້າງອຸໂມງ CONNECTກ່ອນ. ພຣັອກຊີອາດຂໍຢືນຢັນຕົວຕົນສຳລັບ CONNECT ນັ້ນ. ຖ້າຍັງບໍ່ສຳເລັດ ເຊດຊັນ TLS ຂອງປາຍທາງຜ່ານອຸໂມງກໍຍັງບໍ່ຖືກສ້າງ. ການປ່ຽນ API token ຂອງເວັບໄຊຈຶ່ງຄົງບໍ່ແກ້ຂັ້ນນີ້ໄດ້.
ໃຊ້ເອົາພຸດແບບລະອຽດເພື່ອເບິ່ງຈຸດທີ່ຮ້ອງຂໍ:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/ປ່ຽນ listener ໃນເຄື່ອງເປັນຂອງທ່ານ ແລ້ວອ່ານຄຳຮ້ອງຂໍທຳອິດໃນບັນທຶກ. 407 ໃນ CONNECT ເກີດກ່ອນ TLS ປາຍທາງ; 401 ຕໍ່ມາອາດເກີດຫຼັງສ້າງອຸໂມງສຳເລັດ.
ໃຫ້ຂໍ້ມູນພຣັອກຊີຜ່ານອິນເຕີເຟດຂອງພຣັອກຊີ
ສຳລັບເອັນພອຍແລະບັນຊີຈາກຜູ້ດູແລທີ່ໄວ້ໃຈ curl ສາມາດເຈລະຈາວິທີຢືນຢັນຕົວຕົນ ແລະຖາມລະຫັດຜ່ານທີ່ບໍ່ໄດ້ລະບຸ:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/ແທນເອັນພອຍແລະຊື່ຜູ້ໃຊ້ຕົວຢ່າງດ້ວຍຂໍ້ມູນບໍລິການທີ່ທ່ານມີສິດໃຊ້. ລະບຸພຽງຜູ້ໃຊ້ຈະບໍ່ໃຫ້ລະຫັດຜ່ານຢູ່ໃນຄຳສັ່ງຂ້າງເທິງໂດຍກົງ. ວິທີທີ່ຮອງຮັບອາດຕ່າງຕາມບິລດ໌ curl ແລະພຣັອກຊີ; ຖ້າເຈລະຈາບໍ່ສຳເລັດ ໃຫ້ເບິ່ງຄຳຂໍຈິງແລະຄວາມສາມາດຂອງບິລດ໌.
ຕົວເລືອກຢືນຢັນຕົວຕົນພຣັອກຊີແຍກຈາກຕົວເລືອກຜູ້ໃຊ້ຕົ້ນທາງໃນ curl. ຢ່າເພີ່ມ Authorization ຂອງຕົ້ນທາງແທນຄຳຕອບໃຫ້ພຣັອກຊີ. ຢ່າສົ່ງຕໍ່ header ຂໍ້ມູນພຣັອກຊີໄປຫາຄຳຂໍທີ່ບໍ່ກ່ຽວຂ້ອງເອງ ຫຼືເກັບໃນ header ທີ່ໃຊ້ຄືນທົ່ວແອັບ.
ຖ້າພຣັອກຊີຍັງຄືນ 407
- ຢືນຢັນວ່າໃຊ້ໂຮສແລະພອດພຣັອກຊີທີ່ຕັ້ງໃຈ.
- ກວດວິທີທີ່ພຣັອກຊີປະກາດ ແທນການຄາດວ່າເປັນ Basic.
- ຢືນຢັນສະຖານະບັນຊີ ແລະຮູບແບບຊື່ຜູ້ໃຊ້ທີ່ບໍລິການຕ້ອງການ.
- ກວດການສົ່ງອັກຂະລະພິເສດ ຖ້າຂໍ້ມູນຢູ່ໃນ URL.
- ຫາວ່າການຢືນຢັນຕົວຕົນອົງກອນທີ່ລວມກັບເບຣົາເຊີຕ້ອງການຮັນໄທມ໌ຫຼືແພລດຟອມຮອງຮັບຫຼືບໍ່.
- ຖ້າຫຼັກຖານຝັ່ງ client ບໍ່ພໍ ຂໍລະຫັດຄຳຂໍຫຼືບັນທຶກເຊີບເວີທີ່ລຶບຂໍ້ມູນອ່ອນໄຫວແລ້ວຈາກຜູ້ດູແລ.
403 ຫຼື CONNECT ທີ່ຖືກປະຕິເສດອາດເປັນການຕັດສິນຕາມນະໂຍບາຍ ແມ່ນແຕ່ຫຼັງເຂົ້າລະບົບສຳເລັດ. ການລອງລະຫັດຜ່ານຕື່ມບໍ່ໄດ້ໃຫ້ສິດເຂົ້າປາຍທາງຕ້ອງຫ້າມ.
HTTPS ປາຍທາງບໍ່ໄດ້ປົກປ້ອງການສົ່ງຂໍ້ມູນພຣັອກຊີທຸກຄັ້ງ
ການຢືນຢັນກັບພຣັອກຊີອາດເກີດກ່ອນ TLS ປາຍທາງ. ຖ້າການເຊື່ອມຕໍ່ກັບພຣັອກຊີເອງບໍ່ເຂົ້າລະຫັດ ແລະວິທີເປີດເຜີຍຂໍ້ມູນທີ່ນຳກັບມາໃຊ້ໄດ້ ປາຍທາງ HTTPS ກໍບໍ່ປົກປ້ອງການແລກປ່ຽນນັ້ນຍ້ອນຫຼັງ. ເລືອກວິທີສົ່ງຂໍ້ມູນແລະການຢືນຢັນທີ່ເໝາະກັບບໍລິການ ແລະຢ່າສົ່ງບັນຊີສ່ວນຕົວໃຫ້ພຣັອກຊີສາທາລະນະທີ່ບໍ່ຮູ້ຈັກ.
ກວດບັນທຶກລະອຽດກ່ອນແຊຣ໌. ເຖິງເຄື່ອງມືຈະປິດບັງຊ່ອງຂໍ້ມູນທົ່ວໄປ ກໍອາດມີຊື່ຜູ້ໃຊ້ ຊື່ເອັນພອຍພາຍໃນ ຄຸກກີ້ ຫຼືຂໍ້ມູນລະບຸຕົວຕົນອື່ນເຫຼືອຢູ່.