ການກວດສອບພຣັອກຊີໃນສ່ວນຂະຫຍາຍ Chrome ຕ້ອງການປາຍທາງທີ່ມີການຕອບສະໜອງທີ່ຄາດເດົາໄດ້. ໃຊ້ຈຸດປາຍທາງ HTTPS ທີ່ທ່ານຄວບຄຸມ ເຊັ່ນອັນທີ່ສົ່ງຄືນວັດຖຸ JSON ນ້ອຍໆທີ່ມີທີ່ຢູ່ທີ່ມັນເຫັນ.

ເລີ່ມຄຳຮ້ອງຈາກບໍລິບົດຂອງສ່ວນຂະຫຍາຍ ເຊັ່ນ service worker ຫຼື ໜ້າສ່ວນຂະຫຍາຍ ໂດຍໃສ່ຈຸດປາຍທາງໃນ host permissions ຂອງ manifest:

"host_permissions": ["https://probe.example/*"]

ການອະນຸຍາດໂຮສບໍ່ໄດ້ໃຫ້ content script ສິດຂ້າມແຫຼ່ງກຳເນີດດຽວກັນ. ເກັບການກວດສອບໄວ້ໃນບໍລິບົດຂອງສ່ວນຂະຫຍາຍ ແທນທີ່ຈະສົມມຸດວ່າສະຄຣິບທີ່ສັກເຂົ້າໄປສາມາດສົ່ງຄຳຮ້ອງດຽວກັນໄດ້.

async function probe() {
  const controller = new AbortController();
  const timer = setTimeout(() => controller.abort(), 5000);
  try {
    const response = await fetch('https://probe.example/ip', {
      cache: 'no-store',
      signal: controller.signal,
    });
    if (!response.ok) throw new Error(`HTTP ${response.status}`);
    const result = await response.json();
    if (typeof result.ip !== 'string') throw new Error('Bad probe body');
    return result.ip;
  } finally {
    clearTimeout(timer);
  }
}

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

ຕັ້ງຊື່ການສັງເກດໃຫ້ຊັດເຈນ

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

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

ເກັບເວລາກຳນົດ, ຂໍ້ຜິດພາດ HTTP ແລະ ເນື້ອຄວາມທີ່ບໍ່ຄາດຄິດໄວ້ແຍກຈາກກັນໃນອິນເຕີເຟດ. “ການກວດສອບນີ້ລົ້ມເຫຼວ” ມີປະໂຫຍດກວ່າການປະກາດວ່າເຄື່ອງທັງໝົດອອບລາຍຫຼັງຄຳຮ້ອງດຽວ.

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