Handlebars.js: Chrome拡張機能マニフェストv2はevalの使用を制限します

これは、フレームワークの設計に継承されます。 動的に生成されたJavaScriptを使用できない環境で実行している場合は、テンプレートをプリコンパイルし、生成された出力をパッケージに含める必要があります。

これは私にとって厄介です。 これがGoogleページからの引用です：

「ただし、さまざまなライブラリがeval（）や、パフォーマンスの最適化や表現のしやすさのためにnew Function（）などのevalに似た構造を使用していることを認識しています。テンプレートライブラリは、特にこのスタイルの実装になりがちです。 .js）CSPをすぐにサポートします。_多くの一般的なフレームワークは、拡張機能の評価のない世界と互換性のあるメカニズムにまだ更新されていません。したがって、その機能のサポートを削除すると、開発者が予想するよりも問題が多いことがわかりました。」

それで、いくつかのテンプレートシステムはCSPに準拠することができますが、ハンドルバーはできませんか？ そのため、プロジェクトでハンドルバーを使用したので、アプリをCSPに準拠させるための2つの選択肢があります。

1）ハンドルバーをはぎ取ります
2）すべてのテンプレートをプリコンパイルします。

私のテンプレートの動的な性質を考えると、プリコンパイルはオプションではありません。 それで、この欠陥が閉じられているので、今私はハンドルバーを引き裂かなければなりません。

ここでCSPガイドに従うことはできませんか？

「ソースリストに「unsafe-eval」を追加することで許可できます」

それは基本的に、注入を防ぐためにCSPを使用するという全体的なポイントを打ち負かします。

FWIW、Cloudant（Apache CouchDBに基づく）は最近、データベース内のスクリプト処理を変更して、 eval()とnew Function()も防止しましたhttps://console.bluemix.net/docs/services/Cloudant/release_info /deprecations.html#disabled -javascript-constructors

テンプレートをJSにプリコンパイルすることは、一部のシナリオでは機能しますが、すべてのシナリオで機能するわけではありません。 Handlebars.jsをより多くの場所で使用できるように、他のオプションがあれば素晴らしいと思います。

しかし...それは希望的観測かもしれません。 ：スマイリー：💭