Chrome-ის გაფართოებიდან დაკვირვებული გამავალი IP-ის შემოწმება
გაგზავნეთ შეზღუდული მოთხოვნა გაფართოების წყაროდან თქვენ მიერ კონტროლირებად საბოლოო წერტილზე და მოგვახსენეთ, რას ამტკიცებს შემოწმება სინამდვილეში.
Chrome-ის გაფართოებაში პროქსის შემოწმებას სჭირდება დანიშნულება წინასწარ ცნობადი პასუხით. გამოიყენეთ HTTPS საბოლოო წერტილი, რომელსაც თქვენ აკონტროლებთ, მაგალითად ის, რომელიც აბრუნებს პატარა JSON ობიექტს მის მიერ დანახული მისამართით.
გაუშვით მოთხოვნა გაფართოების კონტექსტიდან, მაგალითად მისი service worker-იდან ან გაფართოების გვერდიდან, საბოლოო წერტილი manifest-ის host permissions-ში მოთავსებული:
"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 შეცდომა და მოულოდნელი სხეული. „ეს შემოწმება ვერ შესრულდა“ უფრო სასარგებლოა, ვიდრე ერთი მოთხოვნის შემდეგ მთელი მანქანის ოფლაინად გამოცხადება.