Il codice ospitato in remoto, o RHC, è ciò che il Chrome Web Store chiama tutto ciò che viene eseguito dal browser e caricato da una posizione diversa dai file dell'estensione. come JavaScript e WASM. Non include dati o elementi come JSON o CSS.
Perché RHC non è più consentito?
Con le estensioni Manifest V3 ora devono raggruppare tutto il codice che utilizzano all'interno dell'estensione stessa. In passato, potevi inserire dinamicamente tag script da qualsiasi URL sul web.
Mi è stato detto che la mia estensione include RHC. Che cosa succede?
Se la tua estensione è stata rifiutata durante la revisione con un errore Blue Argon, i nostri revisori ritengono che l'estensione utilizzi codice ospitato in remoto. Questo di solito è il risultato del tentativo di un'estensione di aggiungere un tag di script con una risorsa remota (ad esempio dal web aperto, piuttosto che dei file inclusi nell'estensione) o del recupero di una risorsa per l'esecuzione diretta.
Come individuare l'RHC
Individuare l'RHC non è particolarmente difficile una volta che sai cosa cercare. Innanzitutto, controlla le stringhe "http://" o "https://" nel tuo progetto. Se rilevi una violazione delle norme RHC, potresti riuscire a individuarla. Se hai un sistema di compilazione completo o utilizzi dipendenze da npm o altre origini di terze parti, assicurati di cercare la versione compilata del codice, poiché è quella che viene valutata dallo store. Se non riesci ancora a trovare il problema, il passaggio successivo consiste nel contattare l'assistenza di One Stop. Saranno in grado di indicare le violazioni specifiche e ciò che è necessario per pubblicare l'estensione il prima possibile.
Cosa fare se una biblioteca richiede il codice
Indipendentemente dalla provenienza del codice, non è consentito utilizzare RHC. Include codice che non hai creato, ma che viene semplicemente utilizzato come dipendenza nel progetto. Alcuni sviluppatori che utilizzavano Firebase riscontravano questo problema quando il codice remoto veniva incluso per essere utilizzato in Firebase Auth. Anche se si trattava di una libreria proprietaria (ovvero di proprietà di Google), non vengono fatte eccezioni per RHC. Devi configurare il codice in modo da rimuovere l'RHC o aggiornare il progetto in modo da non includere il codice iniziale. Se riscontri un problema per cui non è il tuo codice a caricare RHC, ma una libreria che stai utilizzando, la soluzione migliore è contattare l'autore della libreria. Comunica che si tratta di un problema e richiedi una soluzione alternativa o l'aggiornamento del codice per rimuoverlo.
E se non vedessi l'ora di ricevere un aggiornamento della raccolta
Alcune librerie spediranno un aggiornamento quasi immediatamente dopo la loro notifica, mentre altre potrebbero essere abbandonate o impiegare il tempo per risolvere il problema. A seconda di cosa si sta accadendo nella violazione specifica, potrebbe non essere necessario attendere che vengano sbloccati e completare una revisione con esito positivo. Ci sono diverse opzioni disponibili per riprendere la configurazione in tempi rapidi.
Controlla il codice
Sei sicuro che il codice che causa la richiesta sia necessario? Se può essere solo eliminato o la libreria che la causa, può essere rimossa, quindi elimina il codice e il job è fatto.
Altrimenti, c'è un'altra raccolta che offre le stesse funzionalità? Prova a controllare npmjs.com, GitHub o altri siti per verificare se sono presenti altre opzioni che soddisfano gli stessi casi d'uso.
Tremore degli alberi
Se il codice che causa la violazione delle norme RHC non viene effettivamente utilizzato, potrebbe essere eliminato automaticamente dagli strumenti. I moderni strumenti di creazione come webpack, Rollup e Vite (solo per citarne alcuni) hanno una funzionalità chiamata tree-shaking. Una volta abilitata sul tuo sistema di build, lo scuotimento dell'albero dovrebbe rimuovere tutti i percorsi di codice inutilizzati. Ciò significa che non solo avrai una versione più conforme del tuo codice, ma anche una versione più snella e più veloce. È importante notare che non tutte le librerie possono subire interruzioni degli alberi, ma molte sì. Per alcuni strumenti, come Rollup e Vite, la vibrazione ad albero è abilitata per impostazione predefinita. Per abilitarla, il webpack deve essere configurato. Se l'estensione non include un sistema di compilazione, ma sei librerie di codice, ti consigliamo di valutare l'aggiunta di uno strumento di creazione al flusso di lavoro. Gli strumenti di creazione ti aiutano a scrivere progetti più sicuri, affidabili e gestibili.
Le specifiche su come implementare l'analisi degli alberi dipendono dal progetto specifico. Per fare un semplice esempio con Rollup, puoi aggiungere treehaking semplicemente compilando il codice del tuo progetto. Ad esempio, se hai un file che accede solo a Firebase Auth, chiamato main.js:
import { GoogleAuthProvider, initializeAuth } from "firebase/auth";
chrome.identity.getAuthToken({ 'interactive': true }, async (token) => {
const credential = GoogleAuthProvider.credential(null, token);
try {
const app = initializeApp({ ... });
const auth = initializeAuth(app, { popupRedirectResolver: undefined, persistence: indexDBLocalPersistence });
const { user } = await auth.signInWithCredential(credential)
console.log(user)
} catch (e) {
console.error(error);
}
});
Quindi ti basta dire a Rollup il file di input, un plug-in necessario per caricare i file dei nodi @rollup/plugin-node-resolve, e il nome del file di output che sta generando.
npx rollup --input main.js --plugin '@rollup/plugin-node-resolve' --file compiled.js
Eseguendo il comando in una finestra del terminale, riceverai una versione generata
del nostro file main.js, il tutto compilato in un unico file denominato compiled.js.
La proprietà di aggregazione può essere semplice, ma è anche molto configurabile. Puoi aggiungere tutti i tipi di logiche e configurazioni complesse, consultando la relativa documentazione. L'aggiunta di strumenti di creazione come questo darà luogo a un codice più piccolo ed efficiente e, in questo caso, corregge il problema relativo al codice ospitato remoto.
Modifica automatica dei file
Un modo sempre più comune in cui il codice ospitato in remoto può inserire il tuo codebase
è una dipendenza da una libreria che stai includendo. Se la libreria X vuoleimport la libreria Y da una CDN, dovrai comunque aggiornarla per caricarla da un'origine locale. Con i moderni sistemi di creazione, è possibile creare facilmente
plug-in per estrarre un riferimento remoto e incorporarlo direttamente nel codice.
Ciò significa che un determinato codice ha il seguente aspetto:
import moment from "https://unpkg.com/moment@2.29.4/moment.js" console.log(moment())
Potresti creare un piccolo plug-in di aggregazione.
import { existsSync } from 'fs';
import fetch from 'node-fetch';
export default {
plugins: [{
load: async function transform(id, options, outputOptions) {
// this code runs over all of out javascript, so we check every import
// to see if it resolves as a local file, if that fails, we grab it from
// the network using fetch, and return the contents of that file directly inline
if (!existsSync(id)) {
const response = await fetch(id);
const code = await response.text();
return code
}
return null
}
}]
};
Dopo aver eseguito la build con il nuovo plug-in, ogni URL import remoto viene rilevato indipendentemente dal fatto che si tratti o meno del nostro codice, di una subdipendenza, di una sottodipendenza o da qualsiasi altra parte.
npx rollup --input main.js --config ./rollup.config.mjs --file compiled.js
Modifica manuale dei file
L'opzione più semplice è eliminare il codice che causa l'RHC. Aprilo nell'editor di testo che preferisci ed elimina le righe che violano le norme. In genere questo non è consigliabile, perché è debole e potrebbe essere dimenticato. La gestione del progetto diventa più difficile quando un file chiamato "library.min.js" non è in realtà library.min.js. Invece di modificare i file non elaborati, un'opzione leggermente più gestibile è quella di utilizzare uno strumento come patch-package. Si tratta di un'opzione molto utile che consente di salvare le modifiche a un file, anziché al file stesso. Si basa su file di patch, lo stesso tipo di elemento alla base dei sistemi di controllo delle versioni come Git o Subversion. Devi solo modificare manualmente il codice in violazione, salvare il file diff e configurare il pacchetto di patch con le modifiche che vuoi applicare. Puoi leggere un tutorial completo sul leggime del progetto. Se stai applicando la patch a un progetto, ti invitiamo davvero a contattare il progetto per richiedere l'applicazione di modifiche a monte. Anche se il pacchetto di patch semplifica la gestione delle patch, non avere nulla da applicare a patch è ancora meglio.
Cosa fare se il codice non viene utilizzato
Con l'aumento dei codebase, le dipendenze (o una dipendenza di...) possono mantenere i percorsi di codice che non vengono più utilizzati. Se una di queste sezioni include codice per caricare o eseguire RHC, dovrà essere rimossa. Non importa se è scaduto o inutilizzato. Se non vengono utilizzati, devono essere rimossi tramite crepe degli alberi o patchando la libreria per rimuoverli.
Esiste una soluzione alternativa?
In linea di massima no. RHC non è consentito. Tuttavia, esiste un numero limitato di casi in cui è consentito. Quasi sempre, in questi casi è impossibile per qualsiasi altra opzione.
API User Scripts
Gli script utente sono piccoli snippet di codice solitamente forniti dall'utente e destinati a gestori degli script utente come TamperMonkey e Violentmonkey. Per questi gestori non è possibile raggruppare il codice scritto dagli utenti, quindi l'API User Script espone un modo per eseguire il codice fornito dall'utente. Non sostituisce chrome.scripting.executeScript o altri ambienti di esecuzione del codice. Gli utenti devono attivare la modalità sviluppatore per eseguire qualsiasi operazione. Se il team di revisori del Chrome Web Store ritiene che questo dispositivo sia utilizzato in un modo diverso da quello previsto (ovvero, tramite un codice fornito dall'utente), la scheda potrebbe essere rifiutata o essere rimossa dallo store.
chrome.debugger
L'API chrome.debugger consente alle estensioni di interagire con il protocollo Chrome DevTools. Si tratta dello stesso protocollo utilizzato per gli strumenti
di sviluppatori di Chrome e di un numero incredibile di altri strumenti. che consente a un'estensione
di richiedere ed eseguire codice remoto. Come gli script utente, non sostituisce chrome.scripting e offre un'esperienza utente molto più significativa.
Mentre è in uso, l'utente vedrà una barra di avviso nella parte superiore
della finestra. Se il banner viene chiuso o ignorato, la sessione di debug verrà terminata.
Iframe con sandbox
Se devi valutare una stringa come codice e ti trovi in un ambiente DOM (ad esempio uno script di contenuti anziché un service worker di estensione), un'altra opzione è utilizzare un iframe con sandbox. Le estensioni non supportano elementi come eval() per impostazione predefinita come misura di sicurezza. Il codice dannoso potrebbe mettere a rischio
la sicurezza degli utenti. Tuttavia, quando il codice viene eseguito solo in un ambiente sicuro noto, come un iframe che è stato limitato tramite sandbox dal resto del web, i rischi si riducono notevolmente. In questo contesto, il criterio di sicurezza del contenuto che blocca l'utilizzo di eval può essere rimosso, permettendoti di eseguire qualsiasi codice JavaScript valido.
Se il tuo caso d'uso non è contemplato, contatta il team utilizzando la mailing list chromium-extensions per ricevere feedback oppure apri una nuova richiesta di assistenza per richiedere indicazioni all'assistenza One Stop.
Cosa fare se non sei d'accordo con un esito
L'applicazione dei criteri può essere complessa e la revisione prevede l'inserimento manuale, il che significa che il team di Chrome Web Store a volte potrebbe accettare di modificare una decisione relativa alla revisione. Se ritieni che sia stato commesso un errore durante la revisione, puoi presentare ricorso contro il rifiuto utilizzando l'assistenza One Stop.