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 dechrome.browserActions
API?Vervang
browser_actions
door de unieke eigenschapbrowser_action
.Vervang
chrome.browserActions
doorchrome.browserAction
.Vervang de eigenschap
icons
doordefault_icon
.Vervang de eigenschap
name
doordefault_title
.Vervang de
popup
eigenschap doordefault_popup
(en deze moet nu een string zijn).Gebruikt u de eigenschap
page_actions
of dechrome.pageActions
API?Vervang
page_actions
doorpage_action
.Vervang
chrome.pageActions
doorchrome.pageAction
.Vervang de eigenschap
icons
doordefault_icon
.Vervang de eigenschap
name
doordefault_title
.Vervang de
popup
eigenschap doordefault_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 dechrome.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 eigenschapbackground
.Voeg een
scripts
ofpage
eigenschap toe die de code voor de pagina bevat.Voeg een
persistent
eigenschap toe en stel deze in opfalse
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()
, newFunction()
,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
enchrome.browserActions
zijn vervangen door hun unieke tegenhangersbrowser_action
enchrome.browserAction
. Onder de oude eigenschap
browser_actions
waren ericons
,name
enpopup
-eigenschappen. Deze zijn vervangen door:default_icon
voor het badgepictogram van de browseractiedefault_name
voor de tekst die in de tooltip verschijnt als u de muisaanwijzer op de badge plaatstdefault_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
enchrome.pageActions
zijn vervangen door hun unieke tegenhangerspage_action
enchrome.pageAction
. Onder de oude eigenschap
page_actions
warenicons
,name
enpopup
upeigenschappen aanwezig. Deze zijn vervangen door:default_icon
voor het badgepictogram voor de paginaactiedefault_name
voor de tekst die in de tooltip verschijnt als u de muisaanwijzer op de badge plaatstdefault_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, gebruikchrome.extension
. - De eigenschap
Port.tab
is vervangen doorPort.sender
. - De
chrome.extension.getTabContentses()
en dechrome.extension.getExtensionTabs()
API's zijn vervangen doorchrome.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:
- Download de relevante bibliotheek lokaal (zoals jQuery) en verpak deze met uw extensie.
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:
- Maak een sandbox-item in uw manifestbestand.
- Vermeld in het sandboxitem de pagina's die u in de sandbox wilt uitvoeren.
- 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.