Python Requests: ຊຸດ CA ຄວນຢູ່ໃນ verify ບໍ່ແມ່ນ cert

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

ເພື່ອນຮ່ວມງານມອບໃບຢັ້ງຢືນ CA ຂອງອົງກອນໃຫ້ທ່ານ. Requests ມີພາລາມິເຕີຊື່ cert. ຊື່ເບິ່ງຄືຄູ່ກັນ ແຕ່ມັນຕອບຄຳຖາມຕ່າງກັນ.

ການຕັ້ງຄ່າຈຸດປະສົງ
verifyເລືອກວັດຖຸຄວາມໄວ້ໃຈທີ່ໃຊ້ກວດສອບຄູ່ສົນທະນາ
certສະແດງໃບຢັ້ງຢືນລູກຄ້າ ພ້ອມກະແຈສ່ວນຕົວ ເມື່ອຕ້ອງການກວດສອບຕົວຕົນລູກຄ້າ

ສຳລັບ CA ສຳລັບການດັກຈັບທີ່ໄດ້ຮັບອະນຸມັດ ການດຳເນີນການ Requests ສາມາດເລືອກຊຸດ CA ທີ່ຕ້ອງການ:

response = requests.get(
    'https://example.com/',
    proxies=routes,
    verify='/path/to/approved-ca-bundle.pem',
    timeout=15,
)

ທີ່ນີ້ routes ແມ່ນການຈຳແນກພຣັອກຊີທີ່ມີຢູ່ຂອງແອັບຯ. ເສັ້ນທາງຕ້ອງລະບຸຊຸດຄວາມໄວ້ໃຈທີ່ຖືກຕ້ອງ ແລະ ອ່ານໄດ້ສຳລັບລູກຄ້ານີ້. ມັນບໍ່ແມ່ນໃບຢັ້ງຢືນເວັບໄຊທີ່ດາວໂຫລດມາ ແລ້ວເລືອກພຽງເພາະການເຊື່ອມຕໍ່ລົ້ມເຫຼວ.

ຕົວແປສະພາບແວດລ້ອມ REQUESTS_CA_BUNDLE ແມ່ນຂໍ້ມູນຄວາມໄວ້ໃຈທີ່ໄດ້ຮັບການສະໜັບສະໜູນອີກອັນໜຶ່ງ. ກວດເບິ່ງເສັ້ນທາງສົ່ງຕົວຈິງຖ້າມັນເບິ່ງຄືບໍ່ມີປະສິດທິພາບ; ຂະບວນການຄຳຮ້ອງທີ່ກຽມໄວ້ ແລະ ການຕັ້ງຄ່າທີ່ຊັດເຈນສາມາດປ່ຽນວິທີ ການລວມການຕັ້ງຄ່າສະພາບແວດລ້ອມ.

ທ່ານບໍ່ຄວນຕ້ອງການກະແຈສ່ວນຕົວຂອງ CA

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

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

ເມື່ອຂໍ້ຜິດພາດຕໍ່ໄປປາກົດ ໃຫ້ບອກການດຳເນີນການ: ໂຫຼດໄຟລ໌ CA, ກວດສອບໃບຢັ້ງຢືນຄູ່ສົນທະນາ ຫຼື ສະແດງຕົວຕົນລູກຄ້າ. ການຍ້າຍໄຟລ໌ລະຫວ່າງ verify ແລະ cert ຈົນກວ່າຂໍ້ຄວາມຈະປ່ຽນ ບໍ່ແມ່ນວິທີທີ່ໜ້າເຊື່ອຖືໃນການເລືອກບົດບາດຂອງມັນ.

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