Diese Seite wurde von der Cloud Translation API übersetzt.

Anleitung: Zu Manifest V2 migrieren

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

Dieses Dokument enthält Checklisten für die Migration Ihrer Chrome-Erweiterungen von Manifest-Version 1 zu Version 2. Anschließend werden die Bedeutung dieser Änderungen und die Gründe für sie ausführlicher zusammengefasst.

Checkliste für API-Änderungen

Verwenden Sie die browser_actions-Property oder die chrome.browserActions API?
Ersetzen Sie browser_actions durch das Singularattribut browser_action.
Ersetzen Sie chrome.browserActions durch chrome.browserAction.
Ersetzen Sie die Property icons durch default_icon.
Ersetzen Sie die Property name durch default_title.
Ersetzen Sie das Attribut popup durch default_popup. Es muss jetzt ein String sein.
Verwenden Sie die page_actions-Property oder die chrome.pageActions API?
Ersetzen Sie page_actions durch page_action.
Ersetzen Sie chrome.pageActions durch chrome.pageAction.
Ersetzen Sie die Property icons durch default_icon.
Ersetzen Sie die Property name durch default_title.
Ersetzen Sie das Attribut popup durch default_popup. Es muss jetzt ein String sein.
Verwenden Sie die Property chrome.self?
Ersetzen Sie chrome.extension.
Verwenden Sie die Property Port.tab?
Ersetzen Sie Port.sender.
Verwenden Sie die chrome.extension.getTabContentses()- oder die chrome.extension.getExtensionTabs()-API?
Ersetzen Sie chrome.extension.getViews( { "type" : "tab" } ).
Verwendet Ihre Erweiterung eine Hintergrundseite?
Ersetzen Sie die Property background_page durch die Property background.
Fügen Sie eine scripts- oder page-Property hinzu, die den Code für die Seite enthält.
Fügen Sie eine persistent-Property hinzu und legen Sie sie auf false fest, um die Hintergrundseite in eine Ereignisseite umzuwandeln.

Checkliste für Sicherheitsänderungen

Verwenden Sie Inline-Script-Blöcke in HTML-Seiten?
Entfernen Sie den JS-Code aus den <script>-Tags und fügen Sie ihn in eine externe JS-Datei ein.
Verwenden Sie Inline-Ereignis-Handler wie „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 Inhaltsscripts in Webseiten ein, die auf Ressourcen (z. B. Bilder und Scripts) zugreifen müssen, die im Paket der Erweiterung enthalten sind?
Definieren Sie die Property web_accessible_resources und listen Sie die Ressourcen auf (optional auch eine separate Content Security Policy für diese Ressourcen).
Enthält Ihre Erweiterung eingebettete externe Webseiten?
Definieren Sie die Property sandbox.
Wird in Ihrem Code oder Ihrer Bibliothek eval(), new Function(), innerHTML, setTimeout() oder werden anderweitig JS-Code-Strings übergeben, die dynamisch ausgewertet werden?
Verwenden Sie JSON.parse(), wenn Sie JSON-Code in ein Objekt parsen.
Verwenden Sie eine CSP-kompatible Bibliothek, z. B. AngularJS.
Erstellen Sie einen Sandbox-Eintrag in Ihrem Manifest und führen Sie den betroffenen Code in der Sandbox aus. Verwenden Sie postMessage(), um mit der Seite in der Sandbox zu kommunizieren.
Laden Sie externen Code wie jQuery oder Google Analytics?
Sie können die Bibliothek herunterladen, in Ihrer Erweiterung verpacken und dann aus dem lokalen Paket laden.
Setzen Sie die HTTPS-Domain, über die die Ressource bereitgestellt wird, im Bereich „content_security_policy“ Ihres Manifests auf die Zulassungsliste.

Zusammenfassung der API-Änderungen

Manifest-Version 2 führt einige Änderungen an den Browser- und Seitenaktions-APIs ein und ersetzt einige alte APIs durch neuere.

Änderungen an Browseraktionen

Bei der Browser Actions API gibt es einige Namensänderungen:

Die Properties browser_actions und chrome.browserActions wurden durch ihre Singularformen browser_action und chrome.browserAction ersetzt.
Unter der alten browser_actions-Eigenschaft gab es die Eigenschaften icons, name und popup. Sie wurden durch Folgendes ersetzt:
default_icon für das Symbol für Browseraktionen
default_name für den Text, der in der Kurzinfo angezeigt wird, wenn Sie den Mauszeiger auf das Kennzeichen bewegen
default_popup für die HTML-Seite, die die Benutzeroberfläche für die Browseraktion darstellt (dies muss jetzt ein String sein, kein Objekt)

Änderungen an Seitenaktionen

Ähnlich wie bei den Änderungen an Browseraktionen hat sich auch die API für Seitenaktionen geändert:

Die Properties page_actions und chrome.pageActions wurden durch ihre Singularformen page_action und chrome.pageAction ersetzt.
Unter der alten page_actions-Eigenschaft gab es die Eigenschaften icons, name und popup. Sie wurden durch Folgendes ersetzt:
default_icon für das Symbol für Seitenaktionen
default_name für den Text, der in der Kurzinfo angezeigt wird, wenn Sie den Mauszeiger auf das Kennzeichen bewegen
default_popup für die HTML-Seite, die die Benutzeroberfläche für die Seitenaktion darstellt (dies muss jetzt ein String sein, kein Objekt)

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

Die Umstellung von Manifest-Version 1 auf Version 2 bringt eine Reihe von sicherheitsrelevanten Änderungen mit sich. Viele dieser Änderungen sind auf die Einführung der Content Security Policy in Chrome zurückzuführen. Lesen Sie mehr über diese Richtlinie, um ihre Auswirkungen zu verstehen.

Inline-Scripts und Event-Handler nicht zulässig

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

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

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

Ebenso werden Inline-Ereignishandler, die von vielen Webentwicklern häufig verwendet werden, nicht ausgeführt. Beispiele für gängige Instanzen:

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

Sie funktionieren nicht in Manifest V2-Erweiterungen. Entfernen Sie die Inline-Ereignis-Handler, platzieren Sie sie in Ihrer externen JS-Datei und registrieren Sie stattdessen mit addEventListener() Ereignis-Handler für sie. Verwenden Sie in Ihrem JS-Code beispielsweise:

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

So können Sie das Verhalten Ihrer Erweiterung viel übersichtlicher vom Markup der Benutzeroberfläche trennen.

Inhalte einbetten

In einigen Fällen kann Ihre Erweiterung Inhalte einbetten, die extern verwendet werden können oder aus einer externen Quelle stammen.

Erweiterungsinhalte auf Webseiten:Wenn Ihre Erweiterung Ressourcen (z. B. Bilder, Scripts, CSS-Styles usw.) einbettet, die in Inhaltsscripts verwendet werden, die in Webseiten eingefügt werden, müssen Sie die Eigenschaft 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"
  ],
...
}

Einbetten externer Inhalte: Die Content Security Policy erlaubt nur das Laden lokaler Scripts 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 wie jQuery- oder Google Analytics-Code laden möchten. Dafür gibt es zwei Möglichkeiten:

Laden Sie die entsprechende Bibliothek (z. B. jQuery) lokal herunter und verpacken Sie sie mit Ihrer Erweiterung.
Sie können die CSP in begrenztem Maße lockern, indem Sie HTTPS-Quellen im Abschnitt „content_security_policy“ Ihres Manifests auf die Zulassungsliste setzen. So fügen Sie eine Bibliothek wie Google Analytics ein:
```
{
  ...,
  "content_security_policy": "script-src 'self'
  https://ssl.google-analytics.com; object-src 'self'",
  ...
}
```

Dynamische Scriptauswertung verwenden

Eine der größten Änderungen am neuen Manifest V2-Schema ist, dass Erweiterungen keine dynamischen Skriptbewertungstechniken wie eval() oder die neue Function() mehr verwenden und keine JS-Code-Strings an Funktionen übergeben können, die zur Verwendung einer eval() führen, z. B. setTimeout(). Außerdem werden einige dieser Techniken von bestimmten gängigen JavaScript-Bibliotheken wie Google Maps und bestimmten Vorlagenbibliotheken verwendet.

Chrome bietet eine Sandbox für Seiten, die an ihrem eigenen Ursprung ausgeführt werden und denen der Zugriff auf Chrome verweigert wird.* APIs So verwenden Sie eval() und ähnliche Elemente gemäß der neuen Content Security Policy:

Erstellen Sie einen Sandbox-Eintrag in Ihrer Manifestdatei.
Geben Sie im Sandbox-Eintrag die Seiten an, die in der Sandbox ausgeführt werden sollen.
Verwenden Sie die Nachrichtenweitergabe über postMessage(), um mit der Seite im Sandbox-Modus zu kommunizieren.

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

Weitere Informationen

Die Änderungen in Manifest-Version 2 sollen Entwickler dazu anregen, 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 von unsicherem Code finden Sie im Artikel Sandboxing-Bewertung. Weitere Informationen zur Content Security Policy finden Sie in unserer Anleitung zu Erweiterungen und in einer ausführlichen Einführung auf HTML5Rocks.