Cómo modificar las solicitudes de red en Manifest V3
Manifest V3 cambia la manera en que las extensiones manejan las modificaciones 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 acciones para realizar cuando se cumple un conjunto determinado de condiciones. Para ello, usa la API de Declarative Net Request.
Las APIs de solicitud web y las APIs de solicitud neta declarativa son muy diferentes. En lugar de reemplazar una llamada a función por otra, debes reescribir tu código según los casos de uso. En esta sección, se explica ese proceso.
En Manifest V2, el bloqueo de solicitudes web podría degradar significativamente el rendimiento de las extensiones y el de las páginas con las que funcionan. El espacio de nombres webRequest admite nueve eventos de bloqueo potencialmente, cada uno de los cuales toma una cantidad ilimitada de controladores de eventos. Para empeorar la situación, cada página web podría estar bloqueada por varias extensiones, y los permisos necesarios son invasivos. Manifest V3 te 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 service worker de extensión. En él, se describe la conversión de solicitudes web de bloqueo, utilizadas por Manifest V2, en solicitudes netas declarativas que utiliza Manifest V3. En las otras dos secciones, se explica cómo actualizar el código necesario 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. - Mueve los patrones de coincidencia 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 solicitudes netas declarativas
Para crear reglas de solicitudes netas 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 apunta a un archivo de regla. 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 netas declarativas. Las siguientes instrucciones proporcionan solo una descripción breve. Para obtener más información, consulta la referencia de la API en chrome.declarativeNetRequest.
Cómo bloquear una sola URL
Un caso de uso habitual en Manifest V2 era bloquear 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. Este ejemplo bloquea solo la página HTML principal, pero tú 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, debes actualizar los permisos de la extensión. En manifest.json, reemplaza el permiso "webRequestBlocking" por el permiso "declarativeNetRequest". Ten en cuenta que se quita la URL del campo "permissions" porque para bloquear contenido no se requieren permisos de host. Como se mostró anteriormente, el archivo de reglas especifica los hosts a los que se aplica una solicitud de red declarativa.
Si quieres probar esto, el código que aparece a continuación está disponible en nuestro repositorio de muestras.
"permissions": [
"webRequestBlocking",
"https://*.example.com/*"
]
"permissions": [
"declarativeNetRequest",
]
Cómo redireccionar varias URLs
Otro caso de uso común en Manifest V2 era usar el evento BeforeRequest para redireccionar las 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"]
);
En Manifest V3, usa el tipo de acción "redirect". Como 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 incluye la URL que se debe 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. Como 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 código que aparece a continuación 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/*"
]
Bloquear cookies
En Manifest V2, para bloquear cookies es necesario interceptar los encabezados de las solicitudes 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 hace esto 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 especifica los encabezados que se modificarán y cómo hacerlo. Observa que el objeto "condition" solo contiene un array "resourceTypes". Admite los mismos valores que los ejemplos anteriores.
Si quieres probar esto, el código que aparece a continuación 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. Como antes, reemplaza el permiso "webRequestBlocking" por el permiso "declarativeNetRequest".
"permissions": [
"webRequest",
"webRequestBlocking",
"https://*/*",
"http://*/*"
],
"permissions": [
"declarativeNetRequest",
],
"host_permissions": [
""
]