Modificar solicitações de rede no Manifesto V3
O Manifest V3 muda a forma como as extensões lidam com a modificação de solicitações de rede. Em vez de interceptar solicitações de rede e alterá-las durante a execução com chrome.webRequest, a extensão especifica regras que descrevem as ações a serem realizadas quando um determinado conjunto de condições for atendido. Para isso, use a API Declarative Net Request.
As APIs Web Request e Declarative Net Request são significativamente diferentes. Em vez de substituir uma chamada de função por outra, é necessário reescrever seu código em termos de casos de uso. Esta seção mostra esse processo.
No Manifesto V2, bloquear solicitações da Web pode prejudicar significativamente o desempenho das extensões e das páginas em que elas funcionam. O namespace webRequest dá suporte a nove eventos potencialmente de bloqueio, cada um usando um número ilimitado de manipuladores de eventos. Para piorar, cada página da Web pode ser bloqueada por várias extensões, e as permissões necessárias para isso são invasivas. O Manifest V3 protege contra esse problema substituindo os retornos de chamada por regras declarativas.
Esta é a segunda de três seções que descrevem as mudanças necessárias para o código que não faz parte do service worker de extensão. Ele descreve a conversão de solicitações da Web de bloqueio, usadas pelo Manifest V2, em solicitações de rede declarativas, usadas pelo Manifesto V3. As outras duas seções abordam a atualização do código necessário para migrar para o Manifest V3 e o aumento da segurança.
Atualizar permissões
Faça as seguintes mudanças no campo "permissions" do manifest.json.
- Remova a permissão
"webRequest"se você não precisar mais observar solicitações de rede. - Mover padrões de correspondência de
"permissions"para"host_permissions".
Você precisará adicionar outras permissões, dependendo do caso de uso. Essas permissões são descritas com o caso de uso compatível.
Criar regras de solicitação de rede declarativas
Para criar regras de solicitação net declarativas, é preciso adicionar um objeto "declarative_net_request" ao manifest.json. O bloco "declarative_net_request" contém uma matriz de objetos "rule_resource" que apontam para um arquivo de regra. O arquivo da regra contém uma matriz de objetos que especificam uma ação e as condições em que essas ações são invocadas.
Casos de uso comuns
As seções a seguir descrevem casos de uso comuns para solicitações de rede declarativas. As instruções abaixo são apenas um breve resumo. Mais informações sobre todas as informações são descritas na referência da API em chrome.declarativeNetRequest.
Bloquear um único URL
Um caso de uso comum no Manifesto V2 era bloquear solicitações da Web usando o evento onBeforeRequest no script em segundo plano.
chrome.webRequest.onBeforeRequest.addListener((e) => {
return { cancel: true };
}, { urls: ["https://www.example.com/*"] }, ["blocking"]);
Para o Manifesto V3, crie uma nova regra declarativeNetRequest usando o tipo de ação "block". Observe o objeto "condition" na regra de exemplo. O "urlFilter" substitui a opção urls transmitida ao listener webRequest. Uma matriz "resourceTypes" especifica a categoria dos recursos a serem bloqueados. Este exemplo bloqueia apenas a página HTML principal, mas é possível, por exemplo, bloquear apenas fontes.
[
{
"id" : 1,
"priority": 1,
"action" : { "type" : "block" },
"condition" : {
"urlFilter" : "||example.com",
"resourceTypes" : ["main_frame"]
}
}
]
Para que isso funcione, atualize as permissões da extensão. No manifest.json, substitua a permissão "webRequestBlocking" pela "declarativeNetRequest". O URL é removido do campo "permissions" porque o bloqueio de conteúdo não exige permissões de host. Conforme mostrado acima, o arquivo de regras especifica os hosts aos quais uma solicitação de rede declarativa se aplica.
Se você quiser testar isso, o código abaixo está disponível no nosso repositório de exemplos.
"permissions": [
"webRequestBlocking",
"https://*.example.com/*"
]
"permissions": [
"declarativeNetRequest",
]
Redirecionar vários URLs
Outro caso de uso comum no Manifesto V2 foi usar o evento BeforeRequest para redirecionar solicitações da 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"]
);
Para o Manifest V3, use o tipo de ação "redirect". Como antes, "urlFilter" substitui a opção url transmitida ao listener webRequest. Observe que, nesse exemplo, o objeto "action" do arquivo de regra contém um campo "redirect" com o URL a ser retornado em vez do URL que está sendo filtrado.
[
{
"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"]
}
}
Este cenário também requer mudanças nas permissões da extensão. Como antes, substitua a permissão "webRequestBlocking" pela permissão "declarativeNetRequest". Os URLs são novamente movidos de manifest.json para um arquivo de regras. O redirecionamento também exige a permissão "declarativeNetRequestWithHostAccess", além da permissão do host.
Se você quiser testar isso, o código abaixo está disponível no nosso repositório de exemplos.
"permissions": [
"webRequestBlocking",
"https://developer.chrome.com/docs/extensions/*",
"https://developer.chrome.com/docs/extensions/reference"
]
"permissions": [
"declarativeNetRequestWithHostAccess"
],
"host_permissions": [
"https://developer.chrome.com/*"
]
Bloquear cookies
No Manifesto V2, o bloqueio de cookies exige a interceptação dos cabeçalhos de solicitação da Web antes que eles sejam enviados e a remoção de um cabeçalho específico.
chrome.webRequest.onBeforeSendHeaders.addListener(
function(details) {
removeHeader(details.requestHeaders, 'cookie');
return {requestHeaders: details.requestHeaders};
},
// filters
{urls: ['https://*/*', 'http://*/*']},
// extraInfoSpec
['blocking', 'requestHeaders', 'extraHeaders']);
O Manifesto V3 também faz isso com uma regra em um arquivo de regras. Desta vez, o tipo de ação é "modifyHeaders". O arquivo usa uma matriz de objetos "requestHeaders" especificando os cabeçalhos a serem modificados e como fazer isso. O objeto "condition" contém apenas uma matriz "resourceTypes". Ele é compatível com os mesmos valores dos exemplos anteriores.
Se você quiser testar isso, o código abaixo está disponível no nosso repositório de exemplos.
[
{
"id": 1,
"priority": 1,
"action": {
"type": "modifyHeaders",
"requestHeaders": [
{ "header": "cookie", "operation": "remove" }
]
},
"condition": {
"urlFilter": "|*?no-cookies=1",
"resourceTypes": ["main_frame"]
}
}
]
Este cenário também requer mudanças nas permissões da extensão. Como antes, substitua a permissão "webRequestBlocking" pela permissão "declarativeNetRequest".
"permissions": [
"webRequest",
"webRequestBlocking",
"https://*/*",
"http://*/*"
],
"permissions": [
"declarativeNetRequest",
],
"host_permissions": [
""
]