getXDM 或 JSONP 使用哪一个来规避同源策略

发布于 2024-10-15 18:52:58 字数 911 浏览 5 评论 0原文

我正在创建一个 JavaScript 小部件,它从我托管的 WCF 服务获取大约 4-6KB 的数据,并使用画布标记(HTML5)来绘制一些图表。我希望任何人都能够通过复制粘贴我共享的一些 html 和 JavaScript 来将此小部件嵌入到他们的网站中。

现在的问题是:同源策略,它不允许从小部件的主机域到我域上的 WCF 服务的任何 XHR 请求,这意味着使用该小部件的任何人都无法从我的 WCF 服务获取数据(每个请求都会得到大约 4-6kb 的响应数据)。

我已经完成了之前的讨论这个网站并找到了以下可能的解决方案:

  1. JSONP(可以与我的 WCF 服务一起使用)
  2. 隐藏的 Iframe(不可能,因为我无法控制这两个域)
  3. window.postMessage(不确定是否JavaScript 库可以使其在旧浏览器(即 IE6)中工作)
  4. 跨源资源共享(CORS)(不可能,因为我希望能够运行旧浏览器(即 IE6))
  5. 反向代理方法(不可能,因为我无法控制用户网站的服务器)
  6. easyXDM(可能是一个可能的解决方案,但需要探索如何将它与我的 WCF 服务一起使用)

首先,我想向你们确认,我对可能的不同方法所做的简要分析是正确的,并且我不会错过任何人正在使用的任何出色的解决方案,如果我的分析正确,我想讨论这些方法的优缺点。

其次,我知道 Facebook、Twitter、Google 都分享他们的应用程序(正是我想要分享的方式),并且为此克服了这个问题,任何人都可以为我指出方向,让我可以找到更多关于他们如何分享的信息吗?已经解决了这个问题。

I am creating a JavaScript widget which gets around 4-6KB of data from a WCF service hosted by me and uses canvas tag(HTML5) to draw some charts. I want anybody to be able to embed this widget in their websites by copy pasting some html and JavaScript shared by me.

Now the problem : Same origin policy, it doesn’t allow any XHR request from the host domain of the widget to the WCF service on my domain, which means anyone using the widget cannot get the data from my WCF service(every request will get around 4-6kb of data in response).

I have gone through the previous discussions on this site and found the following possible solutions:

  1. JSONP (can be used with my WCF service)
  2. Hidden Iframes (not possible as i do not have control over both the domains)
  3. window.postMessage (not sure if JavaScript libraries can make it work in old browsers i.e. IE6)
  4. Cross-Origin Resource Sharing (CORS) (not possible as i want to be able to sport old browsers i.e. IE6)
  5. The Reverse Proxy method (not possible as i do not have control over server of the users website)
  6. easyXDM (can be a possible solution but need to explore how to use it with my WCF service)

Firstly I would like to confirm with you guys that the brief analysis done by me of the different approaches possible is correct and i am not missing out on any great solution that anyone is using and if my analysis is correct i would like to discuss the pros and cons of these approaches.

Secondly I know that Facebook, Twitter, Google all of them share their apps (exactly the way I want to share) and have overcome this problem in order to do so, Can anybody point me in the direction where I could find more about how they have solved this problem.

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

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

发布评论

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

评论(1

诺曦 2024-10-22 18:52:58

您需要根据

  • 您的小部件(包括库)可以接受的大小来判断。
  • 您需要轮询服务的频率,或者是否是一次性事件。
  • 完整的浏览器兼容性对您来说有多重要。

对于您描述的特定用例,我会推荐 JSONP。它将使小部件保持非常小,是一个很好的跨浏览器解决方案,并且可以处理适度的数据要求。

谷歌等使用“comet”类型的解决方案,其中类似套接字的流在客户端和服务器之间保留。这不应该用于小部件,因为它会占用浏览器资源。

It's something you need to judge based on

  • How large it's acceptable for your widget to be, including libraries.
  • How frequently you'll need to poll the service, or whether it's a one time event.
  • How important full browser compatibility is to you.

For the specific use case you describe, I would recommend JSONP. It would keep the widget very small, is a good cross browser solution and can handle the modest data requirements.

Google etc use "comet" type solutions, in which a socket like stream is persisted between client and server. This shouldn't be used for widgets as it would hog browser resources.

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