On Sat, Oct 24, 2009 at 1:54 AM, Gene Amtower <g...@pc-backup.com> wrote:
> Don,
>
> You sounded confused by the results of your testing, and I was trying to
> show you where there is correlation between your test results and the
> Qooxdoo RPC framework. It sounds like you still don't agree that there is
> some order to your results - that somehow the behavior is still unexpected.
> I think I provided you with some explanations for how your results are not
> entirely unexpected.
Thanks.
> To be clear, I pulled all of your test instances and scenarios out of the
> email and arranged them in a spreadsheet to be able to see these
> "relationships" more clearly, and this told me that when the page URL
> matched the RPC url in your tests, your setup worked correctly, except when
> you set cross-Domain to TRUE (when it wasn't necessary). When the URLs
> didn't match and cross-Domain was FALSE (8 of your test cases), it failed
> because those instances could not be run as non-crossDomain requests due to
> the mismatched URLs - they must be letter-for-letter identical, not just
> equivalent in your DNS system. So, I think I explained why eight of your
> tests failed and why you got six successful results - do you at least agree
> with that?
Agreed.
> So, we know there are scenarios in your testing that worked correctly. As
> for the two failures in Test section #2, I was suggesting that in running 24
> different tests, you might have accidentally run a couple of them with the
> wrong line of code in place, as I suspect the first two instances in Test
> section #2, which returned "Unknown Status code" should have matched results
> from the first two instances in Test section #5, where you DID get a good
> response - everything about these two different test scenarios is identical,
> so the results should have also been identical. It seems to me that those
> four results are definitely anomalous results in your testing and might
> deserve to be repeated for confirmation. Do you agree with that?
Agreed, and I will repeat the tests later today to confirm the results.
> Obviously, something is not working correctly for you with cross-domain
> requests, and I suspect it has something to do with the fact that this
> forces a different transport mode for the request. But, do you intend on
> serving a Qooxdoo application from one server that accesses the RPC backend
> on a different server? You haven't really made that clear. If they always
> reside on the same server, then just make sure you form the RPC url based on
> the webpage URL, and it should work fine. In this case, don't worry about
> why cross-Domain requests aren't working.
The webserver and RPC backend are running on the same machine. I have
to go and read through the docs for qx.io.remote.transport.Script. I
wanted to fully understand what is going on so that I can prepare
usage/debugging/troubleshooting procedures for our users.
> If you really need to serve the RPC from a different URL address, then you
> will need to work out the cross-Domain transport issue. From your
> statements, it appears that your web2py backend may not be a factor in your
> failures for cross-Domain RPC calls, but I can't confirm that for you. If
> you trust the web2py ML answers, then maybe that's true. However, I'm not
> at all familiar with web2py to give you any additional insight into why
> cross-Domain requests are not working. I'm hoping someone else on the ML
> can shed more light from their own experience with web2py. Anyone else care
> to chime in here?
I trust the answers, the web2py developer answered my question.
> You may have to do more reading to understand Script Transport versus
> XMLHttp transport mechanisms, which is what IS DIFFERENT when you try to
> make the RPC call as a cross-domain request. It's obvious to me that this
> deserves a closer look - if you really need to use cross-Domain requests.
> Keep in mind that implementing cross-Domain requests comes with additional
> security compromises, but if you must use them, then you'll have to work
> through this issue. I have not had the pleasure of digging this deeply
> myself, but hopefully Derrell or others on the ML can shed more light on the
> key differences in the transports that might be responsible for your
> failures.
Yep, I have more reading to do :)
> Again, I don't know enough about web2py to help solve the cross-Domain
> issue, but I hope I've clarified why I think your tests are actually useful
> AND consistent, which seemed to be your original question.
Yes, thanks.
> See below for one additional comment relative to your client versus server
> testing and some FQDN thoughts.
see my reply below. Thank you for your responses. They have been very helpful
> Best regards,
>
> Gene
>
>
> On Fri, 2009-10-23 at 23:17 -0400, Don Lee wrote:
>
> First let me say thank you for your response to my question. I will
> reply to each section.
>
> On Fri, Oct 23, 2009 at 7:39 PM, Gene Amtower <g...@pc-backup.com> wrote:
>> Don,
>>
>> First, I think there's a misunderstanding about what crossDomain means -
>> it
>> does not refer to a "domain" in the sense of a domain name or network
>> domain. It is just used here to refer to a request to a different RPC URL
>> than the source page that makes the RPC request. Since you mentioned that
>> the client is in the same network domain as the server, it appears you may
>> have misinterpreted this terminology.
>
>
> I actually understood this point. My intention in stating the FQDN of
> my systems was that whether or not crossDomain was enabled, the
> requests made from the server should have worked.
>
> I think it should be clear from your testing that the results didn't matter
> whether you opened it in a browser on your client or a browser on your
> server - in each pair of test cases (client versus server), the results were
> identical between them. In each case, the rules for RPC calls are still the
> same. Keep in mind that even when you open it in a browser on the server,
> that it's still acting like a client, even if the communication loop is a
> very small loop internal to the server. All the same limitations apply to
> browser scripting in that case. So, don't think that just because the
> browser window is on the same machine as the server instance that it changes
> the rules - the Qooxdoo framework is not so smart that it can bypass basic
> browser security limitations. And finally, enabling the cross-Domain
> property FORCES a different transport method, even if it wasn't warranted in
> that instance. Maybe you're over-complicating the situation.
I did not understand this to be the case. I thought that running the
browser from the server would be seen as a local request no matter
what unless server.domain.com and server would both have to be
specified in /etc/hosts as pointing to localhost. hmmm... This was
what caused me to think that something unexpected was going on. I
thought that running the web server, browser, and rpc backend on a
single system would always provide positive results, and that was not
the case.
> One additional comment relative to the FQDN versus NetBios name in your
> requests - it would seem that you are only developing apps for use within an
> Intranet environment; otherwise, using NetBios names in URLs doesn't make
> much sense for the web. However, even in Intranet situations, I always
> develop for FQDN URLs - maybe I just don't trust NetBios naming to always
> work correctly. However, if you're developing applications for the web, why
> are you doing any work with NetBios names?
>
I was not referring to NetBios names. It is more like FQDN and short
machine names. They all resolve properly via DNS. Some of the
clients are linux systems and NetBIOS is not an available name
resolution system. Some of the users will be lazy and not want to use
the FQDN.
>
>> Also, when you don't set crossDomain explicitly, it defaults to FALSE in
>> the
>> implementation of qx.io.remote.RPC. So, I would expect your requests with
>> it set to FALSE to have the same result as your requests where you didn't
>> set it at all. In fact, they are the same between these two scenarios in
>> all except 4 of your tests in sections 2 & 5 - where your request came
>> from
>> //server and your rpc call went to //server. Since you didn't show any
>> code
>> from your app or remote service, it's not clear why these scenarios would
>> be
>> different - Setting crossDomain to FALSE and not setting it at all should
>> have yielded the same result between #1, 2, 5, & 6. Maybe you made a
>> mistake somewhere in your testing, and these scenarios really would have
>> had
>> the same result if done as you stated.
>
> [ -------------------------------------------- | Begin QooxDoo Code |
> -------------------------------------------- ]
> // Create a button
> var button1 = new qx.ui.form.Button("Submit");
>
> // create a text field to hold the e-mail address
> var emailField = new qx.ui.form.TextField();
> emailField.setWidth(140);
> var emailLabel = new qx.ui.basic.Label("e-mail address:");
>
> // setup rpc class
> var rpc = new qx.io.remote.Rpc();
> rpc.setTimeout(10000);
> rpc.setUrl("http://server.domain.com/app/controller/call/jsonrpc";);
> rpc.setServiceName("");
>
> // asynchronous call
> var handler = function(result, exc, id) {
> if (exc == null) {
> alert("Result of async call: " + result);
> } else {
> alert("Exception during async call: " + exc);
> }
> };
>
> // Document is the application root
> var doc = this.getRoot();
>
> // Add button to document at fixed coordinates
> doc.add(button1, {left: 100, top: 50});
> // Add email field to document root
> doc.add(emailLabel, {left: 100, top: 0});
> doc.add(emailField,{left: 175, top: 0});
>
> // Add an event listener
> button1.addListener("execute", function(e) {
> // asynchronous call
> rpc.callAsync(handler, "search", emailField.getValue());
> //rpc.callAsync(handler, "echo", "Test");
>
> [ -------------------------------------------- | End QooxDoo Code |
> -------------------------------------------- ]
>
> [ -------------------------------------------- | Begin Web2py Code |
> -------------------------------------------- ]
> import ldap
>
> server='ldap.domain.com'
> base_dn='ou=ldap,o=domain.com'
> search='mail'
>
> def index():
> redirect(URL(r=request,f='searchApp'))
>
> def searchApp():
> return dict()
>
> def call():
> # remove session.forget() if you want to use session cookies for
> services
> session.forget()
> return service()
>
> @service.jsonrpc
> def search(email="d...@domain.com"):
> dn = None
> search = 'email'
> filter = '('+search+'='+email+')'
> attrs = ['uid']
>
> con = ldap.initialize("ldaps://" + server + ":" + "636")
>
> result=con.search_s(base_dn, ldap.SCOPE_SUBTREE, filter)
> dn=result[0][0]
> return dn
>
>
> @service.jsonrpc
> def echo(msg):
> return msg
> [ -------------------------------------------- | End Web2py Code |
> -------------------------------------------- ]
>
>
> This app creates two callable service functions: echo(), and search().
> Echo simply returns what was sent to it. Search searches the ldap
> server and returns the distinguished name (dn). I have tested this
> from the python shell using jsonrpclib on both the server itself and
> on other machines. It worked.
>
>
> [ -------------------------------------------- | Begin Python Shell |
> -------------------------------------------- ]
> Python 2.4.3 (#1, Jul 27 2009, 17:56:30)
> [GCC 4.1.2 20080704 (Red Hat 4.1.2-44)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import jsonrpclib
>>>> rpc =
>>>> jsonrpclib.ServerProxy("http://server.com/app/controller/call/jsonrpc";,
>>>> verbose=1)
>>>> print rpc.echo("Hello World!!")
> connect: (server, 80)
> send: 'POST /app/controller/call/jsonrpc HTTP/1.0\r\nHost:
> server\r\nUser-Agent: jsonlib.py/0.0.1 (by matt
> harrison)\r\nContent-Type: text/xml\r\nContent-Length: 56\r\n\r\n'
> send: '{"params": ["Hello World!!"], "method": "echo", "id": 3}'
> reply: 'HTTP/1.1 200 OK\r\n'
> header: Date: Sat, 24 Oct 2009 03:02:22 GMT
> header: Server: Apache/2.2.3 (Red Hat)
> header: Expires: Sat, 24 Oct 2009 03:02:22 GMT
> header: Pragma: no-cache
> header: Cache-Control: no-store, no-cache, must-revalidate,
> post-check=0, pre-check=0
> header: Set-Cookie:
> session_id_app=IP-89-8be806cc-e740-4f31-85da-500e9b45e7a1; Path=/
> header: Connection: close
> header: Content-Type: text/html; charset=UTF-8
> body: '{"error": null, "version": "1.1", "id": 3, "result": "Hello
> World!!"}'
> {u'result': u'Hello World!!', u'version': u'1.1', u'id': 3, u'error': None}
>>>>
>>>>
>>>>
>>>>
>>>> print rpc.search("d...@domain.com")
> connect: (server.domain.com, 80)
> send: 'POST /app/controller/call/jsonrpc HTTP/1.0\r\nHost:
> server.domain.com\r\nUser-Agent: jsonlib.py/0.0.1 (by matt
> harrison)\r\nContent-Type: text/xml\r\nContent-Length: 63\r\n\r\n'
> send: '{"params": ["d...@domain.com"], "method": "search", "id": 5}'
> reply: 'HTTP/1.1 200 OK\r\n'
> header: Date: Sat, 24 Oct 2009 03:06:00 GMT
> header: Server: Apache/2.2.3 (Red Hat)
> header: Expires: Sat, 24 Oct 2009 03:06:00 GMT
> header: Pragma: no-cache
> header: Cache-Control: no-store, no-cache, must-revalidate,
> post-check=0, pre-check=0
> header: Set-Cookie:
> session_id_app=IP-89c94dbe-9609-4c0e-96c5-fb47f5f450a2; Path=/
> header: Connection: close
> header: Content-Type: text/html; charset=UTF-8
> body: '{"error": null, "version": "1.1", "id": 5, "result":
> "uid=X-XXXXXXX,c=uk,ou=ldap,o=domain.com"}'
> {u'result': u'uid=X-XXXXXXX,c=uk,ou=ldap,o=domain.com', u'version':
> u'1.1', u'id': 5, u'error': None}
>>>>
>
> [ -------------------------------------------- | End Python Shell |
> -------------------------------------------- ]
>
>
>> In summary, when you access a page at one URL and request an RPC service
>> at
>> a different URL, you are going to need to set crossDomain to true. This
>> is
>> likely why eight of your requests came back as "Unknown Status code",
>> since
>> these were all cases where the page URL did NOT match the RPC URL and you
>> essentially had crossDomain set to FALSE (half by setting it to FALSE and
>> half by leaving it at the default of FALSE).
>>
>> Secondly, you didn't mention how your RPC server is configured. In the
>> case
>> of RPC-PHP, the RPC server is configured by default to only allow
>> non-cross-domain requests. If you haven't checked this setting, then this
>> would explain why your requests with crossDomain set to TRUE would fail.
>> The server is likely ignoring the crossDomain request because it's set to
>> not allow them. Also note that setting crossDomain to TRUE will force a
>> different request mode, as pointed out in the API docs for
>> qx.io.remote.RPC,
>> specifically using scriptTransport mode. So, even if you have set the RPC
>> server to allow crossDomain requests, it is possible that the specific
>> request you are implementing cannot be done via RPC with crossDomain set
>> to
>> TRUE - it really depends on what you are trying to send and receive in
>> your
>> specific implementation.
>
> I sent a message to the web2py mailing list today asking is there was
> anything needed to allow for cross domain calls in it json-rpc setup.
> The answer was no. The python shell tests confirmed in my mind that
> the web2py backend was working properly.
>
> http://groups.google.com/group/web2py/browse_thread/thread/1b224f2206b816b5#
>>
>> Anyway, I hope some of what I've said here provides some additional
>> insight
>> for you. Derrell, please correct anything I might have stated incorrectly
>> here, as you're the expert in this area.
>>
>> Regards,
>>
>> Gene
>>
>> On Fri, 2009-10-23 at 15:28 -0400, Don Lee wrote:
>>
>> I am using qooxdoo-0.8.3, along with web2py as my backend. My web
>> server and client are on the same network/domain. I have observer that
>> depending on the URL provided to the RPC object and whether I set
>> crossDomain, I get weird behavior even when running the software from
>> the web server itself. I have 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. Can anyone shed some light?
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> qooxdoo-devel mailing list
>> qooxdoo-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> qooxdoo-devel mailing list
>> qooxdoo-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>>
>>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
