یک بررسی پروکسی در افزونه Chrome به مقصدی با پاسخ قابل پیش‌بینی نیاز دارد. از یک نقطه پایانی HTTPS که خودتان کنترل می‌کنید استفاده کنید، برای نمونه نقطه‌ای که یک شیء JSON کوچک شامل نشانی مشاهده‌شده بازمی‌گرداند.

درخواست را از بافت افزونه، مانند service worker یا صفحه افزونه، اجرا کنید و نقطه پایانی را در 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 و بدنه غیرمنتظره را در رابط کاربری جدا نگه دارید. «این بررسی شکست خورد» مفیدتر از اعلام آفلاین بودن کل دستگاه پس از یک درخواست است.

مقالات مرتبط