Diese Seite wurde von der Cloud Translation API übersetzt.

Anleitung: Zu Manifest V2 migrieren

Die Manifestversion 1 wurde in Chrome 18 eingestellt und der Support wird gemäß dem Supportzeitplan für Manifestversion 1 eingestellt. Die Änderungen von Version 1 zu Version 2 lassen sich in zwei allgemeine Kategorien einteilen: API-Änderungen und Änderungen bei der Sicherheit.

Dieses Dokument enthält Checklisten für die Migration Ihrer Chrome-Erweiterungen von Manifestversion 1 zu Version 2, gefolgt von detaillierteren Zusammenfassungen, was diese Änderungen bedeuten und warum sie vorgenommen wurden.

Checkliste für API-Änderungen

Verwenden Sie die Property browser_actions oder die chrome.browserActions API?
Ersetzen Sie browser_actions durch die einzelne browser_action-Property.
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 (und es muss jetzt ein String sein).
Verwenden Sie die Property 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 (und es muss jetzt ein String sein).
Verwenden Sie die Property chrome.self?
Ersetzen Sie sie durch chrome.extension.
Verwenden Sie die Property Port.tab?
Ersetzen Sie sie durch Port.sender.
Verwenden Sie die chrome.extension.getTabContentses() oder die chrome.extension.getExtensionTabs() API?
Ersetzen Sie sie durch chrome.extension.getViews( { "type" : "tab" } ).
Verwendet deine Erweiterung eine Hintergrundseite?
Ersetzen Sie das Attribut background_page durch ein Attribut vom Typ background.
Füge eine scripts- oder page-Property hinzu, die den Code für die Seite enthält.
Füge ein persistent-Attribut hinzu und setze es auf false, um deine Hintergrundseite in eine Ereignisseite zu konvertieren

Checkliste für Sicherheitsänderungen

Verwenden Sie Inline-Skriptblöcke auf HTML-Seiten?
Entferne den in <script>-Tags enthaltenen JavaScript-Code und platziere ihn in einer externen JS-Datei.
Verwenden Sie Inline-Event-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 wie 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 (und optional eine separate Content Security Policy für diese Ressourcen) auf.
Betten Sie externe Webseiten in Ihre Erweiterung ein?
Definieren Sie das Attribut sandbox.
Verwendet Ihr Code oder Ihre Bibliothek eval(), ein neues Function(), innerHTML, setTimeout() oder andere JS-Code-Strings, 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 in Ihrem Manifest einen Sandbox-Eintrag und führen Sie den betroffenen Code in der Sandbox aus. Verwenden Sie dabei postMessage(), um mit der Seite zu kommunizieren, die in der Sandbox ausgeführt wird.
Laden Sie externen Code wie jQuery oder Google Analytics?
Sie können die Bibliothek herunterladen, in Ihre Erweiterung verpacken und dann aus dem lokalen Paket laden.
Setzen Sie die HTTPS-Domain, die die Ressource bereitstellt, im Teil „content_security_policy“ des Manifests auf die Zulassungsliste.

Zusammenfassung der API-Änderungen

Mit Manifestversion 2 werden einige Änderungen an den APIs für Browseraktionen und Seitenaktionen vorgenommen und einige alte APIs durch neue ersetzt.

Änderungen an Browseraktionen

Die Browser Actions API führt einige Namensänderungen ein:

Die Attribute browser_actions und chrome.browserActions wurden durch ihre jeweiligen Gegenstücke browser_action und chrome.browserAction ersetzt.
Unter der alten browser_actions-Property befanden sich icons-, name- und popup-Properties. Diese wurden ersetzt durch:
default_icon für das Browseraktions-Badge-Symbol
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 UI für die Browseraktion darstellt. Hierbei muss es sich um einen String handeln. Er darf kein Objekt sein.

Änderungen an Seitenaktionen

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

Die Attribute page_actions und chrome.pageActions wurden durch ihre jeweiligen Entsprechungen page_action und chrome.pageAction ersetzt.
Unter der alten page_actions-Property befanden sich icons-, name- und popup-Properties. Diese wurden ersetzt durch:
default_icon für das Symbol für das Seitenaktions-Badge
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 UI für die Seitenaktion darstellt. Dabei muss es sich um einen String handeln. Er darf kein Objekt sein.

Entfernte und geänderte APIs

Einige Erweiterungs-APIs wurden entfernt und durch neue ersetzt:

Das Attribut background_page wurde durch Hintergrund ersetzt.
Die Property chrome.self wurde entfernt. Verwende chrome.extension.
Die Eigenschaft 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

Im Zuge der Umstellung von Manifestversion 1 auf Version 2 gibt es eine Reihe von sicherheitsbezogenen Änderungen. Viele dieser Änderungen sind auf die Einführung der Content Security Policy in Chrome zurückzuführen. Lesen Sie mehr über diese Richtlinie, um sich über ihre Auswirkungen zu informieren.

Inline-Skripts und Event-Handler nicht zulässig

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

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

Dieser Code würde zur Laufzeit einen Fehler verursachen. Um dieses Problem zu beheben, verschieben Sie <script>-Tag-Inhalte in externe Dateien und verweisen Sie mit einem src='path_to_file.js'-Attribut darauf.

Ebenso werden Inline-Event-Handler, die häufig von vielen Webentwicklern verwendet werden, nicht ausgeführt. Beispiele:

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

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

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

So lassen sich das Verhalten Ihrer Erweiterung deutlich übersichtlicher vom Markup für die Benutzeroberfläche trennen.

Inhalte einbetten

Es gibt einige Szenarien, in denen Ihre Erweiterung möglicherweise Inhalte einbettet, die extern verwendet werden können oder aus einer externen Quelle stammen.

Erweiterungsinhalte in Webseiten:Wenn Ihre Erweiterung Ressourcen wie Bilder, Skripte oder CSS-Stile einbettet, die in Inhaltsskripten verwendet werden, die in Webseiten eingefügt werden, müssen Sie diese Ressourcen mit der Property web_accessible_resources auf die Zulassungsliste setzen, damit externe Webseiten sie verwenden können:

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

Externe Inhalte einbetten:Mit der Content Security Policy können nur lokale Skripts und Objekte aus Ihrem Paket geladen werden. Dadurch wird verhindert, dass externe Angreifer unbekannten Code in Ihre Erweiterung einschleusen. Manchmal möchten Sie jedoch extern bereitgestellte Ressourcen wie jQuery- oder Google Analytics-Code laden. Dafür gibt es zwei Möglichkeiten:

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

Dynamische Skriptauswertung verwenden

Eine der größten Änderungen am neuen Manifest V2-Schema besteht darin, dass Erweiterungen keine dynamischen Skriptauswertungstechniken wie eval() oder neues Function() mehr verwenden oder JS-Code-Strings nicht mehr an Funktionen übergeben können, die die Verwendung eines eval()s veranlassen, z. B. setTimeout(). Darüber hinaus verwenden bestimmte häufig verwendete JavaScript-Bibliotheken wie Google Maps und bestimmte Vorlagenbibliotheken einige dieser Techniken.

Chrome stellt eine Sandbox für Seiten bereit, die an ihrem eigenen Ursprung ausgeführt werden. Der Zugriff auf Chrome wird ihnen verweigert.* APIs Damit du eval() und Ähnliches im Rahmen der neuen Content Security Policy verwenden kannst:

Erstellen Sie in Ihrer Manifestdatei einen Sandbox-Eintrag.
Listen Sie im Sandbox-Eintrag die Seiten auf, die Sie in der Sandbox ausführen möchten.
Verwenden Sie die Nachrichtenübergabe über postMessage(), um mit der Sandbox-Seite zu kommunizieren.

Weitere Informationen dazu finden Sie in der Dokumentation zur Sandboxing-Bewertung.

Weitere Informationen

Die Änderungen in Manifestversion 2 sollen Entwickler dabei unterstützen, sicherere und robustere Erweiterungen und Apps zu erstellen. 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 eval. Weitere Informationen zur Content Security Policy finden Sie in unserem Tutorial zu Erweiterungen und einer guten Einführung in HTML5Rocks.