Op afstand gehoste code, of RHC, is wat de Chrome Web Store alles noemt dat wordt uitgevoerd door de browser en wordt geladen vanaf een andere plek dan de eigen bestanden van de extensie. Dingen als JavaScript en WASM. Het bevat geen gegevens of zaken als JSON of CSS.
Waarom is RHC niet meer toegestaan?
Met Manifest V3 moeten extensies nu alle code die ze gebruiken in de extensie zelf bundelen. In het verleden kon u scripttags dynamisch injecteren vanuit elke URL op internet.
Er is mij verteld dat mijn toestel RHC heeft. Wat gebeurd er?
Als uw extensie tijdens de beoordeling is afgewezen vanwege een Blue Argon- fout, denken onze reviewers dat uw extensie gebruikmaakt van op afstand gehoste code. Dit is meestal het gevolg van het feit dat een extensie probeert een scripttag toe te voegen met een externe bron (dat wil zeggen van het open web, in plaats van de bestanden in de extensie), of een bron ophaalt om deze direct uit te voeren.
Hoe RHC te herkennen
Het spotten van RHC is niet bijzonder moeilijk als je eenmaal weet waar je op moet letten. Controleer eerst of de tekenreeksen "http://" of "https://" in uw project aanwezig zijn. Als u een RHC-schending heeft, kunt u deze waarschijnlijk lokaliseren door dat te constateren. Als je een volledig bouwsysteem hebt, of afhankelijkheden van npm of andere bronnen van derden gebruikt, zorg er dan voor dat je de gecompileerde versie van de code doorzoekt, aangezien dat is wat door de winkel wordt geëvalueerd. Als u het probleem nog steeds niet kunt vinden, is de volgende stap contact opnemen met One Stop Support . Zij kunnen de specifieke schendingen schetsen en wat er nodig is om de uitbreiding zo snel mogelijk gepubliceerd te krijgen.
Wat te doen als een bibliotheek de code opvraagt
Ongeacht waar de code vandaan komt, het is niet toegestaan om RHC te hebben. Dit omvat code die u niet zelf heeft geschreven, maar die u toevallig als afhankelijkheid in uw project gebruikt. Sommige ontwikkelaars die Firebase gebruikten, hadden dit probleem toen externe code werd opgenomen voor gebruik in Firebase Auth . Ook al was dit een eigen bibliotheek (dwz eigendom van Google), er wordt geen uitzondering gemaakt voor RHC. U moet de code configureren om de RHC te verwijderen of uw project bij te werken zodat de code om te beginnen niet wordt opgenomen. Als u een probleem tegenkomt waarbij het niet uw code is die RHC laadt, maar een bibliotheek die u gebruikt, kunt u het beste contact opnemen met de auteur van de bibliotheek. Laat hen weten dat dit gebeurt en vraag om een oplossing of om code-updates om dit te verwijderen.
Wat als je niet kunt wachten op een bibliotheekupdate?
Sommige bibliotheken zullen vrijwel onmiddellijk nadat ze op de hoogte zijn gesteld een update verzenden, maar andere kunnen worden stopgezet of het duurt enige tijd om het probleem op te lossen. Afhankelijk van wat er bij de specifieke overtreding gebeurt, hoeft u mogelijk niet te wachten totdat de blokkering is opgeheven en een succesvolle beoordeling is voltooid. Er zijn een aantal opties beschikbaar om snel weer aan de slag te gaan.
Controleer de code
Weet u zeker dat de code die het verzoek veroorzaakt, nodig is? Als het gewoon kan worden verwijderd, of als een bibliotheek die het veroorzaakt, kan worden verwijderd, verwijder dan die code en de klus is geklaard.
Is er alternatief een andere bibliotheek die dezelfde functies biedt? Probeer npmjs.com , GitHub of andere sites te controleren op andere opties die aan dezelfde gebruiksscenario's voldoen.
Boom schudden
Als de code die de RHC-schending veroorzaakt, niet daadwerkelijk wordt gebruikt, kan deze mogelijk automatisch worden verwijderd door middel van tools. Moderne buildtools zoals webpack , Rollup en Vite (om er maar een paar te noemen) hebben een functie die tree-shaking wordt genoemd. Eenmaal ingeschakeld op uw bouwsysteem, zou het schudden van bomen alle ongebruikte codepaden moeten verwijderen. Dit kan betekenen dat u niet alleen een meer compatibele versie van uw code heeft, maar ook een slankere en snellere versie! Het is belangrijk op te merken dat niet alle bibliotheken boomschudden kunnen, maar veel daarvan wel. Bij sommige tools, zoals Rollup en Vite, is het schudden van bomen standaard ingeschakeld. webpack moet worden geconfigureerd voordat het kan worden ingeschakeld. Als u geen bouwsysteem gebruikt als onderdeel van uw extensie, maar codebibliotheken gebruikt , wordt u echt aangemoedigd om te onderzoeken of u een bouwtool aan uw workflow kunt toevoegen. Met bouwtools kunt u veiligere, betrouwbaardere en beter onderhoudbare projecten schrijven.
De details van hoe u treeshaking kunt implementeren, zijn afhankelijk van uw specifieke project. Maar om een eenvoudig voorbeeld te nemen met Rollup: u kunt treeshaking toevoegen door simpelweg uw projectcode te compileren. Als u bijvoorbeeld een bestand heeft dat alleen inlogt bij Firebase Auth, genaamd 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);
}
});
Het enige wat u dan hoeft te doen is Rollup het invoerbestand vertellen, een plug-in die nodig is om knooppuntbestanden @rollup/plugin-node-resolve te laden en de naam van het uitvoerbestand dat het genereert.
npx rollup --input main.js --plugin '@rollup/plugin-node-resolve' --file compiled.js
Als u die opdracht in een terminalvenster uitvoert, ontvangt u een gegenereerde versie van ons bestand main.js , allemaal gecompileerd in één enkel bestand met de naam compiled.js .
Rollup kan eenvoudig zijn, maar het is ook zeer configureerbaar. Je kunt allerlei soorten complexe logica en configuratie toevoegen, bekijk gewoon hun documentatie . Het toevoegen van dergelijke build-tools zal resulteren in een kleinere, efficiëntere code, en in dit geval wordt het probleem met de op afstand gehoste code opgelost.
Automatisch bestanden bewerken
Een steeds vaker voorkomende manier waarop op afstand gehoste code uw codebase kan binnendringen, is als een subafhankelijkheid van een bibliotheek die u opneemt. Als bibliotheek X bibliotheek Y uit een CDN wil import , moet u deze nog steeds bijwerken om deze vanuit een lokale bron te laten laden. Met moderne bouwsystemen kunt u op een eenvoudige manier plug-ins maken om een referentie op afstand te extraheren en deze rechtstreeks in uw code in te voegen.
Dat zou betekenen dat de gegeven code er als volgt uitziet:
import moment from "https://unpkg.com/moment@2.29.4/moment.js" console.log(moment())
Je zou een kleine rollup-plug-in kunnen maken.
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
}
}]
};
Zodra u de build met de nieuwe plug-in uitvoert, wordt elke externe import URL ontdekt, ongeacht of het onze code is of niet, een subafhankelijkheid, subsubafhankelijkheid of ergens anders.
npx rollup --input main.js --config ./rollup.config.mjs --file compiled.js
Handmatig bestanden bewerken
De eenvoudigste optie is om gewoon de code te verwijderen die de RHC veroorzaakt. Open in uw gewenste teksteditor en verwijder de overtredende regels. Dit is over het algemeen niet zo aan te raden, omdat het broos is en vergeten kan worden. Het maakt het onderhouden van uw project moeilijker als een bestand met de naam "library.min.js" niet daadwerkelijk bibliotheek.min.js is. In plaats van de onbewerkte bestanden te bewerken, is een iets beter onderhoudbare optie het gebruik van een tool als patch-package . Dit is een superkrachtige optie waarmee je wijzigingen in een bestand kunt opslaan, in plaats van het bestand zelf. Het is gebouwd op patchbestanden , hetzelfde soort dingen dat versiebeheersystemen zoals Git of Subversion aanstuurt. U hoeft alleen maar de inbreukmakende code handmatig aan te passen, het diff-bestand op te slaan en het patchpakket te configureren met de wijzigingen die u wilt toepassen. U kunt een volledige tutorial lezen in de readme van het project . Als u een project aan het patchen bent, raden we u ten zeerste aan contact op te nemen met het project en te vragen of er upstream wijzigingen kunnen worden aangebracht. Hoewel het patchpakket het beheren van patches een stuk eenvoudiger maakt, is het nog beter om niets te hoeven patchen.
Wat te doen als de code niet wordt gebruikt
Naarmate codebases groeien, kunnen afhankelijkheden (of de afhankelijkheid van een afhankelijkheid, of de afhankelijkheid van...) codepaden behouden die niet langer worden gebruikt. Als een van deze secties code bevat om RHC te laden of uit te voeren, moet deze worden verwijderd. Het maakt niet uit of het dood of ongebruikt is. Als het niet wordt gebruikt, moet het worden verwijderd, hetzij door middel van 'treeshaking', hetzij door de bibliotheek te patchen om het te verwijderen.
Is er een oplossing?
Over het algemeen niet. RHC is niet toegestaan. Er zijn echter een klein aantal gevallen waarin dit wel is toegestaan. Dit zijn vrijwel altijd gevallen waarin geen andere optie mogelijk is.
API voor gebruikersscripts
Gebruikersscripts zijn kleine codefragmenten die meestal door de gebruiker worden aangeleverd, bedoeld voor gebruikersscriptbeheerders zoals TamperMonkey en Violentmonkey . Het is voor deze managers niet mogelijk om code te bundelen die door gebruikers is geschreven, dus biedt de User Script API een manier om door de gebruiker aangeleverde code uit te voeren. Dit is geen vervanging voor chrome.scripting.executeScript of andere omgevingen voor het uitvoeren van code. Gebruikers moeten de ontwikkelaarsmodus inschakelen om iets uit te voeren. Als het beoordelingsteam van de Chrome Web Store denkt dat dit op een andere manier wordt gebruikt dan waarvoor het is bedoeld (dat wil zeggen met code die door de gebruiker is verstrekt), kan het worden afgewezen of wordt de vermelding uit de winkel verwijderd.
chrome.debugger
De chrome.debugger API geeft extensies de mogelijkheid om te communiceren met het Chrome Devtools Protocol . Dit is hetzelfde protocol dat wordt gebruikt voor Chrome's Devtools en een verbazingwekkend aantal andere tools . Hiermee kan een extensie externe code opvragen en uitvoeren. Net als gebruikersscripts is het geen vervanging voor chrome.scripting en heeft het een veel opmerkelijkere gebruikerservaring. Terwijl het wordt gebruikt, ziet de gebruiker bovenaan het venster een waarschuwingsbalk. Als de banner wordt gesloten of verwijderd, wordt de foutopsporingssessie beëindigd.
iframes in de sandbox
Als u een tekenreeks als code moet evalueren en u zich in een DOM-omgeving bevindt (bijvoorbeeld een inhoudsscript, in tegenstelling tot een extensieservicewerker), dan is een andere optie het gebruik van een iframe in een sandbox . Extensies ondersteunen zaken als eval() standaard niet als veiligheidsmaatregel. Schadelijke code kan de veiligheid en beveiliging van gebruikers in gevaar brengen. Maar als de code alleen wordt uitgevoerd in een bekende veilige omgeving, zoals een iframe dat in een sandbox van de rest van het internet is geplaatst, worden die risico's aanzienlijk verminderd. Binnen deze context kan het Content Security Policy dat het gebruik van eval blokkeert, worden opgeheven, zodat u elke geldige JavaScript-code kunt uitvoeren.
Als u een gebruiksscenario heeft dat niet onder de dekking valt, neem dan gerust contact op met het team via de mailinglijst met chroomextensies om feedback te krijgen, of open een nieuw ticket om hulp te vragen aan One Stop Support
Wat moet u doen als u het niet eens bent met een uitspraak?
Het afdwingen van beleid kan genuanceerd zijn en bij beoordeling is handmatige invoer betrokken, wat betekent dat het team van de Chrome Web Store er soms mee instemt een beoordelingsbesluit te wijzigen. Als u van mening bent dat er bij de beoordeling een fout is gemaakt, kunt u via One Stop Support in beroep gaan tegen de afwijzing