views:

140

answers:

2

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!

+2  A: 

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)

saret
Thank you for your answer saret. I've added a clarification on the exact problem I'm dealing with, I don't think it's a serialisation issue, though.
Banang
One thing that seems strange is that going through the reverseproxy your url should be "https://localhost/app/...", this should mean that the browser shouldn't give SOP issues when trying to hit "https://localhost/app/resource?action='doStuffs". At what point in the GWT app does it cause issues - has the app loaded ok prior to this issue?
saret
The app loads up prior to this issue. It arises when I start making calls to the server...
Banang
Try checking if there any urls in the javascript/html that still point to the actual url of the app (http://localhost:8080/MyApp) instead of the reverse proxies url
saret
Nope, everything looks as it should, I'm afraid... :(
Banang
One thing worth trying is to try make sure your urls are relative paths if possible - so you shouldn't really need to use GWT.getModuleBaseURL() then
saret
Yes, it looks as if someone else had the same problem and solved it this way: http://forums.smartclient.com/showthread.php?t=10893
Chris Lercher
@Chris - intresting, not sure why this should happen though, but using relative urls is helpful anyway...can help avoid having to have the server rewrite urls in the page/js@Banang has this helped at all?
saret
Chris and Saret, you two are officially my heroes, that's the trick that made it all tick! Thank you both so, so much! Now, the only issue is - whose answer do I mark as accepted?
Banang
My pleasure, glad I could help
saret
+2  A: 

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.

Chris Lercher
Thank you for your answer. I've been using GWT.getModuleBaseURL(), could this be the issue?
Banang
I'm really a little bit unsure about getModuleBaseURL(). But what I do know is, that it's usually a good idea to configure the application server (which one do you use?) to know about the proxy - so whenever you ask the server to give you the URL, it returns the proxy's public URL. Here's how to do it in [Tomcat 6](http://www.icom2010.org.cn/docs/proxy-howto.html) (see the <Connector> element).
Chris Lercher
Ah, thanks. I'm running Tomcat 6, I'll give it a try right away.
Banang
No, this didn't help. Thanks for the suggestion, though, I really appreciate it.
Banang
It's not a bug in the SmartClient, it's just that you should use absolute URLs that point to the *publicly accessible* proxy, not your internal application or localhost.
Tassos Bassoukos
@Tassos: Yeah, normally this should be the case (that's what we already pointed out). But according to Banang and to [this statement on the smartclient forum](http://forums.smartclient.com/showthread.php?t=10893), SmartClient still complains when using the public URL (I haven't verified this myself). It might be, that SmartClient performs some additional check on absolute URLs to see, if they match the server's own URL (whatever technique it uses to determine that internal URL), and then produces the unnecessary Exception.
Chris Lercher