Ich habe eine wirklich einfache Chrome-Erweiterung erstellt und einen einfachen node.js-Server eingerichtet, um die automatische Aktualisierungsfunktion zu testen. Der Server hostet die .crx-Datei, so dass ich die Erweiterung problemlos installieren kann, indem ich einfach http://localhost:3000/clients/chrome/extension.crx besuche. Aber wenn ich zu tools - & gt; extensions gehe und auf Update extensions now klicke, ruft die Erweiterung die neue Version nicht ab. Der Server empfängt die Anforderung für localhost:3000/clients/chrome/updates.xml , erhält jedoch keine Anforderung für die neue extension.crx-Datei. Was mache ich hier falsch?
CODE
Lassen Sie mich Sie durch den Code führen, um dies reproduzierbar zu machen:
$ tree
%Vor%Die Erweiterung ist wirklich nur eine Manifest-Datei.
manifest.json
%Vor%Wie Sie sehen, beziehe ich mich auf eine update_url, um eine automatische Aktualisierung zu ermöglichen.
updates.xml
%Vor%Durch das Packen der Erweiterung werden extension.crx und extension.pem erstellt.
Ich habe auch einen einfachen node.js-Server erstellt, der die Dateien bereitstellt:
web.js
%Vor%Ok, lass es uns testen. Starten Sie zuerst den Server:
$ node web.js
%Vor%Installieren Sie die Erweiterung, indem Sie Ссылка besuchen. Dieser Teil funktioniert perfekt beim ersten Versuch. Der Server protokolliert die Anfrage:
%Vor%Ändern wir die Erweiterung:
version auf 1.1 (intead von 1.0). version auf 1.1 (statt 1.0). extention.pem -Datei wie beim ersten Mal. extension.crx wird erstellt. Tools - & gt; Extensions - & gt; Update extensions now
Man würde erwarten, dass die Versionsnummer der Erweiterung in Tools - & gt; Extensions auf 1.1 geändert wird.
Stattdessen passiert nichts. Der Server erhält eine Anfrage für updates.xml , aber nicht für extension.crx .
Ich denke, der Fehler liegt darin, wie Ihre web.js-Datei updates.xml bedient. Hier ist meine Argumentation:
updates.xml , der auf eine von Dropbox gehostete Datei verweist, und einen anderen mit einem von Dropbox gehosteten updates.xml , der auf eine Node-gehostete crx-Datei zeigt. Das Ergebnis war, dass, wenn updates.xml von Node geliefert wurde, Chrome die Erweiterung nicht korrekt aktualisiert hat und wenn updates.xml von Dropbox gehostet wurde, alles gut, unabhängig davon, wer die crx-Datei gehostet hat. (Und ich habe die update_url im Manifest geändert und die Erweiterung für jede Testversion neu erstellt / hochgeladen.)
Warum genau das passiert, ist für mich immer noch ein ziemlich großes Rätsel. Hier sind die HTTP-Response-Header, die ich bekomme, wenn ich updates.xml in Chrome abrufe (normalerweise benutze ich die Adressleiste; ich schnüffle nicht den tatsächlichen Netzverkehr von der Update-Operation, sondern simuliere ihn einfach):
Dropbox:
%Vor%Node.js:
%Vor% Ich dachte auch, es könnte ein Problem mit den Ports sein (vielleicht möchte Chrome nicht von Nicht-80-Ports updaten?), und ich habe gerade entdeckt, dass updates.xml und crx-Datei von meinem eigenen Apache-Server geliefert wird auf Port 80 verursacht Bruch identisch mit dem Problem mit Knoten beobachtet.
Ich wünschte, ich hätte eine echte Antwort für Sie, aber vielleicht können Sie einige Tests mit Dropbox ausführen und schließlich herausfinden, was sie anders machen, was Chrome zu ihrer Update-Datei macht.
Da es Ihr XML bekommt und die Erweiterung nicht aktualisiert, mag es etwas in Ihrem Update XML wahrscheinlich nicht. Meine beste Vermutung ist, dass Ihre 'appid' nicht mit der App ID der installierten Extension übereinstimmt. Auf der Seite chrome: // extensions wird die 'ID' der installierten Erweiterung angezeigt und überprüft, ob dieser Wert dem Wert in der Datei update.xml entspricht.
Tags und Links google-chrome-extension auto-update