Underscore.js _.template 导致 Chrome 扩展程序出错

发布于 2024-12-26 03:31:30 字数 287 浏览 5 评论 0 原文

如果我使用 underscore.js_.template() 我在控制台中收到以下错误:

未捕获错误:此上下文不允许从字符串生成代码

有什么方法可以解决此错误吗?

If I use underscore.js's _.template() from inside a Google Chrome extension I get the following error in the console:

Uncaught Error: Code generation from strings disallowed for this context

Is there any way to get past this error?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

不再让梦枯萎 2025-01-02 03:31:30

非常感谢 Chromium 列表贡献者指出,要以下划线的方式创建 Function 对象,需要 content_security_policymanifest.json 选项code> 包含“unsafe-eval”。

例如,您的 manifest.json 可能是

{
  "manifest_version": 2,
  ...
  "content_security_policy": "script-src 'self' 'unsafe-eval'",
  ...
}

,然后下划线行为将起作用,因为此策略允许它。有关该格式的详细信息,请参阅此处有关此选项的 Chrome 文档。

Many thanks to the Chromium list contributor who pointed out that to create a Function object in the way underscore is doing it requires the manifest.json option for content_security_policy to include 'unsafe-eval'.

As an example, your manifest.json could be

{
  "manifest_version": 2,
  ...
  "content_security_policy": "script-src 'self' 'unsafe-eval'",
  ...
}

and then the underscore behavior would work because this policy allows it. For more information on the format see the Chrome documentation on this option here.

美胚控场 2025-01-02 03:31:30

不幸的是,我认为你不能在 chrome 扩展中使用 underscore.js 的 _.template() ...至少对于新的 manifest.json 版本 2 来说是这样。尝试使用 jQuery 模板插件

来自 Google Chrome 扩展程序的内容安全政策页面:

<块引用>

没有机制可以放松对执行内联 JavaScript 的限制。特别是,设置包含 unsafe-inline 的脚本策略将不会产生任何效果。这是故意的。

我将研究其他希望不使用 new Function 对象的模板引擎。

Unfortunately I don't think you can use underscore.js's _.template() from within a chrome extension...at least with the new manifest.json version 2. The same holds true for trying to use the jQuery Template plugin.

From the Google Chrome Extension's Content Security Policy page:

There is no mechanism for relaxing the restriction against executing inline JavaScript. In particular, setting a script policy that includes unsafe-inline will have no effect. This is intentional.

I am going to look at other templating engines that will hopefully not use the new Function object.

夜声 2025-01-02 03:31:30

我使用 Underscore.js 因为我想要 Backbone.js 作为我的 Chrome 扩展,我刚刚将模板引擎更改为 Mustache ~ 如果您有同样的原因,你也可以使用 Underscore.js 作为 Backbone,只是不要使用 _.template() 函数。

I use Underscore.js because I want Backbone.js for my Chrome extension, I just changed the Template engine to Mustache ~ if you have the same reason, you can also use Underscore.js for Backbone, just do not use _.template() function.

过潦 2025-01-02 03:31:30

如上所述,Manifest v2 限制禁止使用 Eval、新函数和内联脚本 - 即使在使用内容安全策略时也是如此:在 v2 扩展中无法放松此安全策略

大多数模板库在某些时候都会使用 eval。
一种解决方案是重写您的扩展,以便所有逻辑都驻留在 JavaScript 中,而不是模板中的任何内容;在这种情况下,诸如 google jstemplate 之类的解决方案应该可用。

不过,可以选择在 沙盒 iframe,例如清单中包含以下几行:

"sandbox": {
    "pages": [
      "page1.html",
      "directory/page2.html"
    ]
},

沙盒页面将无法访问扩展程序或应用程序 API,或直接访问非沙盒页面(它可以通过 postMessage() 与它们通信)。您可以使用特定的 CSP 进一步限制沙箱权限

现在,Google Chrome 团队在 iframe 中的 github eval 了解如何通过与沙盒 iframe 通信来规避问题,以及 简短的分析教程

希望某些库会使用此机制来提供与标准模板的完全兼容性用法,但出于性能原因,我建议从模板中删除尽可能多的逻辑...

感谢 Google,阵容中有很多扩展重写:(

Manifest v2 limitations, as said above, forbid to use Eval, new Function, and inline scripts - even when playing with the Content Security Policy: there's no way to relax this security policy in v2 extensions.

Most template libraries use, at some point or another, evals.
One solution is to rewrite your extensions so that all logic resides in a javascript, and nothing in a template; a solution such as google jstemplate should in this case be usable.

There's, though, the option to do Eval and new Function inside a sandboxed iframe, for instance with the following lines in the manifest:

"sandbox": {
    "pages": [
      "page1.html",
      "directory/page2.html"
    ]
},

A sandboxed page will not have access to extension or app APIs, or direct access to non-sandboxed pages (it may communicate with them via postMessage()). You can further restrict the sandbox rights with a specific CSP

There's now a full example from the Google Chrome team on the github eval in iframe on how to circumvent the problem by communicating with a sandboxed iframe, as well as a short analytics tutorial

Hopefully some library will show up using this mechanism to provide full compatibility with standard templates usage, though I'd advise removing as much logic from the templates as possible for performance reasons...

Thanks to Google, there's a lot of extension rewriting in the lineup :(

岁吢 2025-01-02 03:31:30

谷歌刚刚发布了一份新文件讨论这个问题的解决方案?

http://code.google.com/chrome/extensions/trunk/sandboxingEval.html

Google just released a new document discussing the solution for this problem ?

http://code.google.com/chrome/extensions/trunk/sandboxingEval.html

云淡风轻 2025-01-02 03:31:30

您可以使用 jQuery 的 $('') 构造编写自己的模板迷你引擎。

干净的方法:

function myElement(text) {
  var d = $('<div class="abc"/>');
  d.text(text);
  return d;
}

myElement('my text').appendTo(domParent);

肮脏的方法:

var yourTemplate = '<div>${somevar}</div>';

function instTemplate(tmpl, text) {
  return $(tmpl.replace(/\$\{somevar\}/g, text));
}

instTemplate(yourTemplate, 'your text').appendTo(domParent);

例如,如果您知道替换数据无害,那么使用脏方法重写简单的 jquery.tmpl 模板非常快。

You can write your own template mini-engine using jQuery's $('<element .../>') construction.

The clean way:

function myElement(text) {
  var d = $('<div class="abc"/>');
  d.text(text);
  return d;
}

myElement('my text').appendTo(domParent);

The dirty way:

var yourTemplate = '<div>${somevar}</div>';

function instTemplate(tmpl, text) {
  return $(tmpl.replace(/\$\{somevar\}/g, text));
}

instTemplate(yourTemplate, 'your text').appendTo(domParent);

E.g. it's pretty quick to rewrite simple jquery.tmpl templates using the dirty method, if you know that the replacement data is not harmful, etc.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文