Pdf.js: Violations CSP pour unsafe-inline dans [email protected]

La politique est violée par cette ligne dans v2.2.228 Function("r", "regeneratorRuntime = r")(runtime);

Ce n'est pas en fait du code provenant de la bibliothèque PDF.js elle-même, mais plutôt d'un polyfill Babel nécessaire pour prendre en charge async / await dans un navigateur plus ancien. En tant que tel, il n'est malheureusement pas du tout clair ce qui (le cas échéant) pourrait être fait à ce sujet ici .

Oui, je pense que cela devrait plutôt être signalé en amont.

@timvandermeij Le code dans pdf.js pourrait être écrit de sorte que le polyfill ne soit pas nécessaire.
@Snuffleupagus Des indices sur le fichier à consulter ?

Regardé plus profondément. Aucune chance :-(

Voici le problème regenerator-runtime/runtime.js .

Même problème ici.

@Snuffleupagus, il est possible de distribuer 2 fichiers séparés, un pour l'ancien navigateur et un 2e pour les navigateurs à feuilles persistantes ?

Y a-t-il un problème à suivre en amont ? Face au même problème actuellement

Vous pouvez signaler le problème à https://github.com/facebook/regeneator. Il semble qu'ils aient déjà corrigé certaines violations du CSP, alors peut-être qu'ils sont prêts à corriger celui-ci aussi. S'ils le corrigent en amont, nous pouvons également mettre à jour la version que nous utilisons pour le corriger de notre côté.

Il semble que les auteurs de pdf.js aient résolu ce problème ici

https://github.com/facebook/regenerator/pull/353

mais en raison de problèmes sur babel, ils ont dû l'annuler

https://github.com/facebook/regeneator/pull/369

Il semble que nous ayons une impasse ici. Je vois trois solutions ici :

• Attendez que facebook/regenerator résolve les problèmes.
  C'est peut-être le plus clair, mais beaucoup d'utilisateurs s'en tiendront à une ancienne version de pdf.js
• Déclasser facebook/regenerator (peut-être que babel doit aussi être déclassé)
• Fournissez en plus de l'ES5 actuel une version à feuilles persistantes (ES2016+) de pdf.js qui n'a pas besoin de facebook/regenerator . (Beaucoup d'applications Web actuelles n'avaient pas besoin d'être compatibles ES5).

Quoi qu'il en soit, la violation du CSP est bien documentée ici
https://github.com/facebook/regenerator/blob/6e9e8d7747c2ab49927bdd9dd6261753181faec1/packages/regenerator-runtime/runtime.js#L716 -L725

  // This module should not be running in strict mode, so the above
  // assignment should always work unless something is misconfigured. Just
  // in case runtime.js accidentally runs in strict mode, we can escape
  // strict mode using a global Function call. This could conceivably fail
  // if a Content Security Policy forbids using Function, but in that case
  // the proper solution is to fix the accidental strict mode problem. If
  // you've misconfigured your bundler to force strict mode and applied a
  // CSP to forbid Function, and you're not willing to fix either of those
  // problems, please detail your unique predicament in a GitHub issue.
  Function("r", "regeneratorRuntime = r")(runtime);

Cela signifie que si vous avez une violation de CSP, vous ne devez pas l'exécuter en mode strict. Comme il s'agit d'un comportement connu dans l'exécution du régénérateur, pdf.js doit désactiver le mode strict.

@timvandermeij Pouvez-vous relire le commentaire s'il vous plaît s'il y a une tâche à faire pour pdf.js ou non ?

Je ne vois pas vraiment ce que PDF.js pourrait faire différemment ici. Même si le commentaire est clair, nous exécutons intentionnellement PDF.js en mode strict pour éviter les erreurs et permettre des optimisations. Étant donné que cela ne s'est pas produit auparavant et que nous n'utilisons même pas facebook/regenerator directement (mais uniquement en tant que dépendance d'un autre paquet), je dirais que ceux-ci devraient être corrigés, à moins qu'il n'y ait un changement trivial que nous pouvons/ besoin de faire de notre côté, mais je ne sais pas ce que ce serait alors...

@timvandermeij

Merci d'avoir compris.

Qu'en est-il d'une version babel gratuite de pdf.js ? Le navigateur moderne ne devrait pas avoir besoin de polyfill d'exécution du régénérateur.

@jkroepke Idéalement, nous n'utiliserions pas Babel du tout, mais malheureusement, il est nécessaire pour l'instant que PDF.js fonctionne dans tous les navigateurs que nous prenons en charge, nous ne pouvons donc pas envisager de nous en débarrasser pour le moment. Bien sûr, vous pouvez créer vous-même PDF.js et désactiver la transpilation Babel.

Je rencontre le même problème avec 2.3.200. Une solution de contournement ou des correctifs? Merci.

@timvandermeij

À la fin, je vois que pdf.js le fait mal car il utilise le mode strict qui n'est pas pris en charge lors de l'utilisation de regenerator-runtime/babel. Ce n'est donc plus un problème en amont car les limitations sont bien documentées.

Je vois 4 alternatives pour résoudre ces problèmes:

• Utiliser une ancienne version de babel. La version 2.1.266 de pdf.js n'a pas ce problème. épingler les versions devrait être le résoudre. Cela devrait être le plus rapide.
• N'utilisez pas le mode strict car les dépendances de babel ne le supportent pas.
• Désactivez les plugins de transpile en utilisant regenerator-runtime. (https://caniuse.com/#feat=es6-generators)
• Fournir deux versions de pdfjs-dist. Un pour les anciens navigateurs (transpilés en ES5) et un pour les navigateurs actuels. (transpiler vers ES6)

Utiliser une ancienne version de babel. La version 2.1.266 de pdf.js n'a pas ce problème. épingler les versions devrait être le résoudre. Cela devrait être le plus rapide.

Épingler une dépendance à une ancienne version n'est jamais une bonne idée, car cela peut causer des problèmes s'il y a des bogues de sécurité dans les anciennes versions de Babel. De plus, l'utilisation d'anciennes versions d'une dépendance peut empêcher, retarder et/ou compliquer la mise à jour d'autres dépendances, causant ainsi d'autres problèmes.

[...] (https://caniuse.com/#feat=es6-generators)

Juste pour clarifier : veuillez noter que la bibliothèque PDF.js n'utilise (actuellement) aucune fonction de générateur, cependant async / await est utilisé et c'est pourquoi cette dépendance particulière existe ici.

Fournir deux versions de pdfjs-dist. Un pour les anciens navigateurs (transpilés en ES5) et un pour les navigateurs actuels. (transpiler vers ES6)

Cela semble être l'option la plus réaliste parmi les suggestions ci-dessus, mais comment/quand cela se produira n'est pas clair pour le moment (notez la discussion/les problèmes dans PR #11241).
Cependant, notez que seuls les types de builds (généraux) suivants seraient alors fournis :

• Builds uniquement compatibles avec la dernière version ES-{version}, quelle qu'elle soit à l'époque, c'est-à-dire que les fichiers construits ne sont pas exécutés via Babel et aucun polyfill n'est inclus.
• Builds compatibles ES5, c'est-à-dire que les fichiers construits sont analysés par Babel et avec des polyfills inclus.

Construit uniquement compatible avec la dernière version ES-{version}

Respecteriez-vous de n'utiliser que les fonctions/technologies prises en charge par les 2 dernières versions majeures du navigateur ?

Une version avec des fonctions de propositions de langage à la pointe de la technologie qui ne sont pas prises en charge par un navigateur plus récent ne nous aiderait pas.

Respecteriez-vous de n'utiliser que les fonctions/technologies prises en charge par les 2 dernières versions majeures du navigateur ?

Cela nécessiterait de produire trois types de builds différents, ce qui ne semble pas être une bonne idée. D'une part, les utilisateurs seraient probablement encore plus confus quant à la version à utiliser (puisque j'imagine que les utilisateurs ne sont pas sûrs même avec seulement deux types de versions). En outre, tenter de fournir plusieurs versions mettra également plus de pression, par exemple en termes de support et de maintenance, sur les quelques contributeurs réguliers de PDF.js.

Fondamentalement, la situation souhaitable dans ce cas en ce qui me concerne serait qu'un utilisateur de bibliothèque soit :

• Choisit la dernière version d'ES et fournit les polyfills eux-mêmes en fonction des plates-formes/navigateurs qu'ils doivent prendre en charge.
• Choisit la version ES5 et obtient tous les polyfills nécessaires inclus et le code compatible avec "tous" les navigateurs modernes.

Une version avec des fonctions de propositions de langage à la pointe de la technologie qui ne sont pas prises en charge par un navigateur plus récent ne nous aiderait pas.

Historiquement parlant, je ne pense pas que nous ayons déjà commencé à utiliser les fonctionnalités immédiatement lorsqu'elles sont devenues disponibles dans Firefox Nightly, par exemple, je ne peux donc pas prévoir que cela soit réellement un problème dans la pratique.

Salut,

J'ai rencontré le même problème, la solution que j'ai utilisée était de charger le régénérateur-runtime en pensant directement à mon polyfill.

De cette façon, je n'ai pas changé pdfjs-dist. Cela m'a permis de résoudre mes problèmes de CSP sans avoir à recompiler les pdfjs :)

@makidelille Vous utilisez l'angulaire ?

@makidelille Vous utilisez l'angulaire ?

nous utilisons angularjs ( toujours ).

Pour être exact, nous avons construit une visionneuse personnalisée au-dessus de pdf.js qui est utilisée via une directive angularjs

edit: la visionneuse personnalisée est construite avec des angularjs dactylographiés, c'est pourquoi nous avons des polyfills.

Je reçois une autre erreur en ligne non sécurisée pour le CSS, à partir de cette ligne de code :
https://github.com/mozilla/pdf.js/blob/master/web/ui_utils.js#L893

Refused to apply inline style because it violates the following Content Security Policy directive: "style-src ...". Either the 'unsafe-inline' keyword, a hash ('sha256-MW4Iy/yu3WipUpTMM/T6OjvUu9R6vUwutodlmYNo6qM='), or a nonce ('nonce-...') is required to enable inline execution.

Salut,

J'ai rencontré le même problème, la solution que j'ai utilisée était de charger le régénérateur-runtime en pensant directement à mon polyfill.

De cette façon, je n'ai pas changé pdfjs-dist. Cela m'a permis de résoudre mes problèmes de CSP sans avoir à recompiler les pdfjs :)

Savez-vous (ou quelqu'un d'autre) comment cette solution se traduirait en angulaire 2+ ? Est-il possible de réparer ça?

J'utilise cette bibliothèque et je rencontre le même problème de CSP (si vous le souhaitez, vous pouvez voir mon ticket dans cette liste de problèmes de projets), mais ce genre de problèmes avec des éléments de type packages/npm/dependency n'est pas quelque chose que je comprends tout cela bien.

Malheureusement, l'ancienne version de pdfjs qui n'avait pas ce problème (2.1.266, comme mentionné ci-dessus) ne semble pas être compatible avec cette bibliothèque wrapper angulaire 2+, et il ne semble pas avoir de version qui utilisait cette version de pdfjs intérieurement.

edit: Pour toute personne dans une situation similaire à la mienne, il existe une autre bibliothèque de wrapper pdfjs angulaire qui a fonctionné pour moi sans problème CSP. Voir ici .

Je pense que ce problème peut être clos maintenant, car la prochaine version comportera deux types de builds :

• Une version moderne (pour les navigateurs à jour), qui n'est pas transpilée avec Babel et sans polyfills inclus.
• Une version compatible ES5 (peut être utilisée par exemple avec IE11), qui est transpilée avec Babel et comprend tous les polyfills nécessaires.

Ça a l'air bien! Merci @Snuffleupagus et tout le monde a travaillé sur cette : 1st_place_medal :