javascript - gratis - Cómo manejar adecuadamente las actualizaciones de extensiones de Chrome desde las secuencias de comandos de contenido
habilitar javascript en chrome en windows (2)
En la página de fondo, podemos detectar actualizaciones de extensiones usando chrome.runtime.onInstalled.addListener
.
Pero después de que se haya actualizado la extensión, todas las secuencias de comandos de contenido no se pueden conectar a la página de fondo. Y obtenemos un error: Error connecting to extension ....
Es posible volver a inyectar secuencias de comandos de contenido utilizando chrome.tabs.executeScript
... Pero, ¿qué chrome.tabs.executeScript
si tenemos datos confidenciales que deben guardarse antes de una actualización y utilizarse después de la actualización? ¿Qué podíamos hacer?
Además, si reinyectamos todas las secuencias de comandos de contenido, deberíamos eliminar apropiadamente las secuencias de comandos de contenido anteriores.
¿Cuál es la forma correcta de manejar actualizaciones de extensión desde scripts de contenido sin perder los datos del usuario?
Si ha establecido una comunicación a través de var port = chrome.runtime.connect(...)
(como se describe en https://developer.chrome.com/extensions/messaging#connect ), debería ser posible escuchar el evento runtime.Port.onDisconnect
:
tport.onDisconnect.addListener(function(msg) {...})
Allí puede reaccionar y, por ejemplo, aplicar algún tipo de memorización, digamos a través de localStorage
. Pero, en general, sugeriría mantener los scripts de contenido lo más pequeños posible y realizar todas las manipulaciones de datos en segundo plano, permitiendo que el contenido solo recopile / transfiera datos y represente algún estado, si es necesario.
Una vez que se produce la actualización de la extensión de Chrome, el script de contenido "huérfano" se corta completamente de la extensión. La única forma en que todavía se puede comunicar es a través del DOM compartido. Si está hablando de datos realmente confidenciales, esto no es seguro desde la página. Más sobre eso más tarde.
En primer lugar, puede retrasar una actualización. En su script de fondo, agregue un controlador para el evento chrome.runtime.onUpdateAvailable
. Mientras el oyente esté allí, tienes la oportunidad de hacer la limpieza.
// Background script
chrome.runtime.onUpdateAvailable.addListener(function(details) {
// Do your work, call the callback when done
syncRemainingData(function() {
chrome.runtime.reload();
});
});
En segundo lugar, suponga que sucede lo peor y que se corte. Todavía puedes comunicarte usando eventos DOM:
// Content script
// Get ready for data
window.addEventListener("SendRemainingData", function(evt) {
processData(evt.detail);
}, false);
// Request data
var event = new CustomEvent("RequestRemainingData");
window.dispatchEvent(event);
// Be ready to send data if asked later
window.addEventListener("RequestRemainingData", function(evt) {
var event = new CustomEvent("SendRemainingData", {detail: data});
window.dispatchEvent(event);
}, false);
Sin embargo, este canal de comunicación puede ser interceptado por la página de host. Y, como dije anteriormente, ese espionaje no es algo que pueda eludir.
Sin embargo, puede tener algunos datos precompartidos fuera de banda. Supongamos que chrome.storage
una clave aleatoria en la primera instalación y la mantienes en chrome.storage
; esto no es accesible por las páginas web de ninguna manera. Por supuesto, una vez huérfano no puedes leerlo, pero puedes hacerlo en el momento de la inyección.
var PSK;
chrome.storage.local.get("preSharedKey", function(data) {
PSK = data.preSharedKey;
// ...
window.addEventListener("SendRemainingData", function(evt) {
processData(decrypt(evt.detail, PSK));
}, false);
// ...
window.addEventListener("RequestRemainingData", function(evt) {
var event = new CustomEvent("SendRemainingData", {detail: encrypt(data, PSK)});
window.dispatchEvent(event);
}, false);
});
Por supuesto, este es un código de prueba de concepto. Dudo que necesites más que un oyente de onUpdateAvailable
.