Modifica delle richieste di rete in Manifest V3
Il file manifest V3 cambia il modo in cui le estensioni gestiscono la modifica delle richieste di rete. Invece di intercettare le richieste di rete e modificarle in fase di runtime con chrome.webRequest
, la tua estensione specifica le regole che descrivono le azioni da eseguire quando è soddisfatto un determinato insieme di condizioni. A questo scopo, utilizza l'API Declarative Net Request.
L'API Web Request e le API Declarative Net Request sono notevolmente diverse. Anziché sostituire una chiamata funzione con un'altra, devi riscrivere il codice in termini di casi d'uso. Questa sezione ti accompagna nella procedura.
In Manifest V2, il blocco delle richieste web potrebbe ridurre significativamente sia le prestazioni delle estensioni sia quelle delle pagine con cui funzionano. Lo spazio dei nomi webRequest
supporta nove eventi potenzialmente bloccanti, ognuno dei quali richiede un numero illimitato di gestori di eventi. Come se non bastasse, ogni pagina web è potenzialmente bloccata da più estensioni e le autorizzazioni richieste sono invasive. Manifest V3 protegge da questo problema sostituendo i callback con regole dichiarative.
Questa è la seconda delle tre sezioni che descrivono le modifiche necessarie per il codice che non fa parte del service worker dell'estensione. Descrive la conversione delle richieste web di blocco, utilizzate da Manifest V2, in richieste nette dichiarative, utilizzate da Manifest V3. Le altre due sezioni riguardano l'aggiornamento del codice necessario per la migrazione a Manifest V3 e il miglioramento della sicurezza.
Aggiorna autorizzazioni
Apporta le seguenti modifiche al campo "permissions"
in manifest.json
.
- Rimuovi l'autorizzazione
"webRequest"
se non hai più bisogno di osservare le richieste di rete. - Sposta i pattern di corrispondenza da
"permissions"
a"host_permissions"
.
Dovrai aggiungere altre autorizzazioni, a seconda del caso d'uso. Queste autorizzazioni sono descritte con il caso d'uso che supporta.
Crea regole di richiesta netta dichiarative
La creazione di regole di richiesta netta dichiarative richiede l'aggiunta di un oggetto "declarative_net_request"
a manifest.json
. Il blocco "declarative_net_request"
contiene un array di oggetti "rule_resource"
che puntano a un file delle regole. Il file delle regole contiene un array di oggetti che specifica un'azione e le condizioni in cui vengono richiamate.
Casi d'uso comuni
Le seguenti sezioni descrivono i casi d'uso comuni per le richieste nette dichiarative. Le istruzioni riportate di seguito forniscono solo un breve riepilogo. Ulteriori informazioni su tutte le informazioni presenti qui sono descritte nella sezione di riferimento dell'API in chrome.declarativeNetRequest
Bloccare un singolo URL
Un caso d'uso comune in Manifest V2 era bloccare le richieste web utilizzando l'evento onBeforeRequest
nello script in background.
chrome.webRequest.onBeforeRequest.addListener((e) => { return { cancel: true }; }, { urls: ["https://www.example.com/*"] }, ["blocking"]);
Per Manifest V3, crea una nuova regola declarativeNetRequest
utilizzando il tipo di azione "block"
. Osserva l'oggetto "condition"
nella regola di esempio. Il suo "urlFilter"
sostituisce l'opzione urls
passata al listener webRequest
. Un array "resourceTypes"
specifica la categoria di risorse da bloccare. Questo esempio blocca solo la pagina HTML principale, ma puoi, ad esempio, bloccare solo i caratteri.
[ { "id" : 1, "priority": 1, "action" : { "type" : "block" }, "condition" : { "urlFilter" : "||example.com", "resourceTypes" : ["main_frame"] } } ]
Per far sì che funzioni, devi aggiornare le autorizzazioni dell'estensione. In manifest.json
, sostituisci l'autorizzazione "webRequestBlocking"
con l'autorizzazione "declarativeNetRequest"
. Tieni presente che l'URL viene rimosso dal campo "permissions"
perché il blocco dei contenuti non richiede autorizzazioni di host. Come mostrato sopra, il file delle regole specifica l'host o gli host a cui si applica una richiesta di rete dichiarativa.
Se vuoi provare, il codice seguente è disponibile nel nostro repository di esempio.
"permissions": [ "webRequestBlocking", "https://*.example.com/*" ]
"permissions": [ "declarativeNetRequest", ]
Reindirizzare più URL
Un altro caso d'uso comune in Manifest V2 consiste nell'utilizzare l'evento BeforeRequest
per reindirizzare le richieste web.
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"] );
Per Manifest V3, utilizza il tipo di azione "redirect"
. Come in precedenza, "urlFilter"
sostituisce l'opzione url
passata al listener webRequest
. In questo esempio, l'oggetto "action"
del file delle regole contiene un campo "redirect"
contenente l'URL da restituire anziché l'URL filtrato.
[ { "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"] } }
Questo scenario richiede anche modifiche alle autorizzazioni dell'estensione. Come prima, sostituisci l'autorizzazione "webRequestBlocking"
con l'autorizzazione "declarativeNetRequest"
. Gli URL vengono nuovamente spostati da manifest.json
a un file delle regole. Tieni presente che il reindirizzamento richiede anche l'autorizzazione "declarativeNetRequestWithHostAccess"
oltre all'autorizzazione host.
Se vuoi provare, il codice seguente è disponibile nel nostro repository di esempio.
"permissions": [ "webRequestBlocking", "https://developer.chrome.com/docs/extensions/*", "https://developer.chrome.com/docs/extensions/reference" ]
"permissions": [ "declarativeNetRequestWithHostAccess" ], "host_permissions": [ "https://developer.chrome.com/*" ]
Blocca i cookie
In Manifest V2, per bloccare i cookie è necessario intercettare le intestazioni delle richieste web prima che vengano inviate e rimuoverne una specifica.
chrome.webRequest.onBeforeSendHeaders.addListener( function(details) { removeHeader(details.requestHeaders, 'cookie'); return {requestHeaders: details.requestHeaders}; }, // filters {urls: ['https://*/*', 'http://*/*']}, // extraInfoSpec ['blocking', 'requestHeaders', 'extraHeaders']);
Questa operazione viene eseguita anche in Manifest V3 in un file delle regole. Questa volta il tipo di azione è "modifyHeaders"
. Il file accetta un array di oggetti "requestHeaders"
che specifica le intestazioni da modificare e la modalità di modifica. Nota che l'oggetto "condition"
contiene solo un array "resourceTypes"
. Supporta gli stessi valori degli esempi precedenti.
Se vuoi provare, il codice seguente è disponibile nel nostro repository di esempio.
[ { "id": 1, "priority": 1, "action": { "type": "modifyHeaders", "requestHeaders": [ { "header": "cookie", "operation": "remove" } ] }, "condition": { "urlFilter": "|*?no-cookies=1", "resourceTypes": ["main_frame"] } } ]
Questo scenario richiede anche modifiche alle autorizzazioni dell'estensione. Come prima, sostituisci l'autorizzazione "webRequestBlocking"
con l'autorizzazione "declarativeNetRequest"
.
"permissions": [ "webRequest", "webRequestBlocking", "https://*/*", "http://*/*" ],
"permissions": [ "declarativeNetRequest", ], "host_permissions": [ "" ]