Versions d'une extension, mise à jour et compatibilité
Un article de MDC.
Sommaire |
[modifier] Versions d'un module
Les modules doivent spécifier leurs versions en utilisant le Format de version du toolkit. Il s'agit approximativement d'une chaîne de caractères découpée par des points, comme par exemple :
- 2.0
- 1.0b1
- 3.0pre1
- 5.0.1.2
[modifier] Comment les applications déterminent la compatibilité
Lors de l'installation de modules, les applications regardent les entrées de targetApplication dans le fichier install.rdf du module. L'id de cette entrée doit correspondre exactement à l'id de l'application. De plus, les valeurs minVersion et maxVersion de cette entrée doivent former un intervalle comprenant la version de l'application.
Si l'application possède une entrée targetApplication pour une version incompatible, elle tentera alors d'obtenir des informations de mise à jour à partir de l'updateURL du module.
Si le fichier install.rdf contient des entrées targetPlatform, la plateforme devant faire tourner l'application doit y être listée. Dans le cas contraire, l'installation sera refusée.
Nouveau dans Firefox 3 Dans des applications basées sur Gecko 1.9, vous pouvez également utiliser une entrée targetApplication avec une id toolkit@mozilla.org, et des valeurs minVersion et maxVersion qui correspondent à la version du toolkit faisant tourner l'application. Cela vous permet que d'installer votre module sur n'importe quelle application basée sur ce toolkit.
[modifier] Outrepasser les tests de compatibilité
Nouveau dans Firefox 1.5 Pour des besoins de tests, vous pouvez dire à l'application d'ignorer quelque peu les vérifications de compatibilité lors de l'installation de modules. Créez simplement une préférence booléenne extensions.checkCompatibility avec la valeur false.
app.extensions.version servait à outrepasser la version que l'application croyait pouvoir installer normalement.[modifier] Choix de minVersion et maxVersion
minVersion et maxVersion doivent spécifier la plage de versions de l'application sur laquelle vous avez fait des tests. En particulier, vous ne devriez jamais spécifier un maxVersion plus grand que la version actuelle de l'application, puisque vous ne connaissez pas les modifications possibles à venir des API et de l'interface utilisateur. Avec la mise à jour de compatibilité, il n'est pas nécessaire de fournir une version entière nouvelle de l'extension simplement pour augmenter son maxVersion.
Pour la valeur maxVersion, il est généralement permis d'utiliser un * à la place de la version mineure de l'application supportée, par exemple 2.0.0.* signifiera que vous supporterez toutes les mises à jour mineures de la version 2.
N'allez pas imaginer que * dans une version représente n'importe quelle version. Le * représente en fait un nombre infiniment grand et n'a réellement un sens que lorsqu'il est utilisé dans maxVersion. Si vous l'utilisez dans minVersion, vous n'obtiendrez pas le résultat escompté.
[modifier] Vérification automatique des mises à jour de modules
Les applications vont vérifier périodiquement les mises à jour à installer des modules en récupérant le fichier updateURL. L'information renvoyée peut servir à prévenir l'utilisateur d'une mise à jour d'un module, aussi bien qu'indiquer à l'application qu'il existe des nouvelles versions d'applications compatibles avec ce module.
[modifier] Mise à jour de compatibilité
Pendant la phase de vérification automatique, les applications examinent à la fois s'il existe des nouvelles versions et des mises à jour de compatibilité concernant la version installée d'un module. Cela signifie que votre manifeste de mise à jour contient une entrée pour la version actuellement installée du module, et l'entrée targetApplication spécifie un maxVersion plus grand, l'application utilisera cette valeur à la place de celle spécifiée dans le fichier install.rdf du module. De ce fait, des modules qui étaient désactivés car incompatibles peuvent s'activer, et des modules qui ne s'installaient normalement pas peuvent être installés.
[modifier] Format RDF de mise à jour
Si vous hébergez l'updateURL de votre module vous-même, vous devrez alors retourner l'information de version dans un format RDF. Vous trouverez ci dessous un exemple de manifeste de mise à jour. Il liste les informations de 2 différentes versions de l'extension ayant pour id foobar@developer.mozilla.org. Les versions incluses sont 2.2 et 2.5, et chacune d'elles définit une compatibilité avec les versions de 1.5 à 2.0.0.* de Firefox. Pour la version 2.2, un lien https de mise à jour est employé tandis que pour la version 2.5, c'est un lien régulier http avec un hash pour vérifier le fichier récupéré.
Il est important de récupérer correctement l'attribut about du RDF:Description initial. Cette information précisera de quel type de module il s'agit :
- Pour une extension, il s'agit de
urn:mozilla:extension:<id> - Pour un thème, il s'agit de
urn:mozilla:theme:<id> - Pour tout autre type de module, il s'agit de
urn:mozilla:item:<id>
<?xml version="1.0" encoding="UTF-8"?>
<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:em="http://www.mozilla.org/2004/em-rdf#">
<!-- Cette ressource de description inclut toutes les informations de mise à jour
et de compatibilité pour un unique module ayant l'id foobar@developer.mozilla.org.
Vous pouvez lister plusieurs informations de module dans un même fichier RDF. -->
<RDF:Description about="urn:mozilla:extension:foobar@developer.mozilla.org">
<em:updates>
<RDF:Seq>
<!-- Chaque li est une version différente du même module -->
<RDF:li>
<RDF:Description>
<em:version>2.2</em:version> <!-- Ceci est le numéro de version du module -->
<!-- Un targetApplication pour chacune des applications avec laquelle le module est compatible -->
<em:targetApplication>
<RDF:Description>
<em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
<em:minVersion>1.5</em:minVersion>
<em:maxVersion>2.0.0.*</em:maxVersion>
<!-- Ceci est l'emplacement de téléchargement du module -->
<em:updateLink>https://www.mysite.com/foobar2.2.xpi</em:updateLink>
<!-- Une page décrivant les nouveautés de la mise à jour -->
<em:updateInfoURL>http://www.mysite.com/updateinfo2.2.xhtml</em:updateInfoURL>
</RDF:Description>
</em:targetApplication>
</RDF:Description>
</RDF:li>
<RDF:li>
<RDF:Description>
<em:version>2.5</em:version>
<em:targetApplication>
<RDF:Description>
<em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
<em:minVersion>1.5</em:minVersion>
<em:maxVersion>2.0.0.*</em:maxVersion>
<em:updateLink>http://www.mysite.com/foobar2.5.xpi</em:updateLink>
<um:updateHash>sha1:78fc1d2887eda35b4ad2e3a0b60120ca271ce6e6</em:updateHash>
</RDF:Description>
</em:targetApplication>
</RDF:Description>
</RDF:li>
</RDF:Seq>
</em:updates>
<!-- Une signature est nécessaire seulement si votre module inclut un updateKey dans
son fichier install.rdf. -->
<em:signature>MIGTMA0GCSqGSIb3DQEBBQUAA4GBAMO1O2gwSCCth1GwYMgscfaNakpN40PJfOWt
ub2HVdg8+OXMciF8d/9eVWm8eH/IxuxyZlmRZTs3O5tv9eWAY5uBCtqDf1WgTsGk
jrgZow1fITkZI7w0//C8eKdMLAtGueGfNs2IlTd5P/0KH/hf1rPc1wUqEqKCd4+L
BcVq13ad</em:signature>
</RDF:Description>
</RDF:RDF>
Certaines personnes préfèrent le format alternatif suivant (notez que beaucoup d'informations ont été retirées de cet exemple par souci de clarté) :
<?xml version="1.0" encoding="UTF-8"?>
<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:em="http://www.mozilla.org/2004/em-rdf#">
<!-- Cette ressource de description inclut toutes les informations de mise à jour
et de compatibilité pour un unique module ayant l'id foobar@developer.mozilla.org.
Vous pouvez lister plusieurs informations de module dans un même fichier RDF. -->
<RDF:Description about="urn:mozilla:extension:foobar@developer.mozilla.org">
<em:updates>
<RDF:Seq>
<!-- L'attribut resource pointe vers une entrée RDF:Description correspondante
plus bas. L'uri peut être ce que vous voulez -->
<RDF:li resource="urn:mozilla:extension:foobar@developer.mozilla.org:2.2"/>
<RDF:li resource="urn:mozilla:extension:foobar@developer.mozilla.org:2.5"/>
</RDF:Seq>
</em:updates>
<em:signature>MIGTMA0GCSqGSIb3DQEBBQUAA4GBAMO1O2gwSCCth1GwYMgscfaNakpN40PJfOWt
ub2HVdg8+OXMciF8d/9eVWm8eH/IxuxyZlmRZTs3O5tv9eWAY5uBCtqDf1WgTsGk
jrgZow1fITkZI7w0//C8eKdMLAtGueGfNs2IlTd5P/0KH/hf1rPc1wUqEqKCd4+L
BcVq13ad</em:signature>
</RDF:Description>
<!-- Ceci représente la même description qu'avec le li de l'exemple précédent -->
<RDF:Description about="urn:mozilla:extension:foobar@developer.mozilla.org:2.2">
<em:version>2.2</em:version>
<!-- suppression du contenu ici -->
</RDF:Description>
<RDF:Description about="urn:mozilla:extension:foobar@developer.mozilla.org:2.5">
<em:version>2.5</em:version>
<!-- suppression du contenu ici -->
</RDF:Description>
</RDF:RDF>
[modifier] Fournir des détails sur les mises à jour
Cet article traite de fonctionnalités introduites dans Firefox 3
Il est possible de fournir à l'utilisateur quelques détails sur les nouveautés d'une mise à jour d'un module. Ils seront visibles lorsque l'utilisateur reçoit une notification de mise à jour et devraient lui permettre d'avoir un aperçu rapide des nouvelles fonctionnalités et des problèmes de sécurité résolus.
Pour réaliser cela, vous devez ajouter une entrée updateInfoURL à votre manifeste de mise à jour (voir l'exemple ci-dessous). La page à cette URL sera récupérée et affichée à l'utilisateur. Puisqu'elle est affichée en dehors du contexte d'une page Web normale, son contenu est énormément assaini, ce qui signifie qu'il n'y a pas beaucoup d'options de formatage disponibles et les scripts et images ne sont pas autorisés.
- h1, h2 et h3 pour les en-têtes généraux
- p pour les paragraphes
- ul et ol pour les listes.
À l'intérieur des listes, utilisez les balises habituelles li pour chaque item.
À l'intérieur des balises h1, h2, h3, p et li, vous pouvez utiliser :
- b ou strong pour du texte en gras
- i ou em pour du texte en italique
La page d'information récupérée doit être actuellement totalement valide en XHTML, et doit être servie avec le type MIME application/xhtml+xml.
[modifier] Mises à jour sécurisées
Introduit dans Gecko 1.9
Cet article traite de fonctionnalités introduites dans Firefox 3
Gecko 1.9 dispose d'un processus supplémentaire destiné à protéger les utilisateurs contre les attaques de l'homme du milieu ainsi que pendant des mises à jour de modules. Dans le fichier install.rdf du module déjà installé, updateURL doit être défini d'une des façons suivantes :
- L'
updateURLutilise https, ou il n'y a aucunupdateURL(ce qui par défaut correspond à addons.mozilla.org qui est en https) - L'
updateURLutilise http et l'entréeupdateKeyest spécifiée pour permettre de vérifier les données du manifeste d'installation.
Lorsque vous spécifier une updateKey dans install.rdf, vous devez inclure une signature numérique dans le manifeste de mise à jour ou l'information sera rejetée.
Dans le manifeste de mise à jour délivré par updateURL, updateLink doit être défini d'une des façons suivantes :
- Le lien
updateLinkvers un fichier XPI doit utiliser https - Le lien
updateLinkpeut utiliser http et vous devez inclure une entréeupdateHashpour le fichier XPI en utilisant des algorithmes de hachage sha1, sha256, sha384 ou sha512.
Toutes les entrées du manifeste de mise à jour qui ne respectent pas ces deux exigences seront ignorées lors de la vérification des nouvelles versions.
Notez que les liens https vers des sites ayant des certificats invalides ou qui redirigent les requêtes vers des sites http échoueront également pour les cas update.rdf et updateLink
[modifier] Hachages de mise à jour
Afin de vérifier l'intégrité du XPI téléchargé, vous devez fournir une entrée updateHash en même temps que le lien updateLink. Il s'agit d'un hachage sous la forme d'un texte généré à partir des données du fichier. L'algorithme de hachage utilisé est placé en préfixe de la chaîne de caractères et séparé par un :.
<em:updateHash>sha1:78fc1d2887eda35b4ad2e3a0b60120ca271ce6e6</em:updateHash>
Une erreur est affichée lorsque le hachage d'un fichier téléchargé diffère de son hachage spécifié.
[modifier] Signature de manifestes de mise à jour
Introduit dans Gecko 1.9
Cet article traite de fonctionnalités introduites dans Firefox 3
Si vous souhaitez servir votre RDF de mise à jour depuis un serveur http classique, les applications basées sur Gecko 1.9 auront besoin que vous signez numériquement le manifeste de mise à jour pour garantir que l'information n'est pas altérée entre le moment où vous l'avez créée et celui où les applications la récupèrent. L'outil McCoy doit être utilisé pour signer le RDF de mise à jour.
Les détails techniques du mécanisme de signature dépasse le cadre de ce document, toutefois les bases sont les suivantes :
L'auteur du module crée une paire de clés cryptée RSA publique/privée.
La partie publique de la clé est encodée en DER et encodée en base 64, puis ajoutée au fichier install.rdf du module dans l'entrée updateKey.
Lorsque l'auteur crée le fichier rdf de mise à jour, un outil sert à le signer en utilisant la partie privée de la clé. Plus simplement, l'information de mise à jour est convertie en chaîne de caractères, puis hachée par un algorithme sha512 et le hachage obtenu est signé grâce à la clé privée. La donnée résultante est encodée en DER, puis encodée en base 64 pour être inclue dans le rdf de mise à jour comme une entrée em:signature.