ການກວດສອບຕົວຕົນພື້ນຖານຂອງ proxy ສຳລັບຄຳຮ້ອງ REST Assured

REST Assured ມີຂໍ້ກຳນົດ proxy ທີ່ພາທີ່ຢູ່ ແລະ ຂໍ້ມູນຢືນຢັນຂອງຕົວກາງໄປນຳກັນ:

import static io.restassured.RestAssured.given;
import io.restassured.specification.ProxySpecification;

var proxy = ProxySpecification.host("proxy.example")
    .withPort(8080)
    .withScheme("http")
    .withAuth(proxyUser, proxyPassword);

var request = given().proxy(proxy);

ແອັບພລິເຄຊັນສະໜອງ proxyUser ແລະ proxyPassword ຈາກແຫຼ່ງຂໍ້ມູນຢືນຢັນປົກກະຕິຂອງມັນ. ສ່ວນນີ້ສ້າງຂໍ້ກຳນົດຄຳຮ້ອງ; ເອີ້ນ URL ຂອງ API ທີ່ຕ້ອງການຜ່ານ request ໂດຍໃຊ້ໂຄ້ດຄຳຮ້ອງ ແລະ ການກວດສອບປົກກະຕິຂອງການທົດສອບ.

ແຜນ http ອະທິບາຍຈຸດສຸດທ້າຍຂອງ proxy. URL ຂອງ API ສາມາດຄົງເປັນ HTTPS. ກົນໄກ withAuth ຂອງ REST Assured ໃຫ້ການກວດສອບຕົວຕົນ proxy ພື້ນຖານ; ມັນບໍ່ໄດ້ເຈລະຈາກັບທຸກແຜນການກວດສອບຕົວຕົນຂອງອົງກອນພຽງແຕ່ຍ້ອນວ່າມີການໃຫ້ສອງສະຕຣິງ.

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

ເມື່ອຄວາມຜິດພາດທີ່ເຫຼືອແມ່ນຄວາມໄວ້ວາງໃຈໃນໃບຮັບຮອງ

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

REST Assured ເປີດເຜີຍ trustStore ສຳລັບຈຸດປະສົງນັ້ນ. truststore ປ່ຽນຜູ້ອອກໃບຮັບຮອງທີ່ລູກຄ້າ HTTPS ໄວ້ວາງໃຈ; ມັນບໍ່ໄດ້ເລືອກ proxy ຫຼື ໃຫ້ການເຂົ້າສູ່ລະບົບຂອງມັນ. ເປີດການກວດສອບຊື່ໂຮສ ແລະ ໃບຮັບຮອງໄວ້ ແທນທີ່ຈະໃຊ້ການຈັບມື accept-all ເພື່ອຮັບໃບຮັບຮອງໃດໆທີ່ຖືກສະເໜີ.