Modyfikowanie żądań sieciowych w pliku manifestu V3
Manifest V3 zmienia sposób, w jaki rozszerzenia modyfikują żądania sieciowe. Zamiast przechwytywać żądania sieciowe i zmieniać je w czasie działania za pomocą chrome.webRequest
, rozszerzenie określa reguły, które opisują działania do wykonania po spełnieniu określonego zestawu warunków. Zrób to za pomocą interfejsu Declarative Net Request API.
Interfejsy Web Request API i Deklaratywne Net Request API różnią się znacznie od siebie. Zamiast zastępowania jednego wywołania funkcji innym musisz przerobić kod pod kątem przypadków użycia. W tej sekcji opisujemy ten proces.
W przypadku manifestu v2 blokowanie żądań internetowych może znacznie obniżyć wydajność rozszerzeń i stron, z którymi współpracują. Przestrzeń nazw webRequest
obsługuje 9 zdarzeń, które mogą blokować działanie aplikacji. Każde z nich może wywołać nieograniczoną liczbę przetwarzaczy zdarzeń. Co gorsza, każda strona internetowa może być blokowana przez wiele rozszerzeń, a wymagające tego uprawnienia mogą być inwazyjne. Manifest V3 chroni przed tym problemem przez zastąpienie wywołań zwrotnych regułami deklaratywnymi.
To druga z 3 sekcji opisujących zmiany wymagane w kodzie, który nie jest częścią rozszerzenia usługi. Opisuje ona konwertowanie blokujących żądań sieciowych używanych przez Manifest V2 na deklaratywnie żądania sieciowe używane przez Manifest V3. Pozostałe 2 sekcje dotyczą aktualizowania kodu, który jest potrzebny do przejścia na Manifest V3, oraz ulepszania zabezpieczeń.
Aktualizuj uprawnienia
Wprowadź te zmiany w polu "permissions"
w konfiguracji manifest.json
.
- Usuń uprawnienie
"webRequest"
, jeśli nie musisz już obserwować żądań sieciowych. - Przenieś wzorce dopasowania z poziomu
"permissions"
na poziom"host_permissions"
.
W zależności od przypadku użycia musisz dodać inne uprawnienia. Te uprawnienia są opisane w ramach przypadku użycia, który obsługują.
Tworzenie deklaratywnych reguł żądań sieciowych
Aby utworzyć deklaratywne reguły sieciowe, musisz dodać obiekt "declarative_net_request"
do obiektu manifest.json
. Blok "declarative_net_request"
zawiera tablicę obiektów "rule_resource"
, które wskazują plik reguł. Plik reguły zawiera tablicę obiektów określających działanie i warunki, w których są one wywoływane.
Typowe zastosowania
W kolejnych sekcjach opisano typowe przypadki użycia deklaratywnych zapytań sieciowych. Poniżej znajdziesz tylko krótkie omówienie. Więcej informacji o wszystkich opisanych tu kwestiach znajdziesz w dokumentacji interfejsu API w sekcji chrome.declarativeNetRequest
.
Blokowanie pojedynczego adresu URL
Częstym przypadkiem użycia w pliku manifestu V2 było blokowanie żądań sieciowych za pomocą zdarzenia onBeforeRequest
w skrypcie uruchamianym w tle.
chrome.webRequest.onBeforeRequest.addListener((e) => {
return { cancel: true };
}, { urls: ["https://www.example.com/*"] }, ["blocking"]);
W przypadku pliku manifestu V3 utwórz nową regułę declarativeNetRequest
, używając typu działania "block"
. Zwróć uwagę na obiekt "condition"
w przykładowej regule. Jego "urlFilter"
zastępuje opcję urls
przekazaną do odsłuchiwania przez webRequest
. Tablica "resourceTypes"
określa kategorię zasobów do zablokowania. W tym przykładzie blokowana jest tylko główna strona HTML, ale możesz zablokować na przykład tylko czcionki.
[
{
"id" : 1,
"priority": 1,
"action" : { "type" : "block" },
"condition" : {
"urlFilter" : "||example.com",
"resourceTypes" : ["main_frame"]
}
}
]
Aby to działało, musisz zaktualizować uprawnienia rozszerzenia. W manifest.json
zastąp uprawnienie "webRequestBlocking"
uprawnieniem "declarativeNetRequest"
. Zwróć uwagę, że adres URL został usunięty z pola "permissions"
, ponieważ blokowanie treści nie wymaga uprawnień hosta. Jak widać powyżej, plik reguły określa hosta lub hostów, do których ma zastosowanie deklaratywna prośba o netto.
Jeśli chcesz to wypróbować, kod poniżej jest dostępny w repozytorium z przykładami.
"permissions": [
"webRequestBlocking",
"https://*.example.com/*"
]
"permissions": [
"declarativeNetRequest",
]
Przekierowywanie wielu adresów URL
Innym częstym zastosowaniem w przypadku Manifest V2 było używanie zdarzenia BeforeRequest
do przekierowywania żądań internetowych.
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"]
);
W przypadku pliku manifestu w wersji 3 użyj typu działania "redirect"
. Jak poprzednio, "urlFilter"
zastępuje opcję url
przekazaną do słuchacza webRequest
. Zwróć uwagę, że w tym przykładzie obiekt "action"
pliku reguł zawiera pole "redirect"
, w którym zamiast filtrowanego adresu URL znajduje się zwracany adres 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"]
}
}
W tym przypadku musisz też zmienić uprawnienia rozszerzenia. Podobnie jak wcześniej zastąp uprawnienie "webRequestBlocking"
uprawnieniem "declarativeNetRequest"
. Adresy URL są ponownie przenoszone z folderu manifest.json
do pliku reguł. Pamiętaj, że przekierowywanie wymaga uprawnienia "declarativeNetRequestWithHostAccess"
oprócz uprawnienia hosta.
Jeśli chcesz to wypróbować, kod poniżej jest dostępny w repozytorium z przykładami.
"permissions": [
"webRequestBlocking",
"https://developer.chrome.com/docs/extensions/*",
"https://developer.chrome.com/docs/extensions/reference"
]
"permissions": [
"declarativeNetRequestWithHostAccess"
],
"host_permissions": [
"https://developer.chrome.com/*"
]
Blokowanie plików cookie
W pliku manifestu V2 zablokowanie plików cookie wymaga przechwycenia nagłówków żądań internetowych przed ich wysłaniem i usunięcia konkretnego nagłówka.
chrome.webRequest.onBeforeSendHeaders.addListener(
function(details) {
removeHeader(details.requestHeaders, 'cookie');
return {requestHeaders: details.requestHeaders};
},
// filters
{urls: ['https://*/*', 'http://*/*']},
// extraInfoSpec
['blocking', 'requestHeaders', 'extraHeaders']);
Manifest V3 również wykonuje to za pomocą reguły w pliku reguł. Tym razem typ działania to "modifyHeaders"
. Plik przyjmuje tablicę obiektów "requestHeaders"
, która określa nagłówki do zmodyfikowania i sposób ich modyfikacji. Zwróć uwagę, że obiekt "condition"
zawiera tylko tablicę "resourceTypes"
. Obsługuje te same wartości co w poprzednich przykładach.
Jeśli chcesz to wypróbować, poniżej znajdziesz kod dostępny w repozytorium z przykładami.
[
{
"id": 1,
"priority": 1,
"action": {
"type": "modifyHeaders",
"requestHeaders": [
{ "header": "cookie", "operation": "remove" }
]
},
"condition": {
"urlFilter": "|*?no-cookies=1",
"resourceTypes": ["main_frame"]
}
}
]
W tym scenariuszu trzeba też zmienić uprawnienia rozszerzenia. Podobnie jak wcześniej zastąp uprawnienie "webRequestBlocking"
uprawnieniem "declarativeNetRequest"
.
"permissions": [
"webRequest",
"webRequestBlocking",
"https://*/*",
"http://*/*"
],
"permissions": [
"declarativeNetRequest",
],
"host_permissions": [
"