Anleitung: Zu Manifest V2 migrieren

Die Manifestversion 1 wurde in Chrome 18 eingestellt und die Unterstützung wird gemäß Supportzeitplan für Manifestversion 1. Die Änderungen von Version 1 zu Version 2 fallen unter zwei allgemeinen Kategorien: API-Änderungen und Sicherheitsänderungen.

Dieses Dokument enthält Checklisten für die Migration Ihrer Chrome-Erweiterungen von Manifestversion 1 zu Version 2 gefolgt von ausführlicheren Zusammenfassungen der Bedeutung und der Gründe für diese Änderungen.

Checkliste für API-Änderungen

  • Verwendest du das Attribut browser_actions oder die chrome.browserActions API?

  • Ersetzen Sie browser_actions durch die Singular-browser_action-Eigenschaft.

  • Ersetzen Sie chrome.browserActions durch chrome.browserAction.

  • Ersetzen Sie das Attribut icons durch default_icon.

  • Ersetzen Sie das Attribut name durch default_title.

  • Ersetzen Sie das Attribut popup durch default_popup (jetzt muss ein String sein).

  • Verwendest du das Attribut page_actions oder die chrome.pageActions API?

  • Ersetzen Sie page_actions durch page_action.

  • Ersetzen Sie chrome.pageActions durch chrome.pageAction.

  • Ersetzen Sie das Attribut icons durch default_icon.

  • Ersetzen Sie das Attribut name durch default_title.

  • Ersetzen Sie das Attribut popup durch default_popup (jetzt muss ein String sein).

  • Verwendest du die Property chrome.self?

  • Durch chrome.extension ersetzen.

  • Verwendest du die Property Port.tab?

  • Durch Port.sender ersetzen.

  • Verwenden Sie die chrome.extension.getTabContentses() oder den chrome.extension.getExtensionTabs() APIs?

  • Durch chrome.extension.getViews( { "type" : "tab" } ) ersetzen.

  • Verwendet Ihre Erweiterung eine Hintergrundseite?

  • Ersetzen Sie das Attribut background_page durch das Attribut background.

  • Füge eine scripts- oder page-Property hinzu, die den Code für die Seite enthält.

  • Füge eine persistent-Property hinzu und setze sie auf false, um deine Hintergrundseite in ein Ereignis umzuwandeln Seite

Checkliste für Sicherheitsänderungen

  • Verwenden Sie Inline-Script-Blöcke auf HTML-Seiten?

  • Entferne den JS-Code in <script>-Tags und platziere ihn in einer externen JS-Datei.

  • Verwenden Sie Inline-Event-Handler wie "onclick"?

  • Entfernen Sie sie aus dem HTML-Code, verschieben Sie sie in eine externe JS-Datei und verwenden Sie addEventListener() .

  • Fügt Ihre Erweiterung Inhaltsskripte in Webseiten ein, die auf Ressourcen zugreifen müssen (z. B. Bilder und Skripts), die im Paket der Erweiterung enthalten sind?

  • Definieren Sie das Attribut web_accessible_resources und listen Sie die Ressourcen auf (und optional einen separate Content Security Policy für diese Ressourcen).

  • Werden in Ihrer Erweiterung externe Webseiten eingebettet?

  • Definieren Sie das Attribut sandbox.

  • Verwendet dein Code oder deine Bibliothek eval(), das neue Function(), innerHTML, setTimeout() oder oder Zeichenfolgen von JS-Code übergeben, die dynamisch ausgewertet werden?

  • Verwenden Sie JSON.parse(), wenn Sie JSON-Code in ein Objekt parsen.

  • Verwenden Sie eine CSP-freundliche Bibliothek, z. B. AngularJS.

  • Erstellen Sie in Ihrem Manifest einen Sandbox-Eintrag und führen Sie den betroffenen Code in der Sandbox aus. Verwenden Sie dazu postMessage(), um mit der in der Sandbox ausgeführten Seite zu kommunizieren.

  • Laden Sie externen Code wie jQuery oder Google Analytics?

  • Sie können die Bibliothek herunterladen, in die Erweiterung verpacken und dann über die lokales Paket.

  • Setzen Sie die HTTPS-Domain, die die Ressource bereitstellt, in „content_security_policy“ auf die Zulassungsliste Teil Ihres Manifests.

Zusammenfassung der API-Änderungen

Mit Manifestversion 2 werden einige Änderungen an den APIs für Browseraktionen und Seitenaktionen eingeführt und ersetzt mit neueren APIs arbeiten.

Änderungen an Browseraktionen

Mit der Browser Actions API wurden einige Namensänderungen eingeführt:

  • Die Attribute browser_actions und chrome.browserActions wurden durch ihre Einzige Gegenstücke browser_action und chrome.browserAction.
  • Unter der alten browser_actions-Property waren icons, name und popup vorhanden. Diese wurden ersetzt durch:

  • default_icon für das Badge-Symbol „Browseraktion“

  • default_name für den Text, der in der Kurzinfo erscheint, wenn Sie den Mauszeiger auf das Logo bewegen

  • default_popup für die HTML-Seite, die die Benutzeroberfläche für die Browseraktion darstellt (und dies muss jetzt ein String sein, darf kein Objekt sein)

Änderungen an Seitenaktionen

Ähnlich wie bei den Browseraktionen wurde auch die Page Actions API geändert:

  • Die Properties page_actions und chrome.pageActions wurden durch ihren Singular ersetzt Gegensätze page_action und chrome.pageAction.
  • Unter der alten page_actions-Property waren icons, name und popup vorhanden. Diese wurden ersetzt durch:

  • default_icon für das Kennzeichensymbol für die Seitenaktion

  • default_name für den Text, der in der Kurzinfo erscheint, wenn Sie den Mauszeiger auf das Logo bewegen

  • default_popup für die HTML-Seite, die die Benutzeroberfläche für die Seitenaktion darstellt. Dies muss nun ein String ist, darf kein Objekt sein)

Entfernte und geänderte APIs

Einige Erweiterungs-APIs wurden entfernt und durch neue Versionen ersetzt:

  • Das Attribut background_page wurde durch background ersetzt.
  • Das Attribut chrome.self wurde entfernt. Verwenden Sie chrome.extension.
  • Das Attribut Port.tab wurde durch Port.sender ersetzt.
  • Die chrome.extension.getTabContentses() und die chrome.extension.getExtensionTabs() API haben durch chrome.extension.getViews( { "type" : "tab" } ) ersetzt.

Zusammenfassung der Sicherheitsänderungen

Es gibt eine Reihe sicherheitsbezogener Änderungen, die mit der Umstellung von Manifest-Version 1 auf Version 2. Viele dieser Änderungen gehen auf die Einführung der Content Security Policy in Chrome zurück. ich sollten Sie mehr über diese Richtlinie lesen, um ihre Auswirkungen zu verstehen.

Inline-Skripts und Event-Handler nicht zulässig

Aufgrund der Verwendung der Content Security Policy können Sie keine <script>-Tags mehr verwenden, die inline sind mit dem HTML-Inhalt. Diese müssen in externe JS-Dateien verschoben werden. Außerdem können Inline-Event-Handler werden ebenfalls nicht unterstützt. Angenommen, Ihre Erweiterung enthält den folgenden Code:

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

Dieser Code würde während der Laufzeit einen Fehler verursachen. Verschieben Sie den Inhalt des <script>-Tags in externe Dateien, um das Problem zu beheben und mit einem src='path_to_file.js'-Attribut darauf verweisen.

Ähnlich verhält es sich mit Inline-Event-Handlern, die oft von vielen Nutzern verwendet werden. nicht ausführen. Betrachten Sie beispielsweise häufige Instanzen wie:

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

Diese funktionieren nicht in Manifest V2-Erweiterungen. Entfernen Sie die Inline-Event-Handler, platzieren Sie sie im externe JS-Datei an und verwenden Sie stattdessen addEventListener(), um Event-Handler für sie zu registrieren. Für Beispiel in Ihrem JS-Code:

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

So lässt sich das Verhalten der Erweiterung klarer von der Auszeichnung der Benutzeroberfläche trennen.

Inhalte einbetten

In einigen Szenarien können in Ihrer Erweiterung Inhalte eingebettet sein, die extern verwendet oder aus einer externen Quelle stammen.

Erweiterungsinhalte auf Webseiten: Wenn in Ihrer Erweiterung Ressourcen wie Bilder, Scripts, CSS-Stile usw. eingebettet sind, die in Inhalten verwendet werden Skripte, die in Webseiten eingeschleust werden, müssen Sie die Property web_accessible_resources verwenden. um diese Ressourcen auf die Zulassungsliste zu setzen, damit sie von externen Webseiten verwendet werden können:

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

Externe Inhalte einbetten: Die Content Security Policy erlaubt nur das Laden lokaler Scripts und Objekte aus Ihrem Paket, was verhindert, dass externe Angreifer unbekannten Code in Ihre Erweiterung einschleusen. Es gibt jedoch wenn Sie extern bereitgestellte Ressourcen wie jQuery- oder Google Analytics-Code laden möchten. Dafür gibt es zwei Möglichkeiten:

  1. Laden Sie die entsprechende Bibliothek lokal herunter (z. B. jQuery) und verpacken Sie sie mit Ihrer Erweiterung.
  2. Sie können die CSP eingeschränkt lockern, indem Sie HTTPS-Ursprünge in der &quot;content_security_policy&quot; deines Manifests. Wenn Sie eine Bibliothek wie Google Analytics einbinden möchten, lautet der Ansatz:

    {
      ...,
      "content_security_policy": "script-src 'self'
      https://ssl.google-analytics.com; object-src 'self'",
      ...
    }
    

Dynamische Skriptauswertung verwenden

Eine der vielleicht größten Änderungen am Schema für Manifest v2 besteht darin, dass Erweiterungen nicht mehr Verwenden Sie dynamische Skriptbewertungstechniken wie eval() oder das neue Function() oder übergeben Sie JavaScript-Strings. Code für Funktionen, die die Verwendung eines eval() verursachen, z. B. setTimeout(). Darüber hinaus können bestimmte häufig verwendete JavaScript-Bibliotheken wie Google Maps und bestimmte Vorlagenbibliotheken, einige dieser Techniken einsetzen.

Chrome bietet eine Sandbox für Seiten, die in ihrem eigenen Ursprung ausgeführt werden können. Für diesen Ursprung wird der Zugriff auf Chrome verweigert.* APIs So verwenden Sie eval() und Ähnliches gemäß der neuen Content Security Policy:

  1. Erstellen Sie in Ihrer Manifestdatei einen Sandbox-Eintrag.
  2. Listen Sie im Sandbox-Eintrag die Seiten auf, die Sie in der Sandbox ausführen möchten.
  3. Verwenden Sie eine Nachricht, die über postMessage() weitergegeben wird, um mit der in der Sandbox ausgeführten Seite zu kommunizieren.

Weitere Informationen hierzu finden Sie in der Dokumentation zur Sandbox-Bewertung.

Weitere Informationen

Die Änderungen in der Manifestversion 2 sollen Entwickler dabei unterstützen, Erweiterungen und Anwendungen entwickelt. Um eine vollständige Liste der Änderungen gegenüber Manifestversion 1 anzuzeigen Version 2 finden Sie in der Dokumentation zur Manifestdatei. Weitere Informationen zur Verwendung der Sandbox zur Isolierung von unsicherem Code finden Sie im Artikel zur Sandbox-Evaluierung. Weitere Informationen zu Inhalten Sicherheitsrichtlinie finden Sie in unserer Anleitung zu Erweiterungen und als gute Einführung HTML5Rocks