web-dev-qa-db-fra.com

Pourquoi l'utilisation des clés downloadURL et updateURL est-elle inhabituelle et comment fonctionnent-elles?

Je lisais wiki de GM pour déterminer la différence entre @downloadURL & @updateURL (ce que je n'ai pas fait). Mais ce qui m'a encore plus troublé, c'est que les deux ne sont pas conseillés:

Il est inhabituel de spécifier cette valeur. La plupart des scripts devraient l'omettre.

Cela m'étonne car c'est le seul moyen pour les scripts de se mettre à jour automatiquement et je ne vois pas pourquoi ces clés ne devraient pas être utilisées.

Le wiki lui-même manque assez et aucune autre source de forum n'est conseillée, je dois donc demander ici. Apprécierais également des informations plus détaillées sur ces clés.

greasemonkeyuserscriptstampermonkey
31
ZeroUnderscoreOu

L'utilisation de ces clés est déconseillée principalement par le développeur principal de Greasemonkey. La plupart des autres, y compris l'équipe de Tampermonkey ne ressentent pas le besoin d'un tel avertissement.
Notez également que ces directives sont pas toujours nécessaires pour que les mises à jour automatiques fonctionnent.

Quelques raisons pour lesquelles il dirait que c'était inhabituel et que "la plupart" des scripts devraient l'omettre:

  1. Dans la plupart des cas, cela n'est pas nécessaire, voir ci-dessous comment fonctionnent les mises à jour et comment fonctionnent ces directives.
  2. L'ajout et l'utilisation de ces directives sont juste plus d'éléments que le script scripteur doit vérifier et maintenir. Pourquoi faire du travail s'il n'est pas nécessaire?.
  3. L'implémentation de la mise à jour et ces directives ont été boguées et, peut-être, pas bien implémentées dans Greasemonkey.
  4. Tampermonkey et d'autres moteurs implémentent les mises à jour et ces directives d'une manière légèrement différente. Cela signifie que le code qui fonctionne sur Tampermonkey peut échouer sur Greasemonkey.

Notez que cette entrée wiki était faite par le développeur principal de Greasemonkey (Arantius) lui-même ; donc ce n'était pas seulement du bruit wiki.

Fonctionnement des mises à jour:

Les mises à jour du script sont effectuées en 4 phases:

  1. La phase activée et/ou les mises à jour "forcées".
  2. La phase de vérification .
  3. La phase de téléchargement .
  4. La phase d'analyse et d'installation.

Pour cette question, nous ne sommes concernés que par les phases check et download. Nous stipulons que les mises à jour sont activées et que le script mis à jour était valide et installé correctement.

Lors de la mise à jour des scripts, Greasemonkey (et Tampermonkey) télécharge les fichiers deux fois :

  1. Le premier téléchargement, contrôlé par la valeur updateURL du script, consiste simplement à vérifier @version (Le cas échéant) et la date du fichier - pour voir si une mise à jour est disponible.

  2. Le deuxième téléchargement, contrôlé par la valeur downloadURL du script, est le téléchargement réel du nouveau script à installer. Ce téléchargement ne se produira que si le fichier serveur a un numéro @version Supérieur au fichier local et/ou si le fichier serveur a une date plus récente que le fichier local. (Attention, il existe ici des différences critiques entre les moteurs de script.)

    Voir "Pourquoi utiliser @downloadURL et @updateURL" ci-dessous pour les raisons pour lesquelles 2 téléchargements de fichiers sont utilisés.


Comment @downloadURL Et @updateURL Fonctionnent:

@downloadURL Remplace simplement l'emplacement interne "URL de téléchargement" par défaut.
@updateURL Remplace simplement l'emplacement interne par défaut de "mise à jour de l'URL" (ou de vérification).
Dans la plupart des cas, cela n'est pas nécessaire. Voir ci-dessous.

  1. Lorsque vous installez un script utilisateur, Greasemonkey enregistre automatiquement l'emplacement d'installation. Aucune directive méta n'est nécessaire. Par défaut, c'est là que Greasemonkey va à la fois vérifier pour les mises à jour et télécharger toutes les mises à jour.
  2. Mais, si @downloadURL Est spécifié, alors Greasemonkey les deux vérifiera et téléchargera depuis l'emplacement spécifié plutôt que l'emplacement stocké.
  3. Mais, si @updateURL Est spécifié, alors Greasemonkey vérifiera (pas télécharger) à partir de l'emplacement de "mise à jour" donné.

Ainsi: @updateURL Remplace à la fois @downloadURL Et l'emplacement par défaut pour les opérations vérification uniquement.
While: @downloadURL Remplace l'emplacement par défaut pour les deux vérification et téléchargement (sauf si @updateURL Est présent ).


Pourquoi vous pourriez utiliser @downloadURL Et @updateURL:

Tout d'abord, il y a 2 téléchargements et potentiellement 2 emplacements différents principalement pour des raisons de vitesse et de bande passante . Considérons un scénario dans lequel un très grand script utilisateur a des milliers d'utilisateurs:

  • Les navigateurs de ces utilisateurs martelaient constamment le serveur hôte pour vérifier si une mise à jour était disponible. La plupart du temps, ce ne serait pas le cas et le gros fichier serait téléchargé à plusieurs reprises inutilement. Cela devait être un problème pour des sites comme l'ancien userscripts.org.
  • Ainsi, un système a été développé grâce auquel un fichier séparé a été créé pour contenir uniquement les informations de version (et de date). Ainsi, le serveur aurait désormais veryLarge.user.js Et veryLarge.meta.js
  • veryLarge.meta.js Serait mis à jour (par le développeur) à chaque fois que le script utilisateur était et contiendrait simplement le bloc de métadonnées de veryLarge.user.js.
  • Ainsi, les milliers de navigateurs téléchargeraient simplement à plusieurs reprises le veryLarge.meta.js Beaucoup plus petit, ce qui ferait gagner du temps à tout le monde et économiser la bande passante du serveur.

De nos jours, Greasemonkey et Tampermonkey recherchent automatiquement un fichier *.meta.js, Donc il n'est normalement pas nécessaire d'en spécifier un séparément.

Donc, pourquoi spécifier explicitement @downloadURL Et/ou @updateURL? Quelques raisons possibles:

  1. Votre script peut être installé de plusieurs façons ou à partir de plusieurs sources (copier-coller, fichier copié localement, serveur secondaire, etc.) et vous ne souhaitez conserver qu'une seule version "maître".
  2. Vous voulez pour suivre le nombre de téléchargements initiaux et/ou de mise à niveau de votre script .
  3. @downloadURL Est également un moyen pratique "d'auto-documentation" d'enregistrer/transmettre d'où l'utilisateur a obtenu le script.
  4. Vous voulez que le fichier *.meta.js Sur un serveur différent de celui du script utilisateur pour une raison quelconque.
  5. Peut-être des problèmes http contre https (besoin de creuser cela un jour).
  6. Vous êtes un méchant et vous voulez que le script mette à jour une version malveillante à une date ultérieure à partir d'un serveur que vous contrôlez - ce n'est pas d'où le script a été installé.


Quelques différences entre Greasemonkey et Tampermonkey:

(Attention: je n'ai pas vérifié tout cela depuis un moment. Sujet à changement de toute façon car Tampermonkey s'améliore constamment (et Greasemonkey change également beaucoup).)

  1. Tampermonkey nécessite une directive @version À la fois sur le fichier actuel et le fichier plus récent. C'est ainsi que Tampermonkey détermine si une mise à jour est disponible.

    Greasemonkey utilisera également cette méthode, donc incluez toujours @version Dans les scripts que vous voudrez peut-être mettre à jour automatiquement.

    Cependant, Greasemonkey requiert également que le fichier de mise à jour soit plus récent. Et si aucune version n'est présente, Greasemonkey ne comparera que les dates. Notez que cela a causé des problèmes dans Greasemonkey dans le passé et suppose également que de nombreuses machines différentes sont synchronisées avec précision avec la date et l'heure correctes.

  2. Greasemonkey ne sera mis à jour qu'à partir des schémas https:// Par défaut, mais peut éventuellement être défini pour autoriser les schémas http:// Et ftp://.

  3. Les deux moteurs n'autorisent jamais les mises à jour à partir des schémas file://.

39
Brock Adams