Il codice ospitato in remoto, o RHC, è il nome che il Chrome Web Store dà a qualsiasi elemento eseguito dal browser 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 Manifest V3, le estensioni 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 ha RHC. Che cosa succede?
Se la tua estensione è stata rifiutata durante la revisione con un errore Blue Argon, significa che i nostri revisori ritengono che la tua estensione utilizzi codice ospitato in remoto. Di solito, questo è il risultato di un'estensione che tenta di aggiungere un tag script con una risorsa remota (ovvero dal web aperto, anziché dai file inclusi nell'estensione) o di recuperare una risorsa da eseguire direttamente.
Come individuare l'RHC
Individuare le RHC non è particolarmente difficile una volta che sai cosa cercare. Innanzitutto, controlla la presenza delle stringhe "http://" o "https://" nel progetto. Se hai una violazione delle norme relative ai contenuti di alto valore, probabilmente potrai 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, in quanto è quella valutata dallo store. Se ancora non riesci a trovare il problema, il passaggio successivo è contattare l'assistenza centralizzata. Potranno delineare le violazioni specifiche e cosa è necessario per pubblicare l'estensione il prima possibile.
Cosa fare se una biblioteca richiede il codice
Indipendentemente dalla provenienza del codice, non è consentito avere RHC. Ciò include il codice che non hai creato, ma che utilizzi come dipendenza nel tuo progetto. Alcuni sviluppatori che utilizzano Firebase hanno riscontrato questo problema quando il codice remoto veniva incluso per l'utilizzo in Firebase Auth. Anche se si trattava di una libreria proprietaria (ovvero di proprietà di Google), non viene concessa alcuna eccezione per RHC. Devi configurare il codice per rimuovere l'RHC o aggiornare il progetto in modo che non includa il codice fin dall'inizio. Se riscontri un problema in cui non è il tuo codice a caricare RHC, ma una libreria che stai utilizzando, la cosa migliore da fare è contattare l'autore della libreria. Comunica che questo sta accadendo e chiedi una soluzione alternativa o aggiornamenti del codice per rimuoverlo.
Cosa succede se non puoi aspettare l'aggiornamento di una libreria
Alcune librerie invieranno un aggiornamento quasi immediatamente dopo la notifica, ma altre potrebbero essere abbandonate o richiedere tempo per risolvere il problema. A seconda di cosa sta succedendo nella violazione specifica, potrebbe non essere necessario attendere che venga spostato per essere sbloccato e completare una revisione riuscita. Sono disponibili diverse opzioni per tornare rapidamente all'operatività.
Controlla il codice
Sei sicuro che il codice che causa la richiesta sia necessario? Se può essere semplicemente eliminato o se è possibile rimuovere una libreria che lo causa, elimina il codice e il problema è risolto.
In alternativa, esiste un'altra libreria che offre le stesse funzionalità? Prova a consultare npmjs.com, GitHub o altri siti per trovare altre opzioni che soddisfino gli stessi casi d'uso.
Tree shaking
Se il codice che causa la violazione delle norme RHC non viene effettivamente utilizzato, potrebbe essere eliminato automaticamente dagli strumenti. Gli strumenti di compilazione moderni come webpack, Rollup e Vite (solo per citarne alcuni) hanno una funzionalità chiamata tree-shaking. Una volta attivato nel sistema di compilazione, il tree shaking dovrebbe rimuovere tutti i percorsi di codice inutilizzati. Ciò può significare che non solo avrai una versione del codice più conforme, ma anche più snella e veloce. È importante notare che non tutte le librerie possono essere sottoposte a tree shaking, ma molte sì. Alcuni strumenti, come Rollup e Vite, hanno l'eliminazione del codice inutilizzato abilitata per impostazione predefinita. webpack deve essere configurato per essere abilitato. Se non utilizzi un sistema di build come parte della tua estensione, ma utilizzi librerie di codice, ti consigliamo vivamente di valutare l'aggiunta di uno strumento di build al tuo flusso di lavoro. Gli strumenti di build ti aiutano a scrivere progetti più sicuri, affidabili e gestibili.
I dettagli su come implementare l'eliminazione del codice inutilizzato dipendono dal tuo progetto specifico. Per fare un esempio semplice con Rollup, puoi aggiungere l'eliminazione del codice inutilizzato semplicemente compilando il codice del progetto. Ad esempio, se hai un file che esegue l'accesso solo a Firebase Auth, denominato main.js:
import { GoogleAuthProvider, initializeAuth } from "firebase/auth"; browser.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); } });
A questo punto, devi solo indicare 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
Se esegui questo 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.
Il rollup può essere semplice, ma è anche molto configurabile. Puoi aggiungere tutti i tipi di logica e configurazione complesse. Consulta la documentazione. L'aggiunta di strumenti di compilazione come questo comporterà un codice più piccolo ed efficiente e, in questo caso, risolve il problema del codice ospitato in remoto.
Modifica automatica dei file
Un modo sempre più comune in cui il codice ospitato in remoto può entrare nel tuo codebase è
come dipendenza secondaria di una libreria che stai includendo. Se la libreria X vuole
import la libreria Y da una CDN, dovrai comunque aggiornarla per farla caricare da una sorgente locale. Con i moderni sistemi di build, puoi creare facilmente plug-in per estrarre un riferimento remoto e incorporarlo direttamente nel codice.
Ciò significa che, dato un codice simile al seguente:
import moment from "https://unpkg.com/moment@2.29.4/moment.js" console.log(moment())
Potresti creare un piccolo plug-in di rollup.
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 del nostro codice, di una sottodipendenza,
di una sottosottodipendenza o di qualsiasi altro elemento.
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. Apri il file nell'editor di testo che preferisci ed elimina le righe che violano le norme. In genere non è consigliabile, perché è fragile e potrebbe essere dimenticata. Rende più difficile la manutenzione del progetto quando un file chiamato "library.min.js" non è effettivamente library.min.js. Anziché modificare i file non elaborati, un'opzione leggermente più gestibile è utilizzare uno strumento come patch-package. Si tratta di un'opzione molto potente che ti consente di salvare le modifiche apportate a un file anziché il file stesso. Si basa sui file patch, lo stesso tipo di file che alimenta i sistemi di controllo della versione come Git o Subversion. Devi solo modificare manualmente il codice che viola le norme, salvare il file diff e configurare patch-package con le modifiche che vuoi applicare. Puoi leggere un tutorial completo nel file Readme del progetto. Se stai applicando una patch a un progetto, ti consigliamo vivamente di contattare il progetto per richiedere che le modifiche vengano apportate a monte. Sebbene patch-package semplifichi notevolmente la gestione delle patch, non dover applicare patch è ancora meglio.
Cosa fare se il codice non viene utilizzato
Man mano che le codebase crescono, le dipendenze (o la dipendenza di una dipendenza o la dipendenza di…) possono mantenere i percorsi del codice che non vengono più utilizzati. Se una di queste sezioni include codice per caricare o eseguire RHC, dovrà essere rimosso. Non importa se è scarica o inutilizzata. Se non viene utilizzata, deve essere rimossa, tramite treeshaking o applicando una patch alla libreria per rimuoverla.
Esiste una soluzione alternativa?
In generale, no. RHC non è consentito. Esiste, tuttavia, un numero ridotto di casi in cui è consentito. Quasi sempre si tratta di casi in cui è impossibile per qualsiasi altra opzione.
API User Scripts
Gli script utente sono piccoli snippet di codice forniti in genere dall'utente e destinati a gestori di script utente come TamperMonkey e Violentmonkey. Questi gestori non possono raggruppare il codice scritto dagli utenti, quindi l'API User Script espone un modo per eseguire il codice fornito dall'utente. Non è un sostituto di browser.scripting.executeScript o di altri ambienti di esecuzione del codice. Gli utenti devono attivare la modalità sviluppatore per eseguire qualsiasi operazione. Se il team di revisione del Chrome Web Store ritiene che venga utilizzato in modo diverso da quello previsto (ad es. codice fornito dall'utente), potrebbe essere rifiutato o la scheda rimossa dallo Store.
browser.debugger
L'API browser.debugger consente alle estensioni di interagire con
il protocollo Chrome DevTools. Si tratta dello stesso protocollo utilizzato per
DevTools di Chrome e per un numero incredibile di altri strumenti. Con questo, un'estensione può richiedere ed eseguire codice remoto. Come gli user script, non è
un sostituto di browser.scripting e offre un'esperienza utente molto più evidente.
Durante l'utilizzo, 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 es. uno script dei contenuti, anziché un service worker dell'estensione), un'altra opzione è utilizzare un iframe con sandbox. Per impostazione predefinita, le estensioni non supportano elementi come
eval() come misura di sicurezza. Il codice dannoso potrebbe mettere a rischio la sicurezza
e la protezione degli utenti. Tuttavia, quando il codice viene eseguito solo in un ambiente sicuro noto, come un iframe sottoposto a sandbox dal resto del web, questi rischi vengono notevolmente ridotti. In questo contesto, i criteri di sicurezza dei contenuti che bloccano l'utilizzo di eval possono essere rimossi, consentendoti di eseguire qualsiasi codice JavaScript valido.
Se hai un caso d'uso non coperto, non esitare a contattare il team utilizzando la mailing list chromium-extensions per ricevere feedback o aprire un nuovo ticket per richiedere indicazioni da One Stop Support.
Cosa fare se non sei d'accordo con un verdetto
L'applicazione delle norme può essere complessa e la revisione comporta l'inserimento manuale, il che significa che il team del Chrome Web Store a volte può accettare di modificare una decisione di revisione. Se ritieni che sia stato commesso un errore nella revisione, puoi presentare ricorso contro il rifiuto utilizzando l'assistenza centralizzata.