Cómo modificar las solicitudes de red en Manifest V3
Manifest V3 cambia la forma en que las extensiones controlan la modificación de las solicitudes de red. En lugar de interceptar solicitudes de red y alterarlas en el tiempo de ejecución con chrome.webRequest
, tu extensión especifica reglas que describen las acciones que se deben realizar cuando se cumple un conjunto determinado de condiciones. Para ello, usa la API de Declarative Net Request.
La API de Web Request y las APIs de Declarative Net Request son muy diferentes. En lugar de reemplazar una llamada a función por otra, debes volver a escribir el código en términos de casos de uso. En esta sección, se explica ese proceso.
En Manifest V2, bloquear las solicitudes web podría degradar significativamente el rendimiento de las extensiones y de las páginas con las que funcionan. El espacio de nombres webRequest
admite nueve eventos potencialmente bloqueantes, cada uno de los cuales toma una cantidad ilimitada de controladores de eventos. Para empeorar las cosas, es posible que varias extensiones bloqueen cada página web, y los permisos necesarios para ello son invasivos. El manifiesto V3 protege contra este problema reemplazando las devoluciones de llamada por reglas declarativas.
Esta es la segunda de tres secciones en las que se describen los cambios necesarios para el código que no forma parte del trabajador del servicio de la extensión. En él, se describe la conversión de solicitudes web de bloqueo, que usa el manifiesto V2, en solicitudes de red declarativas, que usa el manifiesto V3. En las otras dos secciones, se explica cómo actualizar tu código para migrar a Manifest V3 y mejorar la seguridad.
Actualizar permisos
Realiza los siguientes cambios en el campo "permissions"
de tu manifest.json
.
- Quita el permiso
"webRequest"
si ya no necesitas observar las solicitudes de red. - Se movió Match Patterns de
"permissions"
a"host_permissions"
.
Deberás agregar otros permisos, según tu caso de uso. Esos permisos se describen con el caso de uso que admiten.
Crea reglas de solicitud de red declarativa
Para crear reglas de solicitud de red declarativas, debes agregar un objeto "declarative_net_request"
a tu manifest.json
. El bloque "declarative_net_request"
contiene un array de objetos "rule_resource"
que apuntan a un archivo de reglas. El archivo de reglas contiene un array de objetos que especifican una acción y las condiciones en las que se invocan esas acciones.
Casos de uso habituales
En las siguientes secciones, se describen casos de uso comunes para las solicitudes de red declarativas. En las siguientes instrucciones, solo se proporciona un breve resumen. Puedes encontrar más información sobre todo lo que se describe aquí en la referencia de la API en chrome.declarativeNetRequest
.
Cómo bloquear una sola URL
Un caso de uso común en el manifiesto V2 era bloquear las solicitudes web con el evento onBeforeRequest
en la secuencia de comandos en segundo plano.
chrome.webRequest.onBeforeRequest.addListener((e) => { return { cancel: true }; }, { urls: ["https://www.example.com/*"] }, ["blocking"]);
Para Manifest V3, crea una nueva regla declarativeNetRequest
con el tipo de acción "block"
. Observa el objeto "condition"
en la regla de ejemplo. Su "urlFilter"
reemplaza la opción urls
que se pasa al objeto de escucha webRequest
. Un array "resourceTypes"
especifica la categoría de recursos que se bloquearán. En este ejemplo, solo se bloquea la página HTML principal, pero podrías, por ejemplo, bloquear solo las fuentes.
[ { "id" : 1, "priority": 1, "action" : { "type" : "block" }, "condition" : { "urlFilter" : "||example.com", "resourceTypes" : ["main_frame"] } } ]
Para que esto funcione, deberás actualizar los permisos de la extensión. En manifest.json
, reemplaza el permiso "webRequestBlocking"
por el permiso "declarativeNetRequest"
. Observa que la URL se quita del campo "permissions"
porque bloquear contenido no requiere permisos de host. Como se muestra más arriba, el archivo de reglas especifica el host o los hosts a los que se aplica una solicitud de red declarativa.
Si quieres probar esto, el siguiente código está disponible en nuestro repositorio de muestras.
"permissions": [ "webRequestBlocking", "https://*.example.com/*" ]
"permissions": [ "declarativeNetRequest", ]
Redirecciona varias URLs
Otro caso de uso común en el manifiesto V2 era usar el evento BeforeRequest
para redireccionar solicitudes 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 Manifest V3, usa el tipo de acción "redirect"
. Al igual que antes, "urlFilter"
reemplaza la opción url
que se pasa al objeto de escucha webRequest
. Ten en cuenta que, en este ejemplo, el objeto "action"
del archivo de reglas contiene un campo "redirect"
que contiene la URL que se mostrará en lugar de la URL que se filtra.
[ { "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"] } }
Esta situación también requiere cambios en los permisos de la extensión. Al igual que antes, reemplaza el permiso "webRequestBlocking"
por el permiso "declarativeNetRequest"
. Las URLs se vuelven a mover de manifest.json
a un archivo de reglas. Ten en cuenta que el redireccionamiento también requiere el permiso "declarativeNetRequestWithHostAccess"
, además del permiso de host.
Si quieres probar esto, el siguiente código está disponible en nuestro repositorio de muestras.
"permissions": [ "webRequestBlocking", "https://developer.chrome.com/docs/extensions/*", "https://developer.chrome.com/docs/extensions/reference" ]
"permissions": [ "declarativeNetRequestWithHostAccess" ], "host_permissions": [ "https://developer.chrome.com/*" ]
Cómo bloquear cookies
En el manifiesto V2, bloquear las cookies requiere interceptar los encabezados de solicitud web antes de que se envíen y quitar uno específico.
chrome.webRequest.onBeforeSendHeaders.addListener( function(details) { removeHeader(details.requestHeaders, 'cookie'); return {requestHeaders: details.requestHeaders}; }, // filters {urls: ['https://*/*', 'http://*/*']}, // extraInfoSpec ['blocking', 'requestHeaders', 'extraHeaders']);
Manifest V3 también lo hace con una regla en un archivo de reglas. Esta vez, el tipo de acción es "modifyHeaders"
. El archivo toma un array de objetos "requestHeaders"
que especifican los encabezados que se deben modificar y cómo hacerlo. Ten en cuenta que el objeto "condition"
solo contiene un array "resourceTypes"
. Admite los mismos valores que los ejemplos anteriores.
Si quieres probar esto, el siguiente código está disponible en nuestro repositorio de muestras.
[ { "id": 1, "priority": 1, "action": { "type": "modifyHeaders", "requestHeaders": [ { "header": "cookie", "operation": "remove" } ] }, "condition": { "urlFilter": "|*?no-cookies=1", "resourceTypes": ["main_frame"] } } ]
Esta situación también requiere cambios en los permisos de la extensión. Al igual que antes, reemplaza el permiso "webRequestBlocking"
por el permiso "declarativeNetRequest"
.
"permissions": [ "webRequest", "webRequestBlocking", "https://*/*", "http://*/*" ],
"permissions": [ "declarativeNetRequest", ], "host_permissions": [ "" ]