Les différents niveaux d’utilisation des scripts JavaScript

PDF : les différents niveaux d’utilisation des scripts JavaScript

 

Il y a scripts JavaScript ET scripts JavaScript, certains ont tous les droits et d’autres non, tout dépend à quel niveau ils s’exécutent.
L’architecture de sécurité du format PDF respecte une hiérarchie stricte, et comme avec toute hiérarchie : plus l’ordre vient d’en haut, moins il est discutable.
Et vice-versa : on ne peut pas permettre qu’un simple matelot puisse donner l’ordre d’appareiller à un porte-avions.

Certaines restrictions sont parfois frustrantes pour le concepteur mais il faut les envisager sous l’angle de la sécurité et de la protection maximale de l’utilisateur, qui pourrait aussi bien être votre directeur que votre grand-mère…

Il en résulte nécessairement un difficile compromis entre liberté-facilité d’utilisation et restrictions avec alertes « de la mort qui tue » qui font peur à tout le monde et en particulier au directeur (ma grand-mère en a vu d’autres).

javascript-icone

 

1- Script d’application

Tous privilèges d’exécution.

Un script d’application est un script JavaScript qui se présente sous la forme d’un fichier texte portant le suffixe .js que l’on installe dans le sous-répertoire JavaScripts d’Adobe Reader ou d’Acrobat.

Il doit être installé manuellement et pas simplement (explicitement) sur chaque poste utilisateur par quelqu’un censé savoir ce qu’il fait et censé avoir vérifié ce qu’il installe. Il n’est donc pas censé pouvoir être malicieux. Dans le cadre d’un parc machines important, on peut installer automatiquement les scripts d’application avec un installeur personnalisé, mais ça ne change rien aux considérations sécuritaires.

Le script d’application est chargé au démarrage du logiciel et à tous les droits possibles, c’est le sommet de la hiérarchie : enregistrement d’un fichier PDF dans un répertoire pré-déterminé, modification de l’interface du logiciel (boutons et menus), etc.

Du fait de ses privilèges maximum, dans une entreprise un tant soit peu sérieuse et soucieuse de sécurité un script d’application ne devrait pas pouvoir être installé sans l’aval d’un responsable.

Exemples (gratuits) :

 

 

2- Script de traitement par lot – Actions

Privilèges limités.

Les « Séquences de traitement par lot » d’Acrobat sont devenues des « Actions » depuis la version X, cela ne change pas grand-chose au principe ni à leur fonctionnement mais l’interface y a beaucoup gagné.

En ce qui concerne la sécurité et la protection les Actions sont particulières dans le sens ou elles ne fonctionnent qu’avec le logiciel Adobe Acrobat* qui est un logiciel commercial et qu’elles répondent à un usage professionnel et « avancé ». D’autre part l’utilisateur est censé savoir à peu près ce qu’il fait, a priori ça ne concerne donc pas ma grand-mère ni le directeur.
*  ==> les Actions ne fonctionnent pas avec le logiciel gratuit Adobe Reader.

En plus de pouvoir enchainer automatiquement quasiment toutes les fonctions d’Acrobat, les Actions peuvent aussi exécuter des scripts JavaScript. Mais comme une Action peut être installée et exécutée immédiatement depuis un double-clic de l’utilisateur ses droits sont forcément moindres que ceux d’un script d’application, particulièrement en ce qui concerne les droits d’écriture/lecture des fichiers.

Exemples (gratuits) :

 

 

3- Script de document

Privilèges restreints.

Le script de document s’exécute à l’ouverture de n’importe quel PDF dans tout logiciel reconnaissant les scripts JavaScript, en général il est utilisé pour pré-charger en mémoire vive des fonctions personnalisées particulières au document ou récurrentes (menus déroulants, formats, validation, etc.), ce qui rend leur accès plus rapide pour la machine et leur maintenance plus facile pour l’humain, qui évite ainsi d’avoir des bouts de scripts dispersés et redondants un peu partout dans le document PDF.

Comme il peut être exécuté à l’ouverture de n’importe quel PDF téléchargé n’importe où par n’importe quelle grand-mère ou n’importe quel directeur ce type de script à des droits beaucoup plus restreints, par exemple il est impossible de modifier ou d’enregistrer javascriptement un fichier, PDF ou autre, sans l’autorisation explicite de l’utilisateur. Pas question non plus d’enregistrer quoi que soit dans un répertoire pré-défini, et encore moins de pouvoir modifier l’interface du logiciel. Seul l’ajout temporaire d’un bouton-icône flottant est possible.

Avec Acrobat on accède aux scripts de document via : panneau Outils : JavaScript : Scripts JavaScript du document.
Avec Scribus on accède aux scripts de document via : menu Edition : JavaScripts.

Exemples (gratuits) :

 

 

4- Script d’évènement

Privilèges restreints.

Le script d’évènement n’a pas plus de droits ni de privilèges que le script de document, la différence c’est qu’il s’exécute lors d’un évènement précis déclenché par l’utilisateur.

Il y en a sept disponibles répartis en deux groupes.

Les évènements du document :

  • Quand le document sera fermé
  • Quand le document sera enregistré
  • Quand le document a été enregistré
  • Quand le document sera imprimé
  • Quand le document a été imprimé

Avec Acrobat on accède aux scripts d’événements du document via : panneau Outils : JavaScript : Scripts JavaScript du document.

 

Les évènements de page :

  • Ouverture de la page
  • Fermeture de la page

Avec Acrobat on accède aux scripts d’événements de page via le menu local du panneau Pages (ou vignettes) : Propriétés : Actions

À ma connaissance, Scribus ne gère pas encore les scripts d’événement.

 

 

5- Script d’action utilisateur

Privilèges restreints.

Mêmes droits et privilèges que les deux précédents, ce type de script répond à une action directe de l’utilisateur sur un élément du document, comme le clic sur un bouton ou un signet, le remplissage d’un champ de texte, l’utilisation d’une liste déroulante, l’apposition d’une signature numérique, etc.

Les scripts d’action utilisateur sont en général des aides ou des contrôles de saisie personnalisés, ou bien des calculs complexes entre chiffres. Ils sont utilisés en complément des fonctions offertes via l’interface d’Acrobat, de Scribus, etc.
C’est le type de script JavaScript le plus couramment utilisé.

Exemple (gratuit) : http://abracadabrapdf.net/category/pdf-de-demo/formulaires/

 

 

Restriction importante dans tous les cas

Dans les Préférences d’Adobe Reader, d’Adobe Acrobat et de tous les logiciels sérieux il est possible pour l’utilisateur, ou pour son service informatique, de désactiver l’exécution des scripts JavaScript.

Pour le concepteur de formulaires PDF ou de PDF interactifs cela veut dire qu’il faut toujours prendre cette éventualité en compte…

Mais comment afficher une alerte à l’utilisateur quand on ne peut pas scripter ?

L’astuce c’est d’afficher par défaut un filigrane, un champ de formulaire ou un calque qui recouvre toutes les pages du document PDF.
Filigrane, champ ou calque qui ne sert qu’à prévenir l’utilisateur de la nécessité d’activer JavaScript pour pouvoir profiter pleinement du document :

  1. si JavaScript est désactivé ou si le logiciel utilisé ne le reconnait pas du tout, l’utilisateur est prévenu par un message bien en évidence.
  2. si JavaScript est activé comme attendu, un script de document habilement conçu aura masqué le filigrane, le champ ou le calque avant même l’ouverture du document PDF sans que l’utilisateur ne se rende compte de rien.
    On en reparlera bientôt…

😉

Print Friendly