ブロックしているウェブ リクエスト リスナーを置き換える

Manifest V3 でネットワーク リクエストを変更する

Manifest V3 では、拡張機能がネットワーク リクエストの変更を処理する方法が変更されました。この拡張機能では、ネットワーク リクエストをインターセプトし、chrome.webRequest を使用して実行時に変更するのではなく、指定された一連の条件が満たされたときに実行するアクションを記述するルールを指定します。これには、Declarative Net Request API を使用します。

Web Request API と Declarative Net Request API は大きく異なります。ある関数呼び出しを別の関数呼び出しに置き換えるのではなく、ユースケースの観点からコードを書き換える必要があります。このセクションでは、そのプロセスについて説明します。

Manifest V2 では、ウェブ リクエストをブロックすると、拡張機能のパフォーマンスと、拡張機能が連携するページのパフォーマンスの両方が大幅に低下する可能性があります。webRequest 名前空間は 9 つのブロッキング イベントをサポートしており、各イベントは無制限のイベント ハンドラを取ることができます。さらに悪いことに、各ウェブページは複数の拡張機能によってブロックされる可能性があり、そのために必要な権限が侵害されることもあります。Manifest V3 では、コールバックを宣言的なルールに置き換えることで、この問題を防ぎます。

これは、拡張機能 Service Worker の一部ではないコードに必要な変更について説明する 3 つのセクションの 2 番目のセクションです。ここでは、Manifest V2 で使用されるウェブ リクエストをブロックするものを、Manifest V3 で使用される宣言型のネット リクエストに変換する方法について説明します。残りの 2 つのセクションでは、Manifest V3 への移行に必要なコードの更新とセキュリティの向上について説明します。

許可を更新

manifest.json の "permissions" フィールドに次の変更を加えます。

• ネットワーク リクエストをモニタリングする必要がなくなった場合は、"webRequest" 権限を削除します。
• 一致パターンを "permissions" から "host_permissions" に移動しました。

ユースケースに応じて、他の権限を追加する必要があります。これらの権限は、サポートするユースケースとともに説明されています。

宣言型のネット リクエスト ルールを作成する

宣言型のネット リクエスト ルールを作成するには、"declarative_net_request" オブジェクトを manifest.json に追加する必要があります。"declarative_net_request" ブロックには、ルールファイルを指す "rule_resource" オブジェクトの配列が含まれます。ルールファイルには、アクションとそのアクションの呼び出し条件を指定するオブジェクトの配列が含まれます。

一般的なユースケース

以降のセクションでは、宣言型ネット リクエストの一般的なユースケースについて説明します。以下の手順は、概要を説明するにすぎません。ここでのあらゆる情報について詳しくは、chrome.declarativeNetRequest の API リファレンスをご覧ください。

1 つの URL をブロックする

Manifest V2 の一般的な使用例は、バックグラウンド スクリプトで onBeforeRequest イベントを使用してウェブ リクエストをブロックすることです。

chrome.webRequest.onBeforeRequest.addListener((e) => {
    return { cancel: true };
}, { urls: ["https://www.example.com/*"] }, ["blocking"]);

Manifest V3 では、"block" アクション タイプを使用して新しい declarativeNetRequest ルールを作成します。サンプルルールの "condition" オブジェクトに注目してください。webRequest リスナーに渡される urls オプションを "urlFilter" に置き換えます。"resourceTypes" 配列は、ブロックするリソースのカテゴリを指定します。この例ではメインの HTML ページのみをブロックしていますが、たとえばフォントのみをブロックすることもできます。

[
  {
    "id" : 1,
    "priority": 1,
    "action" : { "type" : "block" },
    "condition" : {
      "urlFilter" : "||example.com",
      "resourceTypes" : ["main_frame"]
    }
  }
]

これを行うには、拡張機能の権限を更新する必要があります。manifest.json で、"webRequestBlocking" 権限を "declarativeNetRequest" 権限に置き換えます。コンテンツをブロックするにはホストの権限が必要ないため、"permissions" フィールドから URL が削除されています。上記のように、ルールファイルでは宣言型のネット リクエストを適用するホストを指定します。

試してみる場合は、以下のコードがサンプル リポジトリから入手できます。

  "permissions": [
    "webRequestBlocking",
    "https://*.example.com/*"
  ]

  "permissions": [
    "declarativeNetRequest",
  ]

複数の URL をリダイレクトする

Manifest V2 のもう 1 つの一般的な使用例は、BeforeRequest イベントを使用してウェブ リクエストをリダイレクトすることです。

chrome.webRequest.onBeforeRequest.addListener((e) => {
    console.log(e);
    return { redirectUrl: "https://developer.chrome.com/docs/extensions/mv3/intro/" };
  }, { 
    urls: [
      "https://developer.chrome.com/docs/extensions/mv2/"
    ]
  }, 
  ["blocking"]
);

Manifest V3 の場合は、"redirect" アクション タイプを使用します。以前と同様に、"urlFilter" は webRequest リスナーに渡される url オプションを置き換えます。この例では、ルールファイルの "action" オブジェクトの "redirect" フィールドに、フィルタ対象の URL の代わりに返す URL が含まれています。

[
  {
    "id" : 1,
    "priority": 1,
    "action": {
      "type": "redirect",
      "redirect": { "url": "https://developer.chrome.com/docs/extensions/mv3/intro/" }
    },
    "condition": {
      "urlFilter": "https://developer.chrome.com/docs/extensions/mv2/",
      "resourceTypes": ["main_frame"]
    }
  }

このシナリオでは、拡張機能の権限も変更する必要があります。以前と同様に、"webRequestBlocking" 権限を "declarativeNetRequest" 権限に置き換えます。URL は再び manifest.json からルールファイルに移動します。リダイレクトするには、ホスト権限に加えて "declarativeNetRequestWithHostAccess" 権限も必要です。

試してみる場合は、以下のコードがサンプル リポジトリから入手できます。

  "permissions": [
    "webRequestBlocking",
    "https://developer.chrome.com/docs/extensions/*",
    "https://developer.chrome.com/docs/extensions/reference"
  ]

  "permissions": [
    "declarativeNetRequestWithHostAccess"
  ],
  "host_permissions": [
    "https://developer.chrome.com/*"
  ]

Cookie をブロックする

Manifest V2 で Cookie をブロックするには、ウェブ リクエスト ヘッダーの送信前にインターセプトして、特定のヘッダーを削除する必要があります。

chrome.webRequest.onBeforeSendHeaders.addListener(
  function(details) {
    removeHeader(details.requestHeaders, 'cookie');
    return {requestHeaders: details.requestHeaders};
  },
  // filters
  {urls: ['https://*/*', 'http://*/*']},
  // extraInfoSpec
  ['blocking', 'requestHeaders', 'extraHeaders']);

Manifest V3 でも、ルールファイルのルールを使用してこれを行うことができます。今回のアクション タイプは "modifyHeaders" です。このファイルは、変更するヘッダーとその変更方法を指定する "requestHeaders" オブジェクトの配列を受け取ります。"condition" オブジェクトには "resourceTypes" 配列のみが含まれています。前の例と同じ値をサポートします。

試してみる場合は、以下のコードがサンプル リポジトリから入手できます。

[
  {
    "id": 1,
    "priority": 1,
    "action": {
      "type": "modifyHeaders",
      "requestHeaders": [
        { "header": "cookie", "operation": "remove" }
      ]
    },
    "condition": {
      "urlFilter": "|*?no-cookies=1",
      "resourceTypes": ["main_frame"]
    }
  }
]

このシナリオでは、拡張機能の権限も変更する必要があります。以前と同様に、"webRequestBlocking" 権限を "declarativeNetRequest" 権限に置き換えます。

  "permissions": [
    "webRequest",
    "webRequestBlocking",
    "https://*/*",
    "http://*/*"
  ],

  "permissions": [
    "declarativeNetRequest",
  ],
  "host_permissions": [
    ""
  ]