same-origin security restriction

[Danny]

Hi All,

I finally got round to making my app run in 1.5 and all is looking
good. However I often use hosted mode with remote data, which helps
massively when debugging issues. I am using RequestBuilder.

I'm getting a weird error in 1.5, if I switch back to 1.4 it works
perfectly. I get the following when in hosted mode.

The URL http://x.x.x.x/yyyy.zzz is invalid or violates the same-origin
security restriction

I've enabled cross-brower communication in Internet Explorer and added
the site to my Local Intranet, but still not joy.

Can anyone shed any light on this?

Many thanks,
Danny

[Danny]

Just thought I'd post an update...

I downgraded from 1.5.3 to 1.5.2 and its now working so I guess this
is a bug with 1.5.3.

Regards,
Danny

On Nov 14, 12:40 am, Danny <da...@xrio.co.uk> wrote:
> Hi All,
>
> I finally got round to making my app run in 1.5 and all is looking
> good.  However I often use hosted mode with remote data, which helps
> massively when debugging issues.  I am using RequestBuilder.
>
> I'm getting a weird error in 1.5, if I switch back to 1.4 it works
> perfectly.  I get the following when in hosted mode.
>

> The URLhttp://x.x.x.x/yyyy.zzzis invalid or violates the same-origin

[Sumit Chandel]

Hi Danny,

The issue you ran into is not actually a bug but an improvement in 1.5.3 in terms of browser security compliance.

Basically, the remote data you are fetching is indeed violating the single origin policy, which is why you are seeing the error message come up in the hosted mode console.

The two ways to enable cross-site communication would be to use -noserver with a proxy that could delegate the calls or using the JSONP technique. Both are described in a bit more detail on the Groups post linked below:

http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/48413bdb6e5b292#msg_71f28d8b382e7f04

Hope that helps,
-Sumit Chandel

[jpnet]

This is not a feature! Please fix this. Allow us developers to
violate the SOP via the Hosted-Mode browsers. You are screwing your
developers that don't use J2EE on the backend.

-JP

On Nov 19, 7:33 pm, Sumit Chandel <sumitchan...@google.com> wrote:
> Hi Danny,
>
> The issue you ran into is not actually a bug but an improvement in 1.5.3 in
> terms of browser security compliance.
>
> Basically, the remote data you are fetching is indeed violating the single
> origin policy, which is why you are seeing the error message come up in the
> hosted mode console.
>
> The two ways to enable cross-site communication would be to use -noserver
> with a proxy that could delegate the calls or using the JSONP technique.
> Both are described in a bit more detail on the Groups post linked below:
>

> http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa...

>
> Hope that helps,
> -Sumit Chandel
>
> On Thu, Nov 13, 2008 at 5:05 PM, Danny <da...@xrio.co.uk> wrote:
>
> > Just thought I'd post an update...
>
> > I downgraded from 1.5.3 to 1.5.2 and its now working so I guess this
> > is a bug with 1.5.3.
>
> > Regards,
> > Danny
>
> > On Nov 14, 12:40 am, Danny <da...@xrio.co.uk> wrote:
> > > Hi All,
>
> > > I finally got round to making my app run in 1.5 and all is looking
> > > good.  However I often use hosted mode with remote data, which helps
> > > massively when debugging issues.  I am using RequestBuilder.
>
> > > I'm getting a weird error in 1.5, if I switch back to 1.4 it works
> > > perfectly.  I get the following when in hosted mode.
>

> > > The URLhttp://x.x.x.x/yyyy.zzzisinvalid or violates the same-origin

[Sumit Chandel]

Hi JP,

The SOP violation has to do with browser restrictions rather than server-side technology such as J2EE.

The browser itself enforces single origin policy, which is what prevents cross-site calls to external domains or different ports. The fact that hosted mode permitted calls to different ports prior to 1.5.3 is actually a bug because it allowed non-standard behaviour.

However, it seems like a few community members feel strongly about this change in hosted mode in 1.5.3. The argument is that allowing calls to different ports actually helped speed up the development cycle by allowing shortcuts to setup proxies or makeshift test servers.

I believe the right way to deal with the problem is to use hosted mode with the -noserver argument, as it will allow for custom setups using proxies. However, for those who feel strongly about the change, I would suggest creating an issue report on the Issue Tracker for this feature and starring it for all those interested in seeing it in core. That way it will be on the team's radar if enough people believe it should be an included feature.

Issue Tracker:
http://code.google.com/p/google-web-toolkit/issues/list

Hope that helps,
-Sumit Chandel

[Jason Essington]

Actually, allowing Hosted mode to violate SOP would lead to even more
problems come deployment time...

The idea with hosted mode is that it mirrors an actual browser as
nearly as possible, so by breaking (not fixing) the SOP behavior,
developers are likely to run into issues where something works in
Hosted mode, but doesn't in Web mode. Definitely not desired behavior.

If you have a situation were you need to connect to a serve that is
not well represented by the embedded tomcat server, then simply use -
noserver and be done with it.

I have a JEE backend, and even I have to use -noserver. In fact, I
would be willing to bet anyone that has an application that has
progressed beyond trivial (trial) client/server communication is using
Hosted mode with the -noserver switch. It is not a matter of the GWT
developers trying to screw non-JEE developers, but rather a matter of
not being able to provide an embedded server that is all things to all
people.

-jason

[Brian]

How did I miss this thread? Is there an issue open already for this,
as per the Nov 21st post? I'll star it.

I'm still using 1.5.2 for dev, as it's the fastest way to iterate on a
non-jsonp app. Basically you guys spoiled me with this bug/feature in
prior releases and using 1.5.3 and its slowdown to iterations just
sucks. No offense :)

Anyway, no, it doesn't cause more problems when deploying. You find
out right away when you're running in webmode if you're violating SOP
as the browser complains or ignores the request (depends on the
browser). Violating SOP in hosted mode was a fantastic feature.
Having a console warning in hosted mode that a request is violating
sop should be enough.


On Nov 24, 11:02 am, Jason Essington <jason.essing...@gmail.com>
wrote:

> >>>> The URLhttp://x.x.x.x/yyyy.zzzisinvalidor violates the same-origin

[Brian]

Created issue 3131: (and 13's my lucky number... so close sorta..)

http://code.google.com/p/google-web-toolkit/issues/detail?id=3131

Please star it :-)

> > >>>> The URLhttp://x.x.x.x/yyyy.zzzisinvalidorviolates the same-origin

[andrew_lau]

I got this worked out using apache's reverse proxy module.


Workstation --> apache proxy ---> (rpc call?)
(192.168.2.2) |-- yes --> ejb server
|-- no --> workstation port 8888

Basically, you just need to set up mod_proxy like this:

===============
httpd.conf
==============
ProxyRequests Off
<Proxy *>
Order deny,allow
Deny from all
allow from 192.168
</Proxy>

ProxyPass /mywebmodule/gwt-rpc-service http://ejbserver.com/mywebmodule/gwt-rpc-service
ProxyPassReverse /mywebmodule/gwt-rpc-service http://ejbserver.com/mywebmodule/gwt-rpc-service

ProxyPass /com.mygwtapp.UIModule http://192.168.2.2:8888/com.mygwtapp.UIModule
ProxyPassReverse /com.mygwtapp.UIModule http://192.168.2.2:8888/com.mygwtapp.UIModule

================

Please note that 192.168.2.2 is my workstation where I develop the
code. Thus, when I start hosted mode in that box, the tomcat instance
will listen to port 8888 of my workstation. Thus, this proxy server
will contact the tomcat in my workstation for any queries that has /
com.mygwtapp.UIModule in its path, and will contact my real EJB
server, when the hosted mode browser does rpc call.

This way, it is "clean", the proxy server separate the calls for you.

Here is my hosted mode batch file:
@java -Xmx512M -cp "%~dp0\src;%~dp0\bin;C:/javadev/lib/gwt-windows/gwt-
user.jar;N:/javadev/lib/gwt-maps.jar;C:/javadev/lib/gwt-windows/gwt-
dev-windows.jar" com.google.gwt.dev.GWTShell -out "%~dp0\www" %*
http://theproxyserver/com.mygwtapp.UIModule/UIModule.html -whitelist
"^http[:][/][/]theproxyserver"

> > > >>>> The URLhttp://x.x.x.x/yyyy.zzzisinvalidorviolatesthe same-origin

[andrew_lau]

any queries that has /com.mygwtapp.UIModule in its path, and will

contact my real EJB
server, when the hosted mode browser does rpc call.

This way, it is "clean", the proxy server separate the calls for you.

Here is my hosted mode batch file:
@java -Xmx512M -cp
"%~dp0\src;%~dp0\bin;C:/javadev/lib/gwt-windows/gwt-user.jar;N:/
javadev/lib/gwt-maps.jar;C:/javadev/lib/gwt-windows/gwt-dev-
windows.jar"
com.google.gwt.dev.GWTShell -out "%~dp0\www" %*
http://theproxyserver/com.mygwtapp.UIModule/UIModule.html -whitelist
"^http[:][/][/]theproxyserver"


On Nov 25, 4:12 pm, Brian <hibr...@gmail.com> wrote:

> > > >>>> The URLhttp://x.x.x.x/yyyy.zzzisinvalidorviolatesthe same-origin

[nichol...@yahoo.com]

This is not an improvement and wasting many developers time.

Scott

On Nov 19 2008, 7:33 pm, Sumit Chandel <sumitchan...@google.com>
wrote:

> Hi Danny,
>
> The issue you ran into is not actually a bug but an improvement in 1.5.3 in
> terms of browser security compliance.
>
> Basically, the remote data you are fetching is indeed violating the single
> origin policy, which is why you are seeing the error message come up in the
> hosted mode console.
>
> The two ways to enable cross-site communication would be to use -noserver
> with a proxy that could delegate the calls or using the JSONP technique.
> Both are described in a bit more detail on the Groups post linked below:
>

> http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa...

>
> Hope that helps,
> -Sumit Chandel
>
> On Thu, Nov 13, 2008 at 5:05 PM, Danny <da...@xrio.co.uk> wrote:
>
> > Just thought I'd post an update...
>
> > I downgraded from 1.5.3 to 1.5.2 and its now working so I guess this
> > is a bug with 1.5.3.
>
> > Regards,
> > Danny
>
> > On Nov 14, 12:40 am, Danny <da...@xrio.co.uk> wrote:
> > > Hi All,
>
> > > I finally got round to making my app run in 1.5 and all is looking
> > > good.  However I often use hosted mode with remote data, which helps
> > > massively when debugging issues.  I am using RequestBuilder.
>
> > > I'm getting a weird error in 1.5, if I switch back to 1.4 it works
> > > perfectly.  I get the following when in hosted mode.
>

> > > The URLhttp://x.x.x.x/yyyy.zzzisinvalid or violates the same-origin

[nichol...@yahoo.com]

I don't get the error and why special configuration is needed. This is
truly wasting many developers time. I'm able to access the local URL
anywhere except in GWT hosted mode. It works fine from other browsers
and scripts.

On Nov 19 2008, 7:33 pm, Sumit Chandel <sumitchan...@google.com>
wrote:

> Hi Danny,
>
> The issue you ran into is not actually a bug but an improvement in 1.5.3 in
> terms of browser security compliance.
>
> Basically, the remote data you are fetching is indeed violating the single
> origin policy, which is why you are seeing the error message come up in the
> hosted mode console.
>
> The two ways to enable cross-site communication would be to use -noserver
> with a proxy that could delegate the calls or using the JSONP technique.
> Both are described in a bit more detail on the Groups post linked below:
>

> http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa...

>
> Hope that helps,
> -Sumit Chandel
>
> On Thu, Nov 13, 2008 at 5:05 PM, Danny <da...@xrio.co.uk> wrote:
>
> > Just thought I'd post an update...
>
> > I downgraded from 1.5.3 to 1.5.2 and its now working so I guess this
> > is a bug with 1.5.3.
>
> > Regards,
> > Danny
>
> > On Nov 14, 12:40 am, Danny <da...@xrio.co.uk> wrote:
> > > Hi All,
>
> > > I finally got round to making my app run in 1.5 and all is looking
> > > good.  However I often use hosted mode with remote data, which helps
> > > massively when debugging issues.  I am using RequestBuilder.
>
> > > I'm getting a weird error in 1.5, if I switch back to 1.4 it works
> > > perfectly.  I get the following when in hosted mode.
>

> > > The URLhttp://x.x.x.x/yyyy.zzzisinvalid or violates the same-origin

[Scooter]

Please allow this to either be a configurable option or a prompt when
accessing external URL. I test against a variety of complex data
sources for our web server where duplicating on my development machine
is almost impossible. It is also an issue when we get a bug report in
production that I can point to the appropriate web server and debug
the problem. I can't upgrade to the latest 1.5 and really want to
avoid the proxy overhead.

[nichol...@yahoo.com]

The light bulb finally lit for me. There's browser security rules in
place that only allow Ajax to communicate with the same server as the
main page. If GWT hosted mode allowed it then in the future when you
deployed to production your app wouldn't work. I'm going to change my
implementation to have the external data sources route through the
server, but may need to add load balancing because of the extra load
now on the server. Nothings ever to easy.

[Sumit Chandel]

Hello sjn456,

You're completely right. That's precisely why the previous behaviour was corrected. It's browser security policies that restrict making calls to other domains or ports. If we allowed these in hosted mode, we would be setting developers up for a break once they go to production. What's more, I believe the new corrected behaviour is the result of an update to the latest XHR spec on supported browsers, meaning that allowing calls to go through to other ports would mean drawing back to older XHRs.

Cheers,
-Sumit Chandel

[Scooter]

You assume that I need someone to put constraints on a development
tool that will protect me. I do not need the protection and promise
not to complain if I somehow release code that doesn't work in the web
browser versus what I need to test in debug mode.

It is also reasonable to make the default option to not allow the
behavior but give the developer the ability to configure this as an
option for testing purposes. .

We are talking about a development tool that is hard wired to
debugging "Java" code that will get converted to Javascript where the
innovation step is to allow the developer to be more productive prior
to deploying to javascript and running in a web browser.

Sun provides the applet viewer for exactly this reason to allow the
developer to write and debug applet code before adding the complexity
and overhead of security models that are designed to protect the end
user not the developer.

Please understand the difference between hosted mode as a debug/
productivity tool used by developers and a web browser used by end
users. I know you do I am just trying to make the point that all
developers understand the difference.

You actually create a situation where I will end up deploying
applications that have more bugs because of the complexity of our
production environment and size of data sets that makes it difficult
to reproduce on a development machine. This means code does not get
tested as well prior to moving into production which results in a
higher number of defects and longer development cycles.

It sounds like you have already decided that even though you have
numerous requests in this thread to relax the restriction it is not
going to happen. Should this discussion be moved over to the developer
group or has it already been discussed? Is the tighter security
restriction part of a google developed application tool or something
used from an external open source tool? Just curious what triggered
the change in a minor release of 1.5.2 to 1.5.3 and how hard it would
be to relax the restriction as a config option.

Thanks

Scooter

On Jan 9, 6:17 pm, Sumit Chandel <sumitchan...@google.com> wrote:
> Hello sjn456,
>
> You're completely right. That's precisely why the previous behaviour was
> corrected. It's browser security policies that restrict making calls to
> other domains or ports. If we allowed these in hosted mode, we would be
> setting developers up for a break once they go to production. What's more, I
> believe the new corrected behaviour is the result of an update to the latest
> XHR spec on supported browsers, meaning that allowing calls to go through to
> other ports would mean drawing back to older XHRs.
>
> Cheers,
> -Sumit Chandel
>

[vladimir....@gmail.com]

I think I found the solution!

!!!!!Please somebody check this!!!!!

Steps:
1. run InternetExplorer

Tools => Internet Options => Security => Trusted Sites
add http://localhost or so to trusted sites (uncheck "add only https"
or so)
works only with Windows XP.

best regards,
Vladimir Chernishov

[DavidPShaw]

has there been any update on this problem? I have a PHP backend
exposed via JSON, and want to develop using hosted mode. Is this
simply impossible without tricky proxy stuff in apache? My backend
cannot run in hosted mode, so I basically have no way to do step-
through debugging.

[Thomas Broyer]

You have two solutions:
- use the -noserver mode (requires that your deploy your app *once*,
and then you're required to deploy needed resources: images --
including imagebundles--, stylesheets, etc.)
- use a proxy-servlet in the hosted mode embedded Tomcat to route all
requests to your other server (no need for this "tricky proxy stuff in
apache"), see http://code.google.com/p/google-web-toolkit/issues/detail?id=3131#c11
and following comments.

[Jason Essington]

Your case is simple, just use the -noserver option to launch hosted
mode, and load your host page directly from your [test] php server.

The embedded tomcat server is really only useful for testing the
simplest of java back-end bits, and is not particularly useful for any
other back-end technology or even more complicated Java configurations.

-jason

[sajjan]

Our application uses GWT to create complex UIs but the data is served up by a Coldfusion web server running externally on a different domain.

The code works fine when compiled and deployed in the same domain as the Coldfusion server but gives this error when running in hosted mode when trying to make a Cross Domain AJAX request.

After much research,changing the Security Level to Medium-Low in the Local Intranet zone in IE fixed it for me.

Just leaving this here in case someone walks this path :)

After much research,changing the Security Level to Medium-Low in the Local Intranet zone in IE fixed it for me.