Driven By Curiosity

Accessing PHP pages for debugging in hosted mode has been an issue mostly confined to those running Linux systems prior to IE7. Now the question comes up for Windows developers as well. I never liked the Tomcat proxy idea since it lends itself to writing code using GWT.isScript(), which I would rather avoid. I like to write code that is identical in testing to its final deployed form. So I wanted to find another solution.

It turns out that IE7 makes it really easy to fix. With some trepidation, I installed the new version (after making a restore point!) and fired it up. Fortunately, in reading around the Microsoft site, I had myself overly worried about what problems I might find. This is what I did:

• On the ‘Security’ tab of the Internet Options dialog, click on the ‘Trusted Sites’ zone.
• Click on the ‘Sites’ button.
• Uncheck the ‘Require server verification…’ box.
• Add "http://localhost" to the sites list and close the sites dialog.
• Making sure you’re still on the Trusted Sites zone, click ‘Custom level…’.
• Scroll down to the miscellaneous section and change ‘Access data sources across domains’ to either Enabled or Prompt (for IE6-type behavior).
• OK your way out of the dialog and you are done.

Making the same changes to the hosted-mode Mozilla on Linux took a lot longer to figure out. I started by installing Linux, if that gives a hint… I’d figured out already how to get FireFox under Windows to let me cross-site script via security policies and figured Linux would be similar. This approach wasn’t quite right for the hosted-mode browser on Linux, so I thought I’d play around with it… I installed Damn Small Linux and ran it via emulation with qemu. Very cool! I messed up a few times in getting everything going and it was delightful to be able to swap and change partitions by just creating some files under windows and running fdisk with impunity under Linux. It took several hours, but I finally got the JDK, eclipse and GWT to all be happy and functional. Time for the real work… But I’ll give you the results instead of the story.

I had to edit {gwt directory}/mozilla-1.7.12/greprefs/all.js (from the GWT 1.2 Linux tarball). Add the following lines to the end:

pref("capability.policy.default.XMLHttpRequest.abort", "allAccess");
pref("capability.policy.default.XMLHttpRequest.getAllResponseHeaders","allAccess");
pref("capability.policy.default.XMLHttpRequest.getResponseHeader","allAccess");
pref("capability.policy.default.XMLHttpRequest.open", "allAccess");
pref("capability.policy.default.XMLHttpRequest.send", "allAccess");
pref("capability.policy.default.XMLHttpRequest.setRequestHeader","allAccess");
pref("capability.policy.default.XMLHttpRequest.onreadystatechange","allAccess");
pref("capability.policy.default.XMLHttpRequest.readyState", "allAccess");
pref("capability.policy.default.XMLHttpRequest.responseText","allAccess");
pref("capability.policy.default.XMLHttpRequest.responseXML","allAccess");
pref("capability.policy.default.XMLHttpRequest.status", "allAccess");
pref("capability.policy.default.XMLHttpRequest.statusText", "allAccess");

This makes it the default policy of the hosted mode browser to allow any XMLHttpRequest call to run. If you don’t like that idea, you could also add the lines above the previous lines:

pref("capability.policy.policynames", "localtest");
pref("capability.policy.localtest.sites", "http://localhost:8888");

Then change all the ‘default’s in the first block to ‘localtest’. This will limit the policy to the Tomcat server address and port. It probably doesn’t matter since this is specific to hosted mode operation and doesn’t apply to FireFox in general. That should do it.

I actually DID add those lines to my user.js of FireFox on Windows (so I can run compiled GWT projects that access remote servers), but they need some modification. First, take the :8888 off of the sites list. Second, all the ‘pref’ calls need to be changed to ‘user_pref’. I would recommend getting the ChromEdit Plus extension (for FF2.0) to make the changes. It simplifies your life. If you aren’t using FF2.0, just get ChromEdit. In this case, I definitely used a restricted site list and didn’t modify the default policy.

So that’s pretty much it. No proxies… Actually, this can be more general than a proxy solution since you aren’t limited by your filter definition. The other big positive (in my opinion, humble of course) is avoiding writing code that depends on being hosted or not. There can be good reasons for doing that, but I would rather avoid it.

The downside is that you will be limited to using absolute URLs in your code. This may or may not matter. I don’t mind it, since I’ve had to do this anyhow. If it was a huge hassle for some reason, I’d put in a JSNI method and pass in a value from PHP like I talked about in a previous posting. Let the server tell me where the code got loaded from. Of course, you’d still have to put SOMETHING in there initially, but it could be overwritten when the page was served.

Probably the biggest hassle of this solution in Linux is that when you update to a new version of GWT, you would have to change all.js again. Another issue could arise if your server sends image URLs to your GWT app for display. These would need to be absolute again, whereas in full deployment they could be relative. This isn’t a big deal to me… A few extra bytes here and there. Presumably, if you use images in your GWT app, putting them in the public directory will make them available to Tomcat, so relative paths are fine both in testing and deployment.

If you find other problems, hate the idea, or can’t get something to work, let me know and I’ll either play around with the problem, or we can email back and forth to get it worked out. This works great for me, but that isn’t always conclusive.

This entry was posted on Monday, January 15th, 2007 at 7:08 pm and is filed under Google Web Toolkit. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.