Sprawdź obserwowany adres IP wyjścia z rozszerzenia Chrome

Wyślij ograniczone żądanie z pochodzenia rozszerzenia do kontrolowanego punktu końcowego i zgłoś, co test faktycznie dowodzi.

Test serwera proxy w rozszerzeniu Chrome potrzebuje celu z przewidywalną odpowiedzią. Użyj punktu końcowego HTTPS, który kontrolujesz, na przykład takiego, który zwraca mały obiekt JSON z obserwowanym adresem.

Uruchom żądanie z kontekstu rozszerzenia, na przykład z jego service workera lub strony rozszerzenia, z punktem końcowym w host permissions manifestu:

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

Uprawnienie hosta nie daje skryptowi treści tych samych uprawnień między źródłami. Trzymaj test w kontekście rozszerzenia, zamiast zakładać, że wstrzyknięty skrypt może wysłać to samo żądanie.

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);
  }
}

Nazwa hosta jest wartością zastępczą. Serwer i klient muszą uzgodnić format odpowiedzi i politykę pamięci podręcznej. Obsłuż odrzucone żądania i uszkodzone odpowiedzi w wywołującym kodzie rozszerzenia, zamiast pokazywać je jako prawidłowy adres wyjścia.

Nazwij obserwację precyzyjnie

Pomyślny wynik dowodzi, że to żądanie dotarło do punktu końcowego i otrzymało oczekiwaną postać odpowiedzi. Porównaj obserwowany adres z zamierzoną trasą tam, gdzie to porównanie ma sens. Adres IP, na którym nasłuchuje skonfigurowany serwer proxy, nie musi być jego publicznym wyjściem.

Reguła PAC lub lista wyjątków może wysłać test bezpośrednio, podczas gdy inny cel korzysta z serwera proxy. Odczyt ustawień proxy dostarcza dowodu konfiguracji; żądanie dostarcza dowodu dla tego celu. Żadne z nich samo nie dowodzi, że każda karta lub URL podąża tą samą trasą.

Trzymaj w interfejsie osobno limit czasu, błąd HTTP i nieoczekiwaną treść. „Ten test nie powiódł się” jest użyteczniejsze niż ogłoszenie całej maszyny offline po jednym żądaniu.

Powiązane artykuły