Overcoming the client "same host" security problem for Ajax debugging?

1 view
Skip to first unread message

Dominique

unread,
Apr 9, 2009, 1:51:54 PM4/9/09
to Google Web Toolkit
I have been very excited about using GWT for developing some client
side code for my Web site but I have hit a wall with the client "same
host" security restriction. My client side code needs to make
extensive calls to the server to get data so I need to be able to
debug this scenario. I've tried the NetBeans IDE and Eclipse and have
found some comments online regarding solutions to this problem in both
environments but I was unable to get either working after a few days
each. Debugging still accesses a different port than 80 which is what
the Ajax calls use. Can anyone point me to concrete steps for how to
setup my environment so I can debug my code when it is running against
my server? Here's what I have:

Windows XP OS
Apache Web server running my Web site, accessed via localhost:80
NetBeans 6.5.1 and Tomcat running localhost
Eclipse 3.4.2 with Cypal plugin
GWT 1.5.3

I am willing to pay someone to help me get this started as I'd really
hate to have to switch to another technology (investigating Yahoo UI
and jScript now).

Dominique

Jeff Chimene

unread,
Apr 9, 2009, 4:40:57 PM4/9/09
to Google-We...@googlegroups.com
Hi,

Are you using the -noserver function? Your setup sounds quite common.
Perhaps I'm missing something...

Tony Strauss

unread,
Apr 9, 2009, 8:20:49 PM4/9/09
to Google Web Toolkit
Just to confirm my understanding, you want to be able to develop/debug
against your production server? I know of several options, depending
on what kind of client server communication you're using. The GWT
team wrote some documentation about this problem:
http://code.google.com/webtoolkit/doc/1.6/FAQ_Server.html#What_is_the_Same_Origin_Policy,_and_how_does_it_affect_GWT?

I think that you will encounter this problem with whichever AJAX
framework you use.

One option is to communicate with the server with JSON (which, because
it can be "imported" through the <script> tag, can evade the same site
origin policy).

Another option is to have a development webserver that proxies
requests to your production server. This blog entry provides some
detail:
http://blog.erace.pl/2009/02/03/apache-proxy-for-gwt-and-alfresco/

Tony
--
Tony Strauss
Designing Patterns, LLC
http://www.designingpatterns.com
http://blogs.designingpatterns.com
Reply all
Reply to author
Forward
0 new messages