Zelfstudie: Migreren naar Manifest V2

Manifestversie 1 is beëindigd in Chrome 18 en de ondersteuning wordt uitgefaseerd volgens het ondersteuningsschema van manifestversie 1 . De wijzigingen van versie 1 naar versie 2 vallen onder twee brede categorieën: API-wijzigingen en beveiligingswijzigingen.

Dit document biedt checklists voor het migreren van uw Chrome-extensies van manifestversie 1 naar versie 2, gevolgd door gedetailleerdere samenvattingen van wat deze wijzigingen betekenen en waarom ze zijn aangebracht.

Controlelijst voor API-wijzigingen

  • Gebruikt u de eigenschap browser_actions of de chrome.browserActions API?

  • Vervang browser_actions door de unieke eigenschap browser_action .

  • Vervang chrome.browserActions door chrome.browserAction .

  • Vervang de eigenschap icons door default_icon .

  • Vervang de eigenschap name door default_title .

  • Vervang de popup eigenschap door default_popup (en deze moet nu een string zijn).

  • Gebruikt u de eigenschap page_actions of de chrome.pageActions API?

  • Vervang page_actions door page_action .

  • Vervang chrome.pageActions door chrome.pageAction .

  • Vervang de eigenschap icons door default_icon .

  • Vervang de eigenschap name door default_title .

  • Vervang de popup eigenschap door default_popup (en deze moet nu een string zijn).

  • Gebruikt u de eigenschap chrome.self ?

  • Vervangen door chrome.extension .

  • Gebruikt u de eigenschap Port.tab ?

  • Vervang Port.sender .

  • Gebruikt u de chrome.extension.getTabContentses() of de chrome.extension.getExtensionTabs() API's?

  • Vervangen door chrome.extension.getViews( { "type" : "tab" } ) .

  • Maakt uw extensie gebruik van een achtergrondpagina?

  • Vervang de eigenschap background_page door een eigenschap background .

  • Voeg een scripts of page eigenschap toe die de code voor de pagina bevat.

  • Voeg een persistent eigenschap toe en stel deze in op false om uw achtergrondpagina om te zetten in een evenementenpagina

Controlelijst voor beveiligingswijzigingen

  • Gebruikt u inline scriptblokken in HTML-pagina's?

  • Verwijder de JS-code die zich in <script> -tags bevindt en plaats deze in een extern JS-bestand.

  • Maakt u gebruik van inline gebeurtenishandlers (zoals onclick, enz.)?

  • Verwijder ze uit de HTML-code, verplaats ze naar een extern JS-bestand en gebruik in plaats daarvan addEventListener() .

  • Injecteert uw extensie inhoudsscripts in webpagina's die toegang nodig hebben tot bronnen (zoals afbeeldingen en scripts) die zich in het pakket van de extensie bevinden?

  • Definieer de eigenschap web_accessible_resources en vermeld de bronnen (en optioneel een afzonderlijk inhoudbeveiligingsbeleid voor die bronnen).

  • Sluit uw extensie externe webpagina's in?

  • Definieer de sandbox- eigenschap.

  • Gebruikt uw code of bibliotheek eval() , new Function() , innerHTML , setTimeout() of geeft u op een andere manier tekenreeksen JS-code door die dynamisch worden geëvalueerd?

  • Gebruik JSON.parse() als u JSON-code in een object parseert.

  • Gebruik een CSP-vriendelijke bibliotheek, bijvoorbeeld AngularJS .

  • Maak een sandbox-item in uw manifest en voer de betrokken code uit in de sandbox, waarbij u postMessage() gebruikt om te communiceren met de sandbox-pagina.

  • Laadt u externe code, zoals jQuery of Google Analytics?

  • Overweeg om de bibliotheek te downloaden, deze in uw extensie te verpakken en deze vervolgens vanuit het lokale pakket te laden.

  • Zet het HTTPS-domein dat de bron bedient op de toelatingslijst in het gedeelte 'content_security_policy' van uw manifest.

Samenvatting van API-wijzigingen

Manifestversie 2 introduceert een paar wijzigingen in de browseractie en paginaactie-API's, en vervangt een paar oude API's door nieuwere.

Wijzigingen in browseracties

De browseracties-API introduceert enkele naamswijzigingen:

  • De eigenschappen browser_actions en chrome.browserActions zijn vervangen door hun unieke tegenhangers browser_action en chrome.browserAction .
  • Onder de oude eigenschap browser_actions waren er icons , name en popup -eigenschappen. Deze zijn vervangen door:

  • default_icon voor het badgepictogram van de browseractie

  • default_name voor de tekst die in de tooltip verschijnt als u de muisaanwijzer op de badge plaatst

  • default_popup voor de HTML-pagina die de gebruikersinterface voor de browseractie vertegenwoordigt (en dit moet nu een tekenreeks zijn, het kan geen object zijn)

Wijzigingen in pagina-acties

Net als bij de wijzigingen voor browseracties is ook de API voor pagina-acties gewijzigd:

  • De eigenschappen page_actions en chrome.pageActions zijn vervangen door hun unieke tegenhangers page_action en chrome.pageAction .
  • Onder de oude eigenschap page_actions waren icons , name en popup upeigenschappen aanwezig. Deze zijn vervangen door:

  • default_icon voor het badgepictogram voor de paginaactie

  • default_name voor de tekst die in de tooltip verschijnt als u de muisaanwijzer op de badge plaatst

  • default_popup voor de HTML-pagina die de gebruikersinterface voor de paginaactie vertegenwoordigt (en dit moet nu een tekenreeks zijn, het kan geen object zijn)

API's verwijderd en gewijzigd

Een aantal uitbreidings-API's zijn verwijderd en vervangen door nieuwe tegenhangers:

  • De eigenschap background_page is vervangen door background .
  • De eigenschap chrome.self is verwijderd, gebruik chrome.extension .
  • De eigenschap Port.tab is vervangen door Port.sender .
  • De chrome.extension.getTabContentses() en de chrome.extension.getExtensionTabs() API's zijn vervangen door chrome.extension.getViews( { "type" : "tab" } ) .

Samenvatting van beveiligingswijzigingen

Er zijn een aantal beveiligingsgerelateerde wijzigingen die gepaard gaan met de overstap van manifestversie 1 naar versie 2. Veel van deze wijzigingen komen voort uit de adoptie van het Content Security Policy door Chrome; U moet meer over dit beleid lezen om de implicaties ervan te begrijpen.

Inline-scripts en gebeurtenishandlers zijn niet toegestaan

Vanwege het gebruik van Content Security Policy kunt u niet langer <script> -tags gebruiken die inline zijn met de HTML-inhoud. Deze moeten worden verplaatst naar externe JS-bestanden. Bovendien worden inline gebeurtenishandlers ook niet ondersteund. Stel dat u de volgende code in uw extensie heeft:

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

Deze code zou tijdens runtime een fout veroorzaken. Om dit op te lossen, verplaatst u <script> -taginhoud naar externe bestanden en verwijst u ernaar met een src='path_to_file.js' attribuut.

Op dezelfde manier zullen inline gebeurtenishandlers, die veel voorkomen en een handige functie zijn die door veel webontwikkelaars wordt gebruikt, niet worden uitgevoerd. Denk bijvoorbeeld eens aan veel voorkomende gevallen zoals:

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

Deze werken niet in manifeste V2-extensies. Verwijder de inline gebeurtenishandlers, plaats ze in uw externe JS-bestand en gebruik addEventListener() om gebeurtenishandlers daarvoor te registreren. Gebruik in uw JS-code bijvoorbeeld:

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

Dit is een veel duidelijkere manier om het gedrag van uw extensie te scheiden van de opmaak van de gebruikersinterface.

Inhoud insluiten

Er zijn enkele scenario's waarin uw extensie inhoud kan insluiten die extern kan worden gebruikt of afkomstig is van een externe bron.

Extensie-inhoud op webpagina's: als uw extensie bronnen insluit (zoals afbeeldingen, scripts, CSS-stijlen, enz.) die worden gebruikt in inhoudsscripts die in webpagina's worden geïnjecteerd, moet u de eigenschap web_accessible_resources gebruiken om deze bronnen op de toelatingslijst te zetten, zodat externe internetgebruikers pagina's kunnen ze gebruiken:

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

Externe inhoud insluiten: het Content Security Policy staat alleen toe dat lokale scripts en objecten uit uw pakket worden geladen, waardoor wordt voorkomen dat externe aanvallers onbekende code in uw extensie introduceren. Er zijn echter momenten waarop u extern aangeboden bronnen wilt laden, zoals jQuery- of Google Analytics-code. Er zijn twee manieren om dit te doen:

  1. Download de relevante bibliotheek lokaal (zoals jQuery) en verpak deze met uw extensie.
  2. U kunt de CSP op een beperkte manier versoepelen door HTTPS-oorsprongen op de toelatingslijst te zetten in de sectie 'content_security_policy' van uw manifest. Om een ​​bibliotheek als Google Analytics op te nemen, is dit de aanpak:

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

Dynamische scriptevaluatie gebruiken

Misschien wel een van de grootste veranderingen in het nieuwe manifest v2-schema is dat extensies niet langer dynamische scriptevaluatietechnieken zoals eval() of new Function() kunnen gebruiken, of strings JS-code kunnen doorgeven aan functies die ervoor zorgen dat een eval() wordt gebruikt, zoals setTimeout() . Bovendien is het bekend dat bepaalde veelgebruikte JavaScript-bibliotheken, zoals Google Maps en bepaalde sjabloonbibliotheken, enkele van deze technieken gebruiken.

Chrome biedt een sandbox voor pagina's die in hun eigen oorsprong kunnen worden uitgevoerd en waarvoor de toegang tot chrome.* API's wordt geweigerd. Om eval() en dergelijke te gebruiken onder het nieuwe Content Security Policy:

  1. Maak een sandbox-item in uw manifestbestand.
  2. Vermeld in het sandboxitem de pagina's die u in de sandbox wilt uitvoeren.
  3. Gebruik het doorgeven van berichten via postMessage() om te communiceren met de sandboxpagina.

Zie de Sandboxing Eval -documentatie voor meer informatie over hoe u dit kunt doen.

Verder lezen

De wijzigingen in manifestversie 2 zijn bedoeld om ontwikkelaars te begeleiden bij het bouwen van veiligere en robuuster ontworpen extensies en apps. Zie de documentatie van het manifestbestand voor een volledige lijst met wijzigingen van manifestversie 1 naar versie 2. Voor meer informatie over het gebruik van sandboxing om onveilige code te isoleren, leest u het eval-artikel over sandboxing . U kunt meer leren over het inhoudsbeveiligingsbeleid door onze extensiegerelateerde tutorial en een goede introductie over HTML5Rocks te bezoeken.