ການເຂົ້າສູ່ proxy URL ໃນ Emacs 31.1: auth-source ແລະ ຂອບເຂດ CONNECT

ທີ່ຢູ່ຂອງ proxy ບອກ Emacs ວ່າຈະເຊື່ອມຕໍ່ໄປໃສ. ການເຂົ້າຂອງມັນແມ່ນພາກສ່ວນອື່ນຂອງການສົນທະນາ. ສຳລັບຄຳຮ້ອງ HTTP ທົ່ວໄປ, ຫ້ອງສະໝຸດ URL ຂອງ Emacs ສາມາດຕອບສິ່ງທ້າທາຍການພິສູດຢືນຢັນຂອງ proxy, ເອົາຂໍ້ມູນຈາກ auth-source ຫຼືຖາມແບບໂຕ້ຕອບ, ແລະ ນຳຂໍ້ມູນທີ່ເກັບໄວ້ໃນເຊສຊັນມາໃຊ້ຄືນ.

ລາຍລະອຽດຂ້າງລຸ່ມປະຕິບັດຕາມ Emacs 31.1. ພວກມັນກ່ຽວຂ້ອງກັບການດຳເນີນງານທີ່ໃຊ້ ຫ້ອງສະໝຸດ URL; ຕົວດາວໂຫຼດພາຍນອກທີ່ແພັກເກດ Emacs ເປີດມີເສັ້ນທາງພິສູດຢືນຢັນຂອງຕົນເອງ.

ກຳນົດເສັ້ນທາງ, ແລ້ວໃຫ້ HTTP ຂໍການເຂົ້າ

ຈຸດປາຍທາງ proxy ຄົງທີ່ສາມາດເລືອກໄດ້ດ້ວຍຕົວເລືອກທີ່ບັນທຶກໄວ້:

(setq url-proxy-services
      '(("http" . "proxy.example:8080")
        ("https" . "proxy.example:8080")))

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

ໃນລະຫວ່າງຄຳຮ້ອງ HTTP ທົ່ວໄປ, proxy ສາມາດຕອບດ້ວຍ 407 Proxy Authentication Required ແລະ ສິ່ງທ້າທາຍ Proxy-Authenticate. ຫ້ອງສະໝຸດ URL ເລືອກແບບການພິສູດຢືນຢັນທີ່ຮອງຮັບ ແລະ ໄດ້ຂໍ້ມູນສຳລັບຈຸດປາຍທາງ proxy. ຈາກນັ້ນມັນລອງຄືນດ້ວຍ Proxy-Authorization.

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

ເກັບຂໍ້ມູນຖາວອນໄວ້ໃນ auth-source

ຖ້າ auth-source ອ່ານໄຟລ໌ຂໍ້ມູນທີ່ເຂົ້າລະຫັດແລ້ວເຊັ່ນ ~/.authinfo.gpg, ລາຍການ Basic ສຳລັບຕົວຢ່າງນີ້ມີຮູບແບບດັ່ງນີ້:

machine proxy.example port http login YOUR_LOGIN password YOUR_PASSWORD

ໃຊ້ບັນຊີ ແລະ ຄວາມລັບຕົວຈິງຂອງທ່ານ, ແລະ ໃຫ້ແນ່ໃຈວ່າໄຟລ໌ນັ້ນຢູ່ໃນ auth-sources ທີ່ຕັ້ງຄ່າໄວ້. ແຖວນີ້ສະແດງຊ່ອງຂໍ້ມູນທີ່ກົງກັນ; ມັນບໍ່ແມ່ນຄຳແນະນຳໃຫ້ໃສ່ລະຫັດຜ່ານໃນໄຟລ໌ເລີ່ມຕົ້ນ Lisp ຂອງທ່ານ.

ມີສອງລາຍລະອຽດທີ່ສຳຄັນໃນການຈັດຕັ້ງ Basic ຂອງ Emacs 31.1. ມັນຄົ້ນຫາຊື່ໂຮສຂອງ proxy ໂດຍບໍ່ມີພອດ TCP ເປັນໂຕເລກ, ແລະ ສົ່ງແບບ URL ຂອງ proxy ເປັນຄ່າພອດຂອງ auth-source. ສຳລັບ HTTP proxy ນີ້, ຄ່ານັ້ນແມ່ນ http ເຖິງແມ່ນການເຊື່ອມຕໍ່ TCP ໃຊ້ພອດ 8080.

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

ຫ້ອງສະໝຸດ URL ຍັງເກັບ cache ການພິສູດຢືນຢັນຂອງຕົນເອງ. ລາຍການ Basic ຂອງມັນແຍກຈຸດປາຍທາງ proxy ແລະ ໃຊ້ການຈັບຄູ່ realm ຫຼື ໄດເຣັກທໍຣີພາຍໃນຈຸດປາຍທາງ; cache ນັ້ນແຍກຈາກການຄົ້ນຫາ auth-source. ການພິມລະຫັດຜ່ານໃນຄຳຖາມສາມາດເຕີມ cache ຂອງເຊສຊັນໄດ້ໂດຍບໍ່ເກັບລາຍການໃໝ່ໃນໄຟລ໌ຂໍ້ມູນຖາວອນຂອງທ່ານ.

HTTPS ມີຂັ້ນຕອນພິສູດຢືນຢັນກ່ອນໜ້າ

ສຳລັບປາຍທາງ HTTPS ຜ່ານ HTTP proxy, Emacs ສົ່ງ CONNECT ກ່ອນ. ດັ່ງນັ້ນການພິສູດຢືນຢັນອາດຈຳເປັນກ່ອນທີ່ຈະຮອດການເຊື່ອມຕໍ່ທີ່ເຂົ້າລະຫັດກັບເວັບໄຊ.

ໃນ Emacs 31.1, ຕົວສ້າງຄຳຮ້ອງ CONNECT ກວດສອບການພິສູດຢືນຢັນທີ່ມີຢູ່ແລ້ວຜ່ານເຄື່ອງຈັກພິສູດຢືນຢັນຂອງມັນ, ລວມທັງຂໍ້ມູນ Basic ທີ່ເກັບໃນ cache. ເສັ້ນທາງ Basic ຂອງມັນບໍ່ຖາມ ຫຼື ດຶງລາຍການ auth-source ໃໝ່ໃນຈຸດນັ້ນ. ການຕອບສະໜອງ CONNECT ທີ່ບໍ່ແມ່ນ 200 ກໍບໍ່ເຂົ້າສູ່ຕົວຈັດການສິ່ງທ້າທາຍ HTTP 407 ປົກກະຕິທີ່ອະທິບາຍຂ້າງເທິງ.

ດັ່ງນັ້ນ, ລາຍການ auth-source ທີ່ສາມາດຕອບສິ່ງທ້າທາຍ HTTP Basic ປົກກະຕິບໍ່ຮັບປະກັນວ່າຄຳຮ້ອງ HTTPS ທຳອິດຂອງເຊສຊັນໃໝ່ຈະພິສູດຢືນຢັນສຳເລັດ. ເຊສຊັນທີ່ມີຂໍ້ມູນໃນ cache ທີ່ເໝາະສົມມີສະຖານະເລີ່ມຕົ້ນຕ່າງກັນ. ການແກ້ໄຂລາຍການລະຫັດຜ່ານອັນດຽວກັນຊ້ຳໆບໍ່ສາມາດລຶບຄວາມແຕກຕ່າງນີ້ລະຫວ່າງສອງເສັ້ນທາງໄດ້ດ້ວຍຕົວມັນເອງ.

ຖ້າການດຳເນີນງານ HTTPS ຢຸດຢູ່ proxy, ໃຫ້ກຳນົດວ່າ CONNECT ໄດ້ຮັບ 407 ຫຼື ບໍ່ ແລະ ທ່ານກຳລັງໃຊ້ພຶດຕິກຳຂອງສະບັບນີ້ຫຼື ບໍ່. ຢືນຢັນແບບການພິສູດຢືນຢັນທີ່ proxy ສະເໜີດ້ວຍ. ລາຍການຂໍ້ມູນ Basic ບໍ່ແມ່ນອະແດັບເຕີສາກົນສຳລັບທຸກລະບົບພິສູດຢືນຢັນອົງກອນ.

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