JavaScript 和 CouchDB - 如何避免 GET/POST/PUT/DELETE 请求上的跨域策略错误
我也在超级用户上发布了这个问题。在我看来，这个问题与两个问题重叠......
我正在为 CouchDB 的 REST 接口创建 一个简单的 JavaScript 包装器，但我陷入了同源策略问题。
到目前为止，我一直在开发在 Mozilla FireFox 上本地工作的代码 - 并且仅作为概念证明。我的服务器在本地主机的端口 5984 上运行。
要在 Mozilla FireFox 中禁用跨域策略，您可以使用 PrivilegeManager，但它只能让我完成一半，因为我无法执行 PUT针对我的服务器的请求...
/*
* Including this in my JavaScript file only seems to disable cross-origin
* policy checks for POST and GET requests in Mozilla FireFox.
* PUT requests fail.
*/
netscape.security.PrivilegeManager.enablePrivilege(
"UniversalBrowserRead UniversalBrowserWrite"
);
有什么方法可以配置我的服务器来隐藏它的位置，这样我就不必实施特定于浏览器的解决方法来避免同源策略问题？如果不是：存在哪些浏览器解决方法可以完全禁用同源策略？
I am posting this question on Super User as well. In my opinion this question overlaps the two...
I am creating a simple JavaScript wrapper for CouchDB's REST-ful interface, but I am stuck on same-origin policy issues.
So far I've been developing my code to work locally - and only as a proof of concept - on Mozilla FireFox. My server is running on localhost, port 5984.
To disable cross-origin policy in Mozilla FireFox you can use the PrivilegeManager, but it only gets me half-way in the sense that I can't do PUT requests against my server...
/*
* Including this in my JavaScript file only seems to disable cross-origin
* policy checks for POST and GET requests in Mozilla FireFox.
* PUT requests fail.
*/
netscape.security.PrivilegeManager.enablePrivilege(
"UniversalBrowserRead UniversalBrowserWrite"
);
Is there any way that I can configure my server to hide it's location so I won't have to implement browser-specific work-arounds to avoid same-origin policy issues? If not: what browser work-arounds exist to disable same-origin policy completely?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不幸的是，任何禁用同源策略的浏览器变通办法都可能被视为严重的安全错误并尽快修复。
看看您是否可以想出一种在同源策略内工作而不试图绕过它的方法。
您可以在目标服务器上提供示例脚本吗？您能否构建一个反射脚本，在用户计算机上的本地脚本上传他们修改的内容后，将目标脚本加载到您的服务器上？
应该有一个不涉及绕过同源策略的好的解决方案。尝试破解它是确保您的代码在未来的浏览器中无法正常工作的好方法。
Unfortunately, any browser workarounds to disable same-origin policies are likely to be treated as serious security bugs and fixed as soon as possible.
See if you can come up with a way to work within the same-origin policy without trying to bypass it.
Can you serve your example scripts on the target server? Could you build a reflection script that would load the target script on your server after a local script on the users computer uploaded whatever they modified?
There should be a good solution that doesn't involve bypassing the same-origin policy. Trying to hack your way around it is a good way to ensure that your code doesn't work properly in future browsers.
我也为这个问题苦苦挣扎，尝试在连接到虚拟化 CouchDB 服务器的本地 html 文件上运行自动化测试，这是我的解决方案：
当您无法启用 CORS 时，我创建了一个最简单解决方案的小型实现（并将其开源）在服务器上，
您需要上传一个 .js 和一个 .html 文件到目标服务器（如果您愿意，您可以使用任何安全机制来限制对此文件的访问）。或者您可以更改 html 文件上的一些简单参数以按域进行限制。
在您的页面上，您使用相同的脚本创建一个不可见的 iframe，其中加载托管的 .html，并使用 window.postMessage() 通过该 iframe 代理某些方法（某种 RPC），默认情况下，可以代理 jQuery ajax 方法，而无需额外的配置。
所有这一切都只需一行 js 代码:)
GitHub 上的 FrameProxy
（可以免费使用并分叉它！）
I strugled with that issue too, trying to run automated tests on a local html file connecting to a virtualized CouchDB server, here's my solution:
I created a small implementation (and open sourced it) of the simplest solution when you can't enable CORS on the server,
you need to upload a .js and an .html file to the target server, (you can use any security mechanism to restrict access to this file if you want). Or you can change some simple parameters on the html file to restrict by domain.
On your page you use the same script to create an invisible iframe where the hosted .html is loaded, and proxy certain methods (sort-of RPC) thru that iframe using window.postMessage(), by default jQuery ajax methods can be proxied without extra configuration.
All this with one line of js code :)
FrameProxy at GitHub
(fell free to use it and fork it!)