Cette page a été traduite par l'API Cloud Translation.

Tutoriel: Migrer vers Manifest V2

Manifest version 1 a été abandonné dans Chrome 18 et ne sera plus pris en charge manifest version 1 de la compatibilité avec la planification. Les changements entre la version 1 et la version 2 sont inférieurs à deux en catégories générales: modifications des API et modifications de la sécurité.

Ce document fournit des checklists pour faire migrer vos extensions Chrome de la version 1 du fichier manifeste vers version 2, suivie de résumés plus détaillés expliquant la signification de ces modifications et les raisons de ces modifications.

Checklist des modifications de l'API

Utilisez-vous la propriété browser_actions ou l'API chrome.browserActions ?
Remplacez browser_actions par la propriété browser_action unique.
Remplacez chrome.browserActions par chrome.browserAction.
Remplacez la propriété icons par default_icon.
Remplacez la propriété name par default_title.
Remplacez la propriété popup par default_popup (elle doit maintenant être une chaîne).
Utilisez-vous la propriété page_actions ou l'API chrome.pageActions ?
Remplacez page_actions par page_action.
Remplacez chrome.pageActions par chrome.pageAction.
Remplacez la propriété icons par default_icon.
Remplacez la propriété name par default_title.
Remplacez la propriété popup par default_popup (elle doit maintenant être une chaîne).
Utilisez-vous la propriété chrome.self ?
Remplacez-la par chrome.extension.
Utilisez-vous la propriété Port.tab ?
Remplacez-la par Port.sender.
Utilisez-vous chrome.extension.getTabContentses() ou chrome.extension.getExtensionTabs() ?
Remplacez-la par chrome.extension.getViews( { "type" : "tab" } ).
Votre extension utilise-t-elle une page en arrière-plan ?
Remplacez la propriété background_page par une propriété background.
Ajoutez une propriété scripts ou page contenant le code de la page.
Ajoutez une propriété persistent et définissez-la sur false pour convertir votre page d'arrière-plan en événement

Checklist des modifications de sécurité

Utilisez-vous des blocs de scripts intégrés dans les pages HTML ?
Supprimez le code JS contenu dans les balises <script> et placez-le dans un fichier JS externe.
Utilisez-vous des gestionnaires d'événements intégrés (par exemple, "onclick") ?
Supprimez-les du code HTML, déplacez-les dans un fichier JS externe et utilisez addEventListener(). à la place.
Votre extension injecte-t-il des scripts de contenu dans les pages Web qui doivent accéder à des ressources (comme images et scripts) contenus dans le package de l'extension ?
Définissez la propriété web_accessible_resources et répertoriez les ressources (et éventuellement une Content Security Policy spécifique pour ces ressources).
Votre extension intègre-t-elle des pages Web externes ?
Définissez la propriété sandbox.
Votre code ou votre bibliothèque utilisent-ils eval(), les nouvelles Function(), innerHTML, setTimeout() ou autrement transmettre des chaînes de code JS qui sont évaluées de manière dynamique ?
Utilisez JSON.parse() si vous analysez du code JSON dans un objet.
Utilisez une bibliothèque compatible avec CSP, telle que AngularJS.
Créez une entrée de bac à sable dans votre fichier manifeste et exécutez le code concerné dans le bac à sable à l'aide de la commande suivante : postMessage() pour communiquer avec la page en bac à sable.
Chargez-vous du code externe, comme jQuery ou Google Analytics ?
Téléchargez la bibliothèque et empaquetez-la dans votre extension, puis chargez-la à partir du package local.
Ajouter à la liste d'autorisation le domaine HTTPS qui diffuse la ressource dans la règle "content_security_policy" une partie de votre fichier manifeste.

Résumé des modifications apportées à l'API

La version 2 du fichier manifeste apporte quelques modifications aux API d'action du navigateur et d'action sur la page, et remplace quelques anciennes API par de nouvelles.

Modifications apportées aux actions du navigateur

L'API des actions du navigateur introduit quelques changements de nom:

Les propriétés browser_actions et chrome.browserActions ont été remplacées par leurs équivalents au singulier browser_action et chrome.browserAction.
Sous l'ancienne propriété browser_actions, il y avait icons, name et popup. Ils ont été remplacés par:
default_icon pour l'icône du badge d'action dans le navigateur
default_name pour le texte qui s'affiche dans l'info-bulle lorsque vous pointez sur le badge
default_popup pour la page HTML qui représente l'interface utilisateur pour l'action du navigateur (et qui doit maintenant être une chaîne, mais pas un objet)

Modifications apportées aux actions sur les pages

De la même manière que pour les actions du navigateur, l'API des actions sur la page a également été modifiée:

Les propriétés page_actions et chrome.pageActions ont été remplacées par leur singulier. équivalents page_action et chrome.pageAction.
Sous l'ancienne propriété page_actions, il y avait icons, name et popup. Ces ont été remplacés par:
default_icon pour l'icône du badge d'action sur la page
default_name pour le texte qui s'affiche dans l'info-bulle lorsque vous pointez sur le badge
default_popup pour la page HTML qui représente l'interface utilisateur pour l'action de page (et il doit maintenant s'agir de une chaîne, il ne peut pas s'agir d'un objet)

API supprimées et modifiées

Quelques API d'extension ont été supprimées et remplacées par de nouvelles:

La propriété background_page a été remplacée par background.
La propriété chrome.self a été supprimée. Utilisez chrome.extension.
La propriété Port.tab a été remplacée par Port.sender.
Les API chrome.extension.getTabContentses() et chrome.extension.getExtensionTabs() ont a été remplacé par chrome.extension.getViews( { "type" : "tab" } ).

Résumé des modifications apportées à la sécurité

Plusieurs modifications liées à la sécurité accompagnent le passage de la version 1 du fichier manifeste à version 2. La plupart de ces changements sont dus à l'adoption du Content Security Policy par Chrome. vous Veuillez vous renseigner sur ce règlement pour en comprendre les implications.

Les scripts intégrés et les gestionnaires d'événements ne sont pas autorisés

En raison de l'utilisation de Content Security Policy, vous ne pouvez plus utiliser les balises <script> intégrées. avec le contenu HTML. Ils doivent être déplacés vers des fichiers JS externes. De plus, les gestionnaires d'événements intégrés ne sont pas non plus prises en charge. Par exemple, supposons que votre extension contienne le code suivant:

<html>
<head>
  <script>
    function myFunc() { ... }
  </script>
</head>
</html>

Ce code générerait une erreur au moment de l'exécution. Pour résoudre ce problème, déplacez le contenu des balises <script> dans des fichiers externes et les référencer avec un attribut src='path_to_file.js'.

De même, les gestionnaires d'événements intégrés, une fonctionnalité pratique et d'occurrence courante utilisée par de nombreux les développeurs Web, ne s'exécuteront pas. Voici quelques exemples courants:

<body onload="initialize()">
<button onclick="handleClick()" id="button1">

Ces commandes ne fonctionnent pas dans les extensions Manifest V2. Supprimez les gestionnaires d'événements intégrés et placez-les dans votre JS externe et utiliser addEventListener() pour enregistrer les gestionnaires d'événements correspondants. Pour exemple, dans votre code JS, utilisez:

window.addEventListener("load", initialize);
...
document.getElementById("button1").addEventListener("click",handleClick);

Il s'agit d'une méthode beaucoup plus claire pour séparer le comportement de votre extension du balisage de son interface utilisateur.

Intégrer du contenu

Dans certains cas, votre extension peut intégrer du contenu pouvant être utilisé en externe ou proviennent d'une source externe.

Contenu des extensions dans les pages Web : Si votre extension intègre des ressources (telles que des images, des scripts, des styles CSS, etc.) qui sont utilisées dans le contenu des scripts injectés dans des pages Web, vous devez utiliser la propriété web_accessible_resources. pour ajouter ces ressources à la liste d'autorisation afin que des pages Web externes puissent les utiliser:

{
...
  "web_accessible_resources": [
    "images/image1.png",
    "script/myscript.js"
  ],
...
}

Intégrer des contenus externes: Content Security Policy n'autorise le chargement d'objets et de scripts locaux qu'à partir de votre package, ce qui empêche les pirates externes d'introduire du code inconnu dans votre extension. Cependant, il existe lorsque vous souhaitez charger des ressources diffusées en externe, comme du code jQuery ou du code Google Analytics. Pour cela, vous pouvez procéder de deux façons :

Téléchargez la bibliothèque appropriée en local (comme jQuery), puis empaquetez-la avec votre extension.
Vous pouvez assouplir la CSP de manière limitée en ajoutant les origines HTTPS à la liste d'autorisation dans "content_security_policy" de votre fichier manifeste. Pour inclure une bibliothèque comme Google Analytics, voici l'approche à adopter:
```
{
  ...,
  "content_security_policy": "script-src 'self'
  https://ssl.google-analytics.com; object-src 'self'",
  ...
}
```

Utiliser l'évaluation de scripts dynamiques

L'un des changements majeurs dans le nouveau schéma Manifest V2 est que les extensions ne peuvent plus utiliser des techniques d'évaluation de scripts dynamiques comme eval() ou le nouveau Function(), ou transmettre des chaînes de code JS. à des fonctions qui entraînent l'utilisation d'un eval(), comme setTimeout(). En outre, certaines Les bibliothèques JavaScript couramment utilisées, telles que Google Maps et certaines bibliothèques de modèles, sont connues d'utiliser certaines de ces techniques.

Chrome fournit un bac à sable pour que les pages s'exécutent dans leur propre origine, qui n'ont pas accès à Chrome*. API Pour utiliser eval() et d'autres éléments similaires dans le nouveau Content Security Policy, procédez comme suit:

Créez une entrée de bac à sable dans votre fichier manifeste.
Dans l'entrée du bac à sable, répertoriez les pages que vous souhaitez exécuter dans le bac à sable.
Utilisez la transmission de message via postMessage() pour communiquer avec la page en bac à sable.

Pour en savoir plus sur la façon de procéder, consultez la documentation sur l'évaluation du bac à sable.

Documentation complémentaire

Les modifications apportées à la version 2 du fichier manifeste ont pour but d'aider les développeurs à créer des applications des extensions et des applications à l'architecture robuste. Afficher la liste complète des modifications par rapport à la version 1 du fichier manifeste à la version 2, consultez la documentation sur le fichier manifeste. Pour en savoir plus sur l'utilisation du bac à sable, pour isoler le code non sécurisé, consultez l'article sur l'évaluation du bac à sable. Pour en savoir plus sur le contenu, nos règles de sécurité en consultant notre tutoriel sur les extensions et une présentation HTML5Rocks