【问题标题】:JavaScript: "Uncaught SecurityError" when running JS-XSL demo locallyJavaScript:在本地运行 JS-XSL 演示时出现“Uncaught SecurityError”
【发布时间】:2016-02-06 01:10:13
【问题描述】:

(这个问题与here找到的JS-XSL演示有关)

简单地告诉你这个演示是做什么的;它以 MS Excel 文件作为输入,解析数据,并以纯文本格式输出数据。我下载了包(zip)并在本地运行它,只需用 Chrome 打开 html 文件。

问题是,我似乎无法克服以下错误:

Uncaught SecurityError: Failed to construct 'Worker': Script at 'file:///C:/Users/David/Desktop/Xlsx%20Demo/xlsworker.js' cannot be accessed from origin 'null'.

上面的错误指向html文件的第34行,代码如下:

/* I changed the file path from './xlsworker.js' to 'xlsworker.js' */
var worker = new Worker('xlsworker.js');

此演示只有三个文件:html 文件本身和两个 javascript 文件,一个名为 xls.js,另一个名为 xlsworker.js。所有三个文件都在同一目录和同一级别。

让我感到困惑的是,我在大约几个月前成功运行了同样的演示!我无法想象我现在是否正在做不同的事情。有什么见解吗?

【问题讨论】:

  • 你可能需要一个服务器来运行它。
  • @mpm - 这一定是原因;我让它再次运行。谢谢!

标签: javascript excel parsing


【解决方案1】:

https://code.google.com/p/chromium/issues/detail?id=278883#c9

Chromium 基本上阻止您在 file:// 协议上使用工作人员,您必须托管文件并通过 http:// 协议访问它们。

你需要一个服务器(甚至像http://docs.python.org/2/library/simplehttpserver.html这样简单的东西)

【讨论】:

  • 谢谢,尼尔克。我去看看链接。
【解决方案2】:

IMO,以下是一个很好的答案,因为它不需要运行网络服务器。它非常快速和简单。

(在我的注释 5 中解释了反对票)

我已经测试并验证,当按照提问者的描述在本地运行时,此解决方案可以与提问者链接的演示一起使用。在 Windows 10、Chrome 稳定版 x64 48.0.2564.103 m 上测试。

不允许脚本访问 Chrome 中的本地文件系统。如果您想在本地测试网络工作者,您必须使用特殊标志打开 Chrome。

在 Windows 上,启动带有标志的 chrome:

chrome.exe --allow-file-access-from-files

之后,Chrome 将启动,您可以在此会话期间测试工作人员。

注意 1:如果运行此命令时 Chrome 已经在运行,则新的 Chrome 实例将不允许运行 Workers——你必须先退出 Chrome(如有必要,使用 Windows 任务管理器以确保 Chrome 未运行)。

注 2:此答案的来源(下面的链接)包括 Windows 上的 --args 标志,但我没有发现 Windows 上需要“args”。事实上,我在任何地方都找不到“args”标志的任何文档——不确定它的作用。所以我没有将它包含在上面的 Windows 命令中。*

注意 3:对于那些试图在 Chrome-Mac 或 Windows-Firefox 上做类似事情的人,下面的链接包括两者,以及上面的 Windows-Chrome 解决方案。但我上面描述的解决方案只是 Windows-Chrome 方法。

http://js-workout.tompascall.com/web-workers-and-responsiveness/

注意 4:请注意,此解决方案与运行 Web 服务器不同,但就您的目的而言,它应该是一个完全足够的解决方案。另外,请注意,在启用此 chrome 启动开关的情况下浏览网页可能会损害您的本地文件安全性,因此建议仅将此方法用于您的本地文件目的,并将其禁用以进行网页浏览。*

注意 5:Google 声明使用启动标志“应仅用于临时情况,将来可能会中断”。对 chrome 启动开关的网络搜索返回了大约 2,000 次点击,因此很多人使用它们并在博客中介绍它们。如果您的需求是暂时的,那么这目前非常有效。*

【讨论】:

  • 建议不支持的命令行标志和about:config 更改不是一个好建议。 file:// URL 可以表现出普通 http://https:// URL 所没有的各种行为差异,因此正确的方法是使用本地 Web 服务器。
  • 另请注意,--incognito 在任何方面都不是更安全,它不像普通的 Chrome 实例那样被沙盒化。它根本不保存 cookie、历史记录和本地数据。那不是“安全的”,它只是“私人的”。
  • “建议不支持的命令行标志和 about:config 更改不是一个好建议....隐身不是更安全”我没有提出上述任何建议。
  • --allow-file-access-from-files 是不受支持的命令行标志。 security.fileuri.strict_origin_policy 是一个 about:config 条目。 --incognito 是关于您提交的另一篇文章(我拒绝了,因为与该 Google 组无关),我承认。 :)
  • "--allow-file-access-from-files 是一个不受支持的命令行标志。" **你怎么知道它“不受支持”? “security.fileuri.strict_origin_policy 是 about:config 条目。” **我没有说 security.fileuri.strict_origin_policy,也没有说任何其他 about:config。 about:config 有什么问题?提问者是开发环境中的程序员,而不是最终用户。 “--incognito 是关于你提交的另一篇文章(我拒绝了,因为与该 Google 群组无关),我承认。” **根据我在其他地方发布的内容在这里抱怨和投反对票是非法的。
猜你喜欢
  • 2014-08-29
  • 2019-10-03
  • 1970-01-01
  • 2023-03-20
  • 1970-01-01
  • 1970-01-01
  • 2014-11-25
  • 2015-02-19
相关资源
最近更新 更多