Anleitung: Zu Manifest V2 migrieren

Manifestversion 1 wurde in Chrome 18 eingestellt und die Unterstützung wird gemäß dem Supportzeitplan für Manifestversion 1 schrittweise beendet. Die Änderungen von Version 1 zu Version 2 lassen sich in zwei große Kategorien einteilen: API-Änderungen und Sicherheitsänderungen.

In diesem Dokument finden Sie Checklisten für die Migration Ihrer Chrome-Erweiterungen von Manifestversion 1 zu Version 2 sowie detailliertere Zusammenfassungen der Auswirkungen dieser Änderungen und der Gründe für ihre Einführung.

Checkliste für API-Änderungen

  • Verwenden Sie das Attribut browser_actions oder die chrome.browserActions API?

  • Ersetzen Sie browser_actions durch das Attribut browser_action in der Einzahl.

  • 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. Es muss jetzt ein String sein.

  • Verwenden Sie 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. Es muss jetzt ein String sein.

  • Verwenden Sie das Attribut chrome.self?

  • Ersetzen Sie es durch chrome.extension.

  • Verwenden Sie das Attribut Port.tab?

  • Ersetzen Sie es durch Port.sender.

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

  • Ersetzen Sie sie durch chrome.extension.getViews( { "type" : "tab" } ).

  • Verwendet Ihre Erweiterung eine Hintergrundseite?

  • Ersetzen Sie das Attribut background_page durch ein Attribut background.

  • Fügen Sie ein Attribut scripts oder page hinzu, das den Code für die Seite enthält.

  • Fügen Sie ein Attribut persistent hinzu und legen Sie es auf false fest, um Ihre Hintergrundseite in eine Ereignis seite umzuwandeln.

Checkliste für Sicherheitsänderungen

  • Verwenden Sie Inline-Skriptblöcke auf HTML-Seiten?

  • Entfernen Sie den JS-Code in den <script>-Tags und fügen Sie ihn in eine externe JS-Datei ein.

  • Verwenden Sie Inline-Ereignis-Handler (z. B. onclick)?

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

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

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

  • Bettet Ihre Erweiterung externe Webseiten ein?

  • Definieren Sie das Attribut sandbox.

  • Verwendet Ihr Code oder Ihre Bibliothek eval() , new Function() , innerHTML oder setTimeout() oder werden auf andere Weise Strings mit 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 postMessage(), um mit der Sandbox-Seite zu kommunizieren.

  • Laden Sie externen Code, z. B. jQuery oder Google Analytics?

  • Laden Sie die Bibliothek herunter, packen Sie sie in Ihre Erweiterung und laden Sie sie dann aus dem lokalen Paket.

  • Fügen Sie die HTTPS-Domain, die die Ressource bereitstellt, im Abschnitt „content_security_policy“ Ihres Manifests zur Zulassungsliste hinzu.

Zusammenfassung der API-Änderungen

In Manifestversion 2 wurden einige Änderungen an den APIs für Browser- und Seitenaktionen vorgenommen und einige alte APIs durch neuere ersetzt.

Änderungen an Browseraktionen

Bei der Browser Actions API wurden einige Namen geändert:

  • Die Attribute browser_actions und chrome.browserActions wurden durch die entsprechenden Attribute in der Einzahl browser_action und chrome.browserAction ersetzt.
  • Das alte Attribut browser_actions enthielt die Attribute icons, name und popup. Diese wurden durch Folgendes ersetzt:

  • default_icon für das Symbol des Browseraktionslogos

  • default_name für den Text, der im Tooltip angezeigt wird, wenn Sie den Mauszeiger auf das Logo bewegen

  • default_popup für die HTML-Seite, die die Benutzeroberfläche für die Browseraktion darstellt. Sie muss jetzt ein String sein und kann kein Objekt sein.

Änderungen an Seitenaktionen

Ähnlich wie bei den Browseraktionen wurde auch die Seitenaktionen-API geändert:

  • Die Attribute page_actions und chrome.pageActions wurden durch die entsprechenden Attribute in der Einzahl ersetzt: page_action und chrome.pageAction.
  • Das alte Attribut page_actions enthielt die Attribute icons, name und popup. Diese wurden durch Folgendes ersetzt:

  • default_icon für das Symbol des Seitenaktionslogos

  • default_name für den Text, der im Tooltip angezeigt wird, wenn Sie den Mauszeiger auf das Logo bewegen

  • default_popup für die HTML-Seite, die die Benutzeroberfläche für die Seitenaktion darstellt. Sie muss jetzt ein String sein und kann kein Objekt sein.

Entfernte und geänderte APIs

Einige Erweiterungs-APIs wurden entfernt und durch neue ersetzt:

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

Zusammenfassung der Sicherheitsänderungen

Mit der Umstellung von Manifestversion 1 auf Version 2 wurden eine Reihe von sicherheitsrelevanten Änderungen eingeführt. Viele dieser Änderungen sind auf die Einführung der Content Security Policy in Chrome zurückzuführen. Sie sollten sich näher mit dieser Richtlinie befassen, um ihre Auswirkungen zu verstehen.

Inline-Skripts und -Ereignis-Handler nicht zulässig

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

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

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

Ebenso werden Inline-Ereignis-Handler, die häufig verwendet werden und eine praktische Funktion für viele Webentwickler darstellen, nicht ausgeführt. Beispiele:

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

Diese funktionieren nicht in Manifest V2-Erweiterungen. Entfernen Sie die Inline-Ereignis-Handler, fügen Sie sie in Ihre externe JS-Datei ein und verwenden Sie stattdessen addEventListener(), um Ereignis-Handler für sie zu registrieren. Verwenden Sie beispielsweise in Ihrem JS-Code:

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

So können Sie das Verhalten Ihrer Erweiterung viel besser von der Markup-Benutzeroberfläche trennen.

Inhalte einbetten

In einigen Fällen bettet Ihre Erweiterung möglicherweise Inhalte ein, die extern verwendet werden können oder aus einer externen Quelle stammen.

Erweiterungsinhalte auf Webseiten: Wenn Ihre Erweiterung Ressourcen (z. B. Bilder, Skripts, CSS-Stile usw.) einbettet, die in Inhaltsskripts verwendet werden, die in Webseiten eingefügt werden, müssen Sie das Attribut web_accessible_resources verwenden, um diese Ressourcen zur Zulassungsliste hinzuzufügen, 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 Skripts und Objekte aus Ihrem Paket. So wird verhindert, dass externe Angreifer unbekannten Code in Ihre Erweiterung einschleusen. Es gibt jedoch Fälle, in denen Sie extern bereitgestellte Ressourcen laden möchten, z. B. jQuery- oder Google Analytics-Code. Dafür gibt es zwei Möglichkeiten:

  1. Laden Sie die entsprechende Bibliothek lokal herunter (z. B. jQuery) und packen Sie sie in Ihre Erweiterung.
  2. Sie können die CSP auf begrenzte Weise lockern, indem Sie HTTPS-Ursprünge im Abschnitt „content_security_policy“ Ihres Manifests zur Zulassungsliste hinzufügen. So fügen Sie eine Bibliothek wie Google Analytics hinzu:

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

Dynamische Skriptauswertung verwenden

Eine der größten Änderungen im neuen Manifest V2-Schema besteht darin, dass Erweiterungen keine dynamischen Skriptauswertungstechniken wie eval() oder new Function() mehr verwenden oder Strings mit JS-Code an Funktionen übergeben können, die eine eval()-Auswertung verursachen, z. B. setTimeout(). Außerdem verwenden bestimmte häufig verwendete JavaScript-Bibliotheken wie Google Maps und bestimmte Vorlagenbibliotheken einige dieser Techniken.

Chrome bietet eine Sandbox für Seiten, die in ihrem eigenen Ursprung ausgeführt werden und keinen Zugriff auf chrome.* APIs haben. So verwenden Sie eval() und ähnliche Funktionen unter der neuen Content Security Policy:

  1. Erstellen Sie in Ihrer Manifestdatei einen Sandbox-Eintrag.
  2. Listen Sie im Sandbox-Eintrag die Seiten auf, die in der Sandbox ausgeführt werden sollen.
  3. Verwenden Sie die Nachrichtenübergabe über postMessage(), um mit der Sandbox-Seite zu kommunizieren.

Weitere Informationen dazu finden Sie in der Dokumentation zu Sandboxing Eval.

Weitere Informationen

Die Änderungen in Manifestversion 2 sollen Entwicklern helfen, sicherere und robuster strukturierte Erweiterungen und Apps zu entwickeln. Eine vollständige Liste der Änderungen von Manifestversion 1 zu Version 2 finden Sie in der Dokumentation zur Manifestdatei. Weitere Informationen zur Verwendung von Sandboxing zum Isolieren unsicheren Codes finden Sie im Artikel Sandboxing Eval. Weitere Informationen zur Content Security Policy finden Sie in unserem Tutorial zu Erweiterungen und in einer guten Einführung auf HTML5Rocks.