反向代理背后的SOP问题

发布于 2024-09-15 05:27:48 字数 1008 浏览 11 评论 0原文

我花了过去 5 个月的时间开发了一个 gwt 应用程序,现在是第三方人员开始使用它的时候了。为了准备这一点,他们中的一个在反向代理后面设置了我的应用程序,这立即导致了浏览器同源策略的问题。我猜响应标头有问题,但我似乎无法以任何方式重写它们来解决问题。我尝试

response.setHeader("Server", request.getRemoteAddress());

过以某种天真的方式模仿我想要的行为。没有用(没有人感到惊讶)。

任何对此有所了解的人在阅读本文时很可能会窃笑并摇头,我不怪他们。如果是我的话,我也会偷笑……我对此一无所知,这自然使得这个问题很难解决。任何帮助都将不胜感激。

如何使标头重写正常工作并摆脱我正在处理的 SOP 问题?

编辑:我遇到的确切问题是一个弹出窗口:

“SmartClient无法直接联系 网址 'https://localhost/app/resource?action='doStuffs'" 由于浏览器同源策略。 删除主机和端口号(甚至 如果是本地主机)以避免这个问题, 或使用 XJSONDataSource 协议(其中 允许跨站点调用),或使用 服务器端 HttpProxy 包含在 智能客户端服务器。”

但是我不应该需要 smartclient HttpProxy,因为我在服务器顶部有一个代理,应该吗?我没有得到任何迹象表明这可能是序列化问题,但也许这条消息隐藏了真正的信息问题...

解决方案 chris_l 和 saret 都帮助找到了解决方案,但由于我只能标记一个,所以我标记了 chris_l 的答案。我们鼓励读者对他们俩进行点赞,他们真的为我提供了帮助。解决方案非常简单,只需删除服务器的所有绝对路径并仅使用相对路径,这对我来说很有效。谢谢你们!

I've spent the last 5 months developing a gwt app, and it's now become time for third party people to start using it. In preparation for this one of them has set up my app behind a reverse proxy, and this immediately resulted in problems with the browser's same origin policy. I guess there's a problem in the response headers, but I can't seem to rewrite them in any way to make the problem go away. I've tried this

response.setHeader("Server", request.getRemoteAddress());

in some sort of naive attempt to mimic the behaviour I want. Didn't work (to the surprise of no-one).

Anyone knowing anything about this will most likely snicker and shake their heads when reading this, and I do not blame them. I would snicker too, if it was me... I know nothing at all about this, and that naturally makes this problem awfully hard to solve. Any help at all will be greatly appreciated.

How can I get the header rewrite to work and get away from the SOP issues I'm dealing with?

Edit: The exact problem I'm getting is a pop-up saying:

"SmartClient can't directly contact
URL
'https://localhost/app/resource?action='doStuffs'"
due to browser same-origin policy.
Remove the host and port number (even
if localhost) to avoid this problem,
or use XJSONDataSource protocol (which
allows cross-site calls), or use the
server-side HttpProxy included with
SmartClient Server."

But I shouldn't need the smartclient HttpProxy, since I have a proxy on top of the server, should I? I've gotten no indications that this could be a serialisation problem, but maybe this message is hiding the real issue...

Solution
chris_l and saret both helped to find the solution, but since I can only mark one I marked the answer from chris_l. Readers are encouraged to bump them both up, they really came through for me here. The solution was quite simple, just remove any absolute paths to your server and use only relative ones, that did the trick for me. Thanks guys!

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

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

发布评论

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

评论(2

手心的温暖 2024-09-22 05:27:48

当 HTML 页面的 URL 和 URL 时,SOP(针对 AJAX 请求)适用AJAX 请求的不同之处在于它们的“来源”。起源包括主机、端口和协议。

因此,如果页面是 http://www.example.com/index.html,您的 AJAX 请求还必须指向 http://www.example.com 下的内容>。对于 SOP,如果有反向代理并不重要 - 只要确保 URL - 正如浏览器显示的那样(包括端口和协议) - 没有不同。您内部使用的 URL 是无关紧要的 - 但不要在 GWT 应用程序中使用该内部 URL!

注意: SmartClient 特殊情况下的解决方案是使用相对 URL(而不是同源的绝对 URL)。由于相对 URL 不是浏览器中的 SOP 要求,我认为这是 SmartClient 中的一个错误。

The SOP (for AJAX requests) applies, when the URL of the HTML page, and the URL of the AJAX requests differ in their "origin". The origin includes host, port and protocol.

So if the page is http://www.example.com/index.html, your AJAX request must also point to something under http://www.example.com. For the SOP, it doesn't matter, if there is a reverse proxy - just make sure, that the URL - as it appears to the browser (including port and protocol) - isn't different. The URL you use internally is irrelevant - but don't use that internal URL in your GWT app!

Note: The solution in the special case of SmartClient turned out to be using relative URLs (instead of absolute URLs to the same origin). Since relative URLs aren't an SOP requirement in browsers, I'd say that's a bug in SmartClient.

留一抹残留的笑 2024-09-22 05:27:48

您到底遇到了什么问题?

以前必须为 GWT 应用程序编写反向代理,我不记得遇到过任何 SOP 问题,但您需要做的一件事是确保响应标头和 uri 被重写为反向代理 url - 这包括 ajax 回调 url。


在反向代理后面运行时,我遇到的一个问题(您可能也会遇到)是 GWT 服务器的序列化策略。

解决这个问题需要编写 RemoteServiceServlet 的实现。虽然这是 2009 年初/中期的事,但问题似乎仍然存在。

似乎其他人也遇到了这个问题 - 参见了解更多详细信息(特别是 Michele Renda 的回答)

What issue are you having exactly?

Having previously had to write a reverseproxy for a GWT app I can't remember hitting any SOP issues, one thing you need to do though is make sure response headers and uri's are rewritten to the reverseproxies url - this includes ajax callback urls.


One issue I hit (which you might also experience) when running behind a reverseproxy was with the serialization policy of GWT server.

Fixing this required writing an implementation of RemoteServiceServlet. While this was in early/mid 2009, it seems the issue still exists.

Seems like others have hit this as well - see this for further details (the answer by Michele Renda in particular)

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