Thanks omicron. I have enabled the cross Domain property and saw some
interesting behavior that led me to believe that web2py needed
additional configuration. This post and additional investigation have
reversed my opinion.
I am using qooxdoo-0.8.3 . I found the following:
web server / json-rpc service host = server.domain.com / server
client resolves to client.domain.com (they are both in the same domain)
1.
-------
setting
var rpc = new
qx.io.remote.Rpc("http://server.domain.com/app/controller/call/jsonrpc";);
rpc.setCrossDomain(false);
- connecting to http://server/qxapp/source from the client produces
"Transport error 0: Unknown status code"
- connecting to http://server/qxapp/source from the server produces
"Transport error 0: Unknown status code"
- connecting to http://server.domain.com/qxapp/source from the client
produces a positive response from the service
- connecting to http://server.domain.com/qxapp/source from the server
produces a positive response from the service
2.
-------
setting
var rpc = new qx.io.remote.Rpc("http://server/app/controller/call/jsonrpc";);
rpc.setCrossDomain(false);
- connecting to http://server/qxapp/source from the client produces
"Local error 1: Local time-out expired"
- connecting to http://server/qxapp/source from the server produces
"Local error 1: Local time-out expired"
- connecting to http://server.domain.com/qxapp/source from the client
produces "Transport error 0: Unknown status code"
- connecting to http://server.domain.com/qxapp/source from the server
produces "Transport error 0: Unknown status code"
3.
-------
setting
var rpc = new
qx.io.remote.Rpc("http://server.domain.com/app/controller/call/jsonrpc";);
rpc.setCrossDomain(true);
- connecting to http://server/qxapp/source from the client produces
"Local error 1: Local time-out expired"
- connecting to http://server/qxapp/source from the server produces
"Local error 1: Local time-out expired"
- connecting to http://server.domain.com/qxapp/source from the client
produces "Local error 1: Local time-out expired"
- connecting to http://server.domain.com/qxapp/source from the server
produces "Local error 1: Local time-out expired"
4.
-------
setting
var rpc = new qx.io.remote.Rpc("http://server/app/controller/call/jsonrpc";);
rpc.setCrossDomain(true);
- connecting to http://server/qxapp/source from the client produces
"Local error 1: Local time-out expired"
- connecting to http://server/qxapp/source from the server produces
"Local error 1: Local time-out expired"
- connecting to http://server.domain.com/qxapp/source from the client
produces "Local error 1: Local time-out expired"
- connecting to http://server.domain.com/qxapp/source from the server
produces "Local error 1: Local time-out expired"
5.
-------
setting
var rpc = new qx.io.remote.Rpc("http://server/app/controller/call/jsonrpc";);
** do not call rpc.setCrossDomain()
- connecting to http://server/qxapp/source from the client produces a
positive response from the service
- connecting to http://server/qxapp/source from the server produces a
positive response from the service
- connecting to http://server.domain.com/qxapp/source from the client
produces "Transport error 0: Unknown status code"
- connecting to http://server.domain.com/qxapp/source from the server
produces "Transport error 0: Unknown status code"
6.
-------
setting
var rpc = new
qx.io.remote.Rpc("http://server.domain.com/app/controller/call/jsonrpc";);
** do not call rpc.setCrossDomain()
- connecting to http://server/qxapp/source from the client produces
"Transport error 0: Unknown status code"
- connecting to http://server/qxapp/source from the server produces
"Transport error 0: Unknown status code"
- connecting to http://server.domain.com/qxapp/source from the client
produces a positive response from the service
- connecting to http://server.domain.com/qxapp/source from the server
produces a positive response from the service
I would think that at the very least, running the code from the server
would always produce positive results. That does not appear to be the
case, at least in my setup.
On Fri, Oct 23, 2009 at 10:10 AM, omicron <jacques.bouss...@gmail.com> wrote:
>
> I'm using QooxDoo / Web2Py with JSonRpc in several applications and
> don't need special features in Web2py. If you want crossdomain feature
> in QooxDoo you must set the crossDomain property to true:
> var rpc = new qx.io.remote.Rpc("http://targetdomain.com/appname/
> function/call/jsonrpc");
> rpc.setCrossDomain(true);
>
> On 23 oct, 16:01, Don Lee <sam...@gmail.com> wrote:
>> I do not need cross domain call blocking. But I guess it would be a
>> good feature to have. I am experiencing a problem with qooxdoo's
>> cross domain call setup, and I wanted to make sure there wasn't
>> something within web2py that I should configure as well. Now I have
>> to go and gather some data so that I can bug the qooxdoo mailing list
>> . Thanks for the help.
>>
>> On Fri, Oct 23, 2009 at 9:48 AM, mdipierro <mdipie...@cs.depaul.edu> wrote:
>>
>> > There is nothing in the JSONRPC to do it but you can block those calls
>> > from outside using routes. It is not that user friendly. Let me think
>> > about this. If poeple have any idea let me know.
>>
>> > On Oct 23, 8:24 am, Don Lee <sam...@gmail.com> wrote:
>> >> Is there anything within web2py's json-rpc implementation that would
>> >> prevent cross domain calls?
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
