Revisiting cross-site requests: CORS and development mode

[Christopher Piggott]

I've been revisiting the cross-site request approaches (currently using JSONP) and tried to search the mailing list for this answer but didn't find it.

Is it possible to modify development mode to send an Access-Control-Allow-Origin header?

A number of "answers" to the question seemed to say "Don't use the built-in server" but that sounds painful.  I like development mode and want to keep it, I am just wondering how to make it send custom headers.

--Chris

[Barop, Johannes]

Hi,

you can use the development mode while dropping the built-in Jetty: See https://developers.google.com/web-toolkit/doc/1.6/FAQ_DebuggingAndCompiling?hl=de#How_do_I_use_my_own_server_in_hosted_mode_instead_of_GWT%27s

But I would try this approch: Install a proxy servlet in the built-in jetty which dispatches all calls to specified backend server.
Now you can easily start the hosted mode against a development or production enviroment.

J.

2012/6/11 Christopher Piggott <cpig...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/MylER2OlcD0J.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--
Johannes Barop - Softwareentwicklung & Beratung
Alsterdorfer Straße 573
DE-22335 Hamburg

E-Mail: j...@barop.de
Tel.: +49 40 807 907 37
Fax : +49 40 807 907 39
Mobil: +49 176 491 551 38

Web: http://www.barop.de

Steuernummer: 49/012/01566
Umsatzsteuer-Identifikationsnummer gemäß §27 a Umsatzsteuergesetz: DE271106292

[Jens]

Couldn't you just create a Servlet Filter that sits in front of your GWT services and let it add that header? You could then use two different web.xml files. The first one for production without the filter and a second one for development that contains the filter definitions.

[Thomas Broyer]

On Monday, June 11, 2012 4:07:57 AM UTC+2, Christopher Piggott wrote:

I've been revisiting the cross-site request approaches (currently using JSONP) and tried to search the mailing list for this answer but didn't find it.

Is it possible to modify development mode to send an Access-Control-Allow-Origin header?

Er, I'm puzzled. If you use Dev Mode's embedded server to serve your data, then you don't hit the SOP, right? and thus you don't need CORS? Or have I missed something obvious?

That being said, you have several solutions:

• configure a servlet filter in your web.xml that adds the header to your responses (clearly the easiest solution)
• copy com.google.gwt.dev.shell.jetty.JettyLauncher and modify it to send the ACAO header, and pass the -server argument to DevMode to use your class.

[Christopher Piggott]

On Monday, June 11, 2012 4:15:04 AM UTC-4, Thomas Broyer wrote:

Er, I'm puzzled. If you use Dev Mode's embedded server to serve your data, then you don't hit the SOP, right? and thus you don't need CORS? Or have I missed something obvious?

Not quite, dev mode's server feeds the application but the data comes from somewhere else.  (It's actually a jersey-guice servlet on my EC2 instance - first year free!)  I want to be able to test the application locally, but using remote data.

Ultimately, one of the things I was trying to determine is whether or not it makes sense to use the same "get data" approach for all cases.  So, for now, I ended up using JSONP for everything.  I don't particularly feel that's ideal, though.  Adding a servlet filter to add the header sounds easy, though.  I'll try that and see how it works out.

[Joseph Lust]

I was writing a new (GWT!) TeamCity plugin Friday for the plasmas around the office used to show each team's build state. Because it cannot use JSONP, I had to use a XHR, but I don't develop on the same machine as the TC server, since the domain and ports would need to match and that would cause conflicts for the dev mode server.

I thus had a similar issue as you mention, needing to get around SOP for dev mode, but not in production (where plugin will be on same server). The solution is to just disable SOP in your dev browser. Sure, I know this is risky, but I have a custom install of Chrome just for this, so I'm not visiting hackzor sites with it.

Chrome: start with --disable-web-security

Safari: start with --disable-web-security

IE: too bad :(

Firefox: Use the Force CORS plugin

OR in FF set the privilege manually, but this will prompt you to confirm

try {
    netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");
} catch (e) {
    alert("UniversalBrowserRead failed");
}

Oh, and for the question "Why not just use JSONP?" the Team City REST API needs an Accept header set to the JSON MIME type or it returns XML. AFAIK you cannot do XML through JsonpRequest. So, given the JsonpRequest is not a true request, but a <script> tag hack, there is no way to set the headers on it like an XHR. I've opened a bug about this, to add a format=[XML|JSON] flag like more API's have for this reason. Vote it up if you've the same issue.

I hope the helps.

Sincerely,

Joseph

[Thomas Broyer]

How about deploying a first "empty" GWT app and then using -noserver?

…or you could use a proxy servlet in DevMode's embedded Jetty, in the line of http://code.google.com/p/google-web-toolkit/issues/detail?id=3131

Much more secure than disabling SOP in the browser ;-)

[Joseph Lust]

Excellent points Thomas.

My point here is that when you're given a few hours to accomplish something and wind up slamming against the SOP, it is easier to just disable it, do your thing, and put it back. Were I to work with the problem I described for a while, I'd look into the proxy or other options, but I just wanted to posit this as a possible temporary work around given that a number of people seem to be running into this.

Of course, I know my suggestion is like noting that your hand gun might fire faster if you take the safety mechanism out. :) Though, in the case of FF prompting to allow cross site access for a page, it is not as dangerous and provides a quick dev workaround.

Joe

[Chris Price]

For dev work like this I find fiddler really useful, it lets you temporarily proxy specific ports paths etc., replace a server script with a locally hosted one and even decrypt https traffic.

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/HDznupahr_AJ.