Handlebars.js: Le manifeste d'extension Chrome v2 restreint l'utilisation d'eval

Créé le 25 févr. 2013 · 5Commentaires · Source: handlebars-lang/handlebars.js

Les guidons ne fonctionneront pas dans les extensions Chrome avec manifest_version : 2 en raison d'une nouvelle politique de sécurité qui restreint l'utilisation de la syntaxe eval et de type eval.

Uncaught EvalError : a refusé d'évaluer une chaîne en tant que JavaScript car 'unsafe-eval' n'est pas une source de script autorisée dans la directive de politique de sécurité du contenu suivante : "script-src 'self' chrome-extension-resource:".
guidon.js:1402
JavaScriptCompiler.createFunctionContext handlebars.js:1402
JavaScriptCompiler.compile handlebars.js:1320
compiler handlebars.js:2105
(fonction anonyme) handlebars.js:2112
(fonction anonyme) panel.js:14 <--- mon script appelé Handlebars.compile()

Source

asgraf

Commentaire le plus utile

Cela va à l'encontre de l'intérêt d'utiliser un CSP pour empêcher l'injection.

rsrsps le 19 mars 2015

👍2

Tous les 5 commentaires

Ceci est hérité de la conception du cadre. Si vous utilisez un environnement dans lequel vous ne pouvez pas utiliser le javascript généré dynamiquement, vous devrez précompiler vos modèles et inclure la sortie générée avec votre package.

kpdecker le 25 févr. 2013

C'est troublant pour moi. Voici une citation de la page Google :

"Nous reconnaissons, cependant, qu'une variété de bibliothèques utilisent eval() et des constructions de type eval telles que new Function() pour l'optimisation des performances et la facilité d'expression. Les bibliothèques de modèles sont particulièrement sujettes à ce style d'implémentation. _Alors que certaines (comme Angular .js) prend en charge le CSP prêt à l'emploi,_ de nombreux frameworks populaires n'ont pas encore mis à jour un mécanisme compatible avec le monde sans évaluation des extensions. La suppression de la prise en charge de cette fonctionnalité s'est donc avérée plus problématique que prévu pour les développeurs. "

Ainsi, certains systèmes de modèles peuvent réussir à être compatibles CSP, mais pas les guidons ? Donc, maintenant que j'ai utilisé des guidons dans mon projet, je suis coincé avec 2 choix pour que mon application soit conforme au CSP :

1) Déchirez le guidon
2) Pré-compiler tous mes modèles.

Étant donné la nature dynamique de mes modèles, la pré-compilation n'est pas une option. Du coup, maintenant je dois arracher le guidon car ce défaut est fermé.

ghost le 1 avr. 2014

👍2

N'est-il pas possible de suivre le guide CSP ici ?

"Vous pouvez l'autoriser en ajoutant 'unsafe-eval' à votre liste de sources"

georgefrick le 2 avr. 2014

Cela va à l'encontre de l'intérêt d'utiliser un CSP pour empêcher l'injection.

rsrsps le 19 mars 2015

👍2

FWIW, Cloudant (basé sur Apache CouchDB) a récemment modifié son traitement de script dans la base de données pour empêcher également eval() et new Function() https://console.bluemix.net/docs/services/Cloudant/release_info /deprecations.html#disabled -javascript-constructors

La précompilation des modèles dans JS fonctionne pour certains scénarios, mais pas pour tous. Ce serait bien s'il y avait d'autres options, afin que Handlebars.js puisse être utilisé à plus d'endroits.

Mais... ce n'est peut-être qu'un vœu pieux. :smiley: 💭