L’art d’utiliser les requêtes HTTP dans le script d’arrière-plan de votre extension Chrome

Ne se déclenche que lorsqu’il est prêt (Manifest v3)

Dans mon dernier article de blogje vous ai montré comment créer une extension Chrome et comment rendre un script d’arrière-plan conforme à la version 3 du manifeste. Dans cet article, nous continuerons avec les scripts d’arrière-plan. Je vais vous montrer comment déclencher un script d’arrière-plan uniquement lorsqu’une certaine demande est faite.

Cette logique pourrait avoir quelques cas d’utilisation. Par exemple, supposons que vous souhaitiez qu’une logique s’exécute automatiquement (sans cliquer sur l’extension). Imaginez maintenant être capable d’exécuter cette logique uniquement quand tu en as besoin, au lieu de régler une minuterie ou un mécanisme d’interrogation superflu.

C’est un principe que j’incorpore dans l’une de mes extensions où je ne veux déclencher la logique que pour un message Medium chaque fois que le Saving/Saved... demande est faite. De cette façon, je n’ai besoin de relancer ma logique que lorsque mon brouillon a été modifié et sauvé, plutôt que d’avoir à le configurer pour qu’il s’exécute périodiquement au cas où les choses auraient changé.

Cette approche est beaucoup plus volontaire et efficace.

Si vous avez déjà écrit pour Medium, vous avez sans aucun doute vu la notification ci-dessus. C’est la notification qui vous indique que ce sur quoi vous travaillez a été enregistré — sinon, vous obtenez une notification d’erreur rouge indiquant qu’il n’a pas pu être enregistré.

N’oubliez pas que vous ne voulez pas que votre extension fonctionne plus que nécessaire. Avec la logique que je propose, vous n’exécuterez votre script que lorsque votre histoire sera enregistrée (c’est-à-dire sur une demande spécifique).

Si vous ne l’avez pas déjà fait, ouvrez le extension-boilerplate projet que je t’ai fait faire pendant Dernier commentaire. Nous allons construire à partir de l’extension que nous avons faite la dernière fois (bien que pour plus de clarté, je vais enregistrer le code source dans un dépôt séparé sur GitHub).

Notre premier changement aura lieu en manifest.json. Dans vos autorisations, vous devrez ajouter une nouvelle propriété appelée webRequest.

"permissions": [
"scripting",
"activeTab",
"webRequest" // This one
],

Cette propriété donnera à notre extension l’autorisation d’afficher les requêtes Web dans la fenêtre de notre client. Nous devrons également ajouter une autre propriété à notre manifest.json appelé host_permissions. Cette propriété pointe vers un tableau de chaînes qui représentent des URL spécifiées.

Ces URL sont les sites autorisés auxquels notre extension a accès. S’il n’est pas spécifié, il a aucune autorisation et le webRequest L’API ne peut pas être utilisée. Si vous voulez qu’il ait l’autorisation de quelconque site Web, vous pouvez écrire "<all_urls>".

Si vous ne précisez pas "host_permissions" dans votre manifeste, vous pourriez vous retrouver avec cette erreur dans votre service worker.

Après avoir ajouté cette propriété, votre manifest.json devrait ressembler à ce qui suit.

{
"name": "Request Specific Extension", 
"description": "Starter code for a chrome extension that is request specific.",
"version": "1.0.0",
"manifest_version": 3,
"permissions": [
"scripting",
"activeTab",
"webRequest"
],
"background": {
"service_worker": "background.js"
},
"host_permissions": [
"<all_urls>"
],
"action":{
"default_title": "Request Specific Extension",
"default_icon": "assets/icon.png"
}
}

Maintenant que nous avons trié le manifeste, nous devons mettre à jour notre background.js fichier pour vous assurer qu’il est à l’écoute de ce nouvel événement. Nous devrons mettre à jour notre écouteur avec la méthode et les arguments appropriés.

Tout d’abord, supprimez action.onClick.addListener(...) et le remplacer par webRequest.onBeforeRequest.addListener(...). Il y a autres méthodes que vous pouvez utiliser mais pour l’instant nous nous en tiendrons onBeforeRequest.

onBeforeRequest est un événement qui se déclenche juste avant qu’une demande soit faite. De cette façon, vous pouvez vous connecter à une demande pour l’annuler ou la rediriger. Ça prend deux requis arguments et un facultatif. Le premier argument est un callback fonction, un peu comme le onClick écouteur d’événements du post précédent. Le deuxième argument, cependant, est un objet.

Cet objet aura une propriété appelée urls qui pointera vers un tableau de chaînes. Ces chaînes représentent les URL sur lesquelles la fonction de rappel peut être exécutée.

chrome.webRequest.onBeforeRequest.addListener(
callback,          
{urls: ["<all_urls>"]}
)

L’exemple ci-dessus exécutera callback chaque fois qu’une demande est faite avec des URL. Les URL ici sont différentes des URL spécifiées dans le "host_permissions".

• Les "host_permissions" Les URL sont les URL des hébergeur de site web.
• Les URL spécifiées dans le filtre se rapportent à en-têtes dans les requêtes.

Avec le code ci-dessus, notre logique sera exécutée chaque fois que notre extension Chrome détectera quelconque demande. Cela seul va à l’encontre de ce que notre intention – faire de notre extension demande spécifique. Nous regardons Plus précisément pour le Saving/Saved demande de médium.

Précisons donc nos URL.

Nous devons savoir à quoi ressemble l’URL lorsque le Saving/Saved demande est faite. Pour ce faire, accédez à un brouillon d’un article Medium existant ou créez-en un nouveau. Une fois dans le post, ouvrez votre console, puis cliquez sur le Network languette.

Effectuez une modification rapide, puis vérifiez le Network languette. Si le message est enregistré, vous devriez pouvoir voir quelque chose comme ci-dessous.

Nous pouvons voir quelle demande correspond à la Saving/Saved demande en vérifiant quel nom apparaît lorsque le Saving/Saved demande est faite. Ensuite, nous pouvons regarder sous Headers > General > Request URL pour trouver notre URL spécifiée.

Le seul problème avec cela est que notre draftID (juste après p/ dans l’URL) et notre logLockId changera probablement en fonction du brouillon sur lequel nous travaillons, du moment où nous y travaillons, etc. Pour rendre notre filtre d’URL dynamique, nous pouvons ajouter un * au lieu de draftID et logLockId.

C’est un personnage qui attrapera n’importe quoi à cette position dans l’URL. Voir notre objet de filtre mis à jour ci-dessous.

{urls: ["https://medium.com/p/*/deltas?logLockId=*"]}

La dernière chose que nous devons mettre à jour est dans notre init fonction (il s’agit de la même fonction que post précédent). Où il est dit const {id, url} = tabvous devriez mettre const {tabId, url} = tab;.

Pourquoi ils n’ont pas choisi de garder les propriétés cohérentes à travers les événements, je ne suis pas sûr. Vous trouverez ci-dessous notre version complète et mise à jour background.js dossier.

init = (tab) => {
const {tabId, url} = tab; // tabId instead of id
chrome.scripting.executeScript(
{
target: {tabId, allFrames: true},
files: ['clientside.js']
}
)
console.log(`Loading: ${url}`); 
}
chrome.webRequest.onBeforeRequest.addListener(
init,          
{urls: ["https://medium.com/p/*/deltas?logLockId=*"]}
)

Une fois que tout cela est terminé, actualisez votre extension, ouvrez le travailleur de service, puis modifiez rapidement votre publication moyenne et observez ce qui se passe.

Alto! Votre extension chrome injecte maintenant clientside.js uniquement lorsque la requête HTTP pour Saving/Saved est appelé! Le script d’arrière-plan de votre extension chrome est maintenant Requête HTTP spécifique et efficace.