Javascript 托管JS文件的Three.JS、Amazon S3和访问控制源错误 背景

我们使用Javascript库Three.JS来可视化存储在AmazonS3上的模型

我的所有模型都使用JSONLoader。其他格式缺乏我们团队所需的工具链支持，而像COLLADA或OBJ这样的常见格式似乎是二等公民，因为所包含的加载程序库（例如，它们可以在“示例”下的源代码树中找到……JSONLoader在core loaders文件夹中）

我有大型模型文件，所以将它们及其相关资产存储在AmazonS3存储上，那里的带宽和空间相对便宜。其目的是使用Three.JS的web应用程序从Amazon上的存储中加载模型，一切正常

问题 不幸的是，这些模型是Javascript文件（“modelBlah.js”，例如），当JSONLoader加载它们时，任何理智的浏览器都会立即抱怨我们违反了脚本的同源策略——例如，我们正在加载并试图评估来自不同域的脚本，而不是调用脚本（这是应用程序的主线束）

因此，我们似乎已经面临多年的web安全最佳实践

迄今为止研究的解决方案

• 我们自己主持模型？我们现在正在使用Heroku，理想情况下，我们希望使用一种专门被称为“大容量比特和带宽”的服务，而不是自己做

• 使用DNAME记录欺骗资源的来源？不幸的是，这似乎不足以欺骗浏览器，因为用于媒体托管的子域仍然会激怒浏览器的安全性

• 使用CORS，特别是Access Control Allow Origin Header？对Amazon S3的简要浏览似乎不允许这样做，尽管我希望我弄错了。即使如此，这是否足够

---

---

有什么想法吗？

你肯定需要CORS，我认为S3允许。否则，这个周末我不得不在谷歌的云存储上安装一个启用CORS的存储桶，这相当简单（使用gsutil）.

S3还不允许您设置CORs。为了解决这个确切的问题，我运行了一个EC2实例作为下载模型的代理服务器。代理（当前仅运行节点）从S3获取文件，设置CORs头并将其传递给应用程序。节点设置有很多选项，包括knox或bufferjs。

现在您终于可以在Amazon上使用CORs了：