Gérer les cas de non-respect du code hébergé à distance

Le code hébergé à distance, ou RHC, est le terme utilisé par le Chrome Web Store pour désigner tout ce qui est exécuté par le navigateur et chargé à partir d'un emplacement autre que les propres fichiers de l'extension. Par exemple, JavaScript et WASM. Il n'inclut pas les données ni les éléments tels que JSON ou CSS.

Pourquoi le RHC n'est-il plus autorisé ?

Avec Manifest V3, les extensions doivent désormais regrouper tout le code qu'elles utilisent dans l'extension elle-même. Auparavant, vous pouviez injecter dynamiquement des balises de script à partir de n'importe quelle URL sur le Web.

On m'a dit que mon extension contenait du RHC. Que se passe-t-il ?

Si votre extension a été refusée lors de l'examen avec une erreur Blue Argon, cela signifie que nos examinateurs pensent qu'elle utilise du code hébergé à distance. Cela se produit généralement lorsqu'une extension tente d'ajouter un tag de script avec une ressource à distance (c'est-à-dire à partir du Web ouvert plutôt que des fichiers inclus dans l' extension) ou lorsqu'elle récupère une ressource à exécuter directement.

Comment repérer le RHC

Il n'est pas particulièrement difficile de repérer le RHC une fois que vous savez ce que vous devez rechercher. Commencez par rechercher les chaînes "http://" ou "https://" dans votre projet. Si vous avez une infraction liée au RHC, vous devriez pouvoir les localiser en trouvant cela. Si vous disposez d'un système de compilation complet ou si vous utilisez des dépendances provenant de npm ou d'autres sources tierces, assurez-vous de rechercher la version compilée du code, car c'est ce qui est évalué par le Store. Si vous ne parvenez toujours pas à trouver le problème, contactez l'assistance centralisée. Elle pourra vous indiquer les infractions spécifiques et ce qui est nécessaire pour publier l'extension dès que possible.

Que faire si une bibliothèque demande le code ?

Quelle que soit la provenance du code, le RHC n'est pas autorisé. Cela inclut le code que vous n'avez pas créé, mais que vous utilisez simplement comme dépendance dans votre projet. Certains développeurs utilisant Firebase ont rencontré ce problème lorsque du code à distance était inclus pour être utilisé dans Firebase Auth. Même s'il s'agissait d'une bibliothèque propriétaire (c'est-à-dire appartenant à Google), aucune exception n'est accordée pour le RHC. Vous devez configurer le code pour supprimer le RHC ou mettre à jour votre projet afin qu'il n'inclue pas le code au départ. Si vous rencontrez un problème où ce n'est pas votre code qui charge le RHC, mais une bibliothèque que vous utilisez, la meilleure chose à faire est de contacter l'auteur de la bibliothèque. Informez-le de ce qui se passe et demandez-lui une solution de contournement ou des mises à jour du code pour le supprimer.

Que faire si vous ne pouvez pas attendre une mise à jour de la bibliothèque ?

Certaines bibliothèques publient une mise à jour presque immédiatement après avoir été averties, mais d'autres peuvent être abandonnées ou prendre du temps pour résoudre le problème. Selon ce qui se passe dans l'infraction spécifique, vous n'aurez peut-être pas besoin d'attendre qu'elle soit résolue pour être débloqué et que l'examen soit réussi. Plusieurs options sont disponibles pour vous permettre de reprendre rapidement vos activités.

Auditer le code

Êtes-vous certain que le code à l'origine de la requête est nécessaire ? Si vous pouvez simplement le supprimer ou supprimer la bibliothèque à l'origine de la requête, faites-le.

Sinon, existe-t-il une autre bibliothèque offrant les mêmes fonctionnalités ? Essayez de consulter npmjs.com, GitHub ou d'autres sites pour trouver d'autres options qui répondent aux mêmes cas d'utilisation.

Tree shaking

Si le code à l'origine de l'infraction liée au RHC n'est pas réellement utilisé, il peut être supprimé automatiquement par un outil. Les outils de compilation modernes tels que webpack, Rollup et Vite (pour n'en citer que quelques-uns) disposent d'une fonctionnalité appelée tree-shaking. Une fois activée sur votre système de compilation, cette fonctionnalité devrait supprimer tous les chemins de code inutilisés. Cela signifie que vous disposez non seulement d'une version plus conforme de votre code, mais aussi d'une version plus légère et plus rapide. Il est important de noter que toutes les bibliothèques ne peuvent pas être "tree shaken", mais beaucoup le peuvent. Certains outils, tels que Rollup et Vite, ont cette fonctionnalité activée par défaut. webpack doit être configuré pour qu'elle soit activée. Si vous n'utilisez pas de système de compilation dans votre extension, mais que vous utilisez des bibliothèques de code, nous vous encourageons vivement à envisager d'ajouter un outil de compilation à votre workflow. Les outils de compilation vous aident à écrire des projets plus sûrs, plus fiables et plus faciles à gérer.

Les détails de l'implémentation du "tree shaking" dépendent de votre projet spécifique. Toutefois, pour prendre un exemple simple avec Rollup, vous pouvez ajouter cette fonctionnalité en compilant simplement le code de votre projet. Par exemple, si vous avez un fichier qui ne se connecte qu'à Firebase Auth, appelé 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);
  }
});

Il vous suffit ensuite d'indiquer à Rollup le fichier d'entrée, un plug-in nécessaire pour charger les fichiers de nœud @rollup/plugin-node-resolve et le nom du fichier de sortie qu'il génère.

npx rollup --input main.js --plugin '@rollup/plugin-node-resolve' --file compiled.js

En exécutant cette commande dans une fenêtre de terminal, vous recevrez une version générée de notre fichier main.js, le tout compilé dans un seul fichier nommé compiled.js.

Rollup peut être simple, mais il est aussi très configurable. Vous pouvez ajouter toutes sortes de logiques et de configurations complexes. Consultez simplement leur documentation. L'ajout d'un outil de compilation comme celui-ci générera un code plus petit et plus efficace, et dans ce cas, résoudra notre problème de code hébergé à distance.

Modifier automatiquement les fichiers

Le code hébergé à distance peut de plus en plus souvent entrer dans votre codebase en tant que sous-dépendance d'une bibliothèque que vous incluez. Si la bibliothèque X souhaite import la bibliothèque Y à partir d'un CDN, vous devrez toujours la mettre à jour pour qu'elle se charge à partir d'une source locale. Avec les systèmes de compilation modernes, vous pouvez facilement créer des plug-ins pour extraire une référence à distance et l'intégrer directement dans votre code.

Cela signifie que, pour un code qui ressemble à ceci :

import moment from "https://unpkg.com/moment@2.29.4/moment.js"
console.log(moment())

Vous pouvez créer un petit plug-in 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
    }
  }]
};

Une fois la compilation exécutée avec le nouveau plug-in, chaque URL import à distance est détectée, qu'il s'agisse de notre code, d'une sous-dépendance, d'une sous-sous-dépendance ou de tout autre élément.

npx rollup --input main.js --config ./rollup.config.mjs --file compiled.js

Modifier manuellement les fichiers

L'option la plus simple consiste à supprimer le code à l'origine du RHC. Ouvrez-le dans l'éditeur de texte de votre choix et supprimez les lignes qui ne respectent pas les règles. Cette pratique n'est généralement pas recommandée, car elle est fragile et peut être oubliée. Elle rend la maintenance de votre projet plus difficile lorsqu'un fichier appelé "library.min.js" n'est pas réellement library.min.js. Au lieu de modifier les fichiers bruts, une option légèrement plus facile à gérer consiste à utiliser un outil tel que patch-package. Il s'agit d'une option très puissante qui vous permet d'enregistrer des modifications dans un fichier, plutôt que le fichier lui-même. Il est basé sur des fichiers de patch, le même type d'élément qui alimente les systèmes de contrôle des versions tels que Git ou Subversion. Il vous suffit de modifier manuellement le code qui ne respecte pas les règles, d'enregistrer le fichier de différences et de configurer patch-package avec les modifications que vous souhaitez appliquer. Vous trouverez un tutoriel complet dans le fichier README du projet. Si vous corrigez un projet, nous vous encourageons vivement à contacter le projet pour demander que les modifications soient apportées en amont. Bien que patch-package facilite grandement la gestion des correctifs, il est encore mieux de n'avoir rien à corriger.

Que faire si le code n'est pas utilisé ?

À mesure que les codebases se développent, les dépendances (ou la dépendance d'une dépendance, ou la dépendance de…) peuvent conserver des chemins de code qui ne sont plus utilisés. Si l'une de ces sections inclut du code permettant de charger ou d'exécuter du RHC, elle devra être supprimée. Peu importe qu'il soit mort ou inutilisé. S'il n'est pas utilisé, il doit être supprimé, soit par "tree shaking", soit en corrigeant la bibliothèque pour le supprimer.

Existe-t-il une solution de contournement ?

En règle générale, non. Le RHC n'est pas autorisé. Il existe toutefois un petit nombre de cas où il est autorisé. Il s'agit presque toujours de cas où aucune autre option n'est possible.

API User Scripts

Les scripts utilisateur sont de petits extraits de code généralement fournis par l' utilisateur et destinés aux gestionnaires de scripts utilisateur tels que TamperMonkey et Violentmonkey. Il n'est pas possible pour ces gestionnaires de regrouper le code écrit par les utilisateurs. L'API User Scripts expose donc un moyen d'exécuter le code fourni par l'utilisateur. Il ne s'agit pas d'un substitut à chrome.scripting.executeScript ni à d'autres environnements d'exécution de code. Les utilisateurs doivent activer le mode développeur pour exécuter quoi que ce soit. Si l'équipe d'examen du Chrome Web Store pense que cette fonctionnalité est utilisée d'une manière autre que celle prévue (c'est-à-dire du code fourni par l'utilisateur), elle peut être refusée ou sa fiche peut être supprimée du Store.

chrome.debugger

L'API chrome.debugger permet aux extensions d'interagir avec le protocole Chrome Devtools. Il s'agit du même protocole que celui utilisé pour les outils de développement Chrome et d'un nombre incroyable d'autres outils. Grâce à lui, une extension peut demander et exécuter du code à distance. Tout comme les scripts utilisateur, il ne remplace pas chrome.scripting et offre une expérience utilisateur beaucoup plus notable. Lorsqu'il est utilisé, l'utilisateur voit une barre d'avertissement en haut de la fenêtre. Si la bannière est fermée ou ignorée, la session de débogage est arrêtée.

iFrames en bac à sable

Si vous devez évaluer une chaîne en tant que code et que vous vous trouvez dans un environnement DOM (par exemple, un script de contenu, par opposition à un service worker d'extension), vous pouvez également utiliser un iFrame en bac à sable. Par mesure de sécurité, les extensions ne sont pas compatibles avec des éléments tels que eval() par défaut. Un code malveillant pourrait mettre en danger la sécurité des utilisateurs. Toutefois, lorsque le code n'est exécuté que dans un environnement sûr connu, comme un iFrame qui a été mis en bac à sable à partir du reste du Web, ces risques sont considérablement réduits. Dans ce contexte, la Content Security Policy qui bloque l'utilisation d'eval peut être levée, ce qui vous permet d'exécuter n'importe quel code JavaScript valide.

Si vous avez un cas d'utilisation qui n'est pas couvert, n'hésitez pas à contacter l'équipe à l'aide de la liste de diffusion chromium-extensions pour obtenir des commentaires ou à ouvrir un nouveau ticket pour demander de l'aide à l'assistance centralisée

Que faire si vous n'êtes pas d'accord avec un verdict ?

L'application des règles peut être nuancée et l'examen implique une intervention manuelle, ce qui signifie que l'équipe du Chrome Web Store peut parfois accepter de modifier une décision d'examen. Si vous pensez qu'une erreur a été commise lors de l'examen, vous pouvez faire appel du refus en contactant l'assistance centralisée