Thanks for the feedback, Brian. Comments inline. On Wed, May 6, 2009 at 10:05 PM, Brian Eaton <[email protected]> wrote:
> Thanks for the heads-up. > > I love the idea of refactoring gadgets.rpc into smaller bits. > > There are existing type=url gadgets that rely on verifying the domain > of the parent page in order to function securely. Today they can do > that by enforcing use of IFPC or WPM and checking the relay URL. That > all seems like it should stay working. Any potential problems you can > see? Yes, this continues to work. I did add 'rmr' to gadgets.rpc.forceParentVerifiable() list of acceptable transports, since it has the relevant security property. Now that I think of it, this is another reason to keep IFPC, though it's possible (haven't tested) that RMR works on IE and FF2 as well. I'll test that. > > > When you say "gadget iframe is the relay URL", do you mean that RPC > messages get tacked on to that exact iframe? Or do we create new > iframes to the same domain and file? Ah, I should have been more clear on this. What I meant in particular is that, when you're not using IFPC, you can now just pass the gadget's IFRAME URL to the gadgets.rpc.setRelayUrl(gadgetId, relayUrl); method as the second parameter. That's because the CL includes code to parse out the protocol://host:port of any given relay, which is what's actually used to construct an RMR relay file (tacking on /robots.txt) as well as to verify WPM-sent messages. NIX, FE, and DPM don't make use of a gadget's relayUrl (to the previous point, they're not parent-verifiable) at all. > > > If we are tacking them on to the same iframe: are we going to hit URL > length limits on messages sooner due to the number of things we cram > on there already? Fortunately, not the same IFRAME :) Tacking onto the same IFRAME would introduce navigation problems as well (when a gadget IFRAME scrolled, it would pop back up to the top on fragment-change). > > > If we are using new iframes to the same domain and file: will there be > any problems with cacheability of the iframe URLs? Or authentication > required to load iframe URLs? None of which I'm aware. The RMR relay is (receiver's) protocol://host:port/robots.txt, which doesn't even need to exist or be served "correctly" (404/500 OK). It would be nice for this file to be heavily cached but at least it's a one-time load. --John > > > Cheers, > Brian > > > On Wed, May 6, 2009 at 7:01 PM, John Hjelmstad <[email protected]> wrote: > > Hello, > > I've been implementing some improvements to rpc.js, and have a few more > > planned, so wanted to give everyone a heads-up. > > > > Issue (https://issues.apache.org/jira/browse/SHINDIG-1050) describes a > new > > transport mechanism I (with significant help from Joey Schorr) have > > implemented called RMR. Nitty-gritty details are in the code and the > issue, > > but the upshot is that this transport is like IFPC but without an > "active" > > relay file. It covers all known (to me) significant browsers currently > using > > IFPC, notably Safari < 4 and Chrome < 2. > > > > With this submitted, IFPC remains somewhat useful though, since it is > used > > as a fall-back for sending messages in certain cases when a "native" > > (dpm/wpm/nix/rmr/fe) transport isn't fully set up on initial page render. > > Messages sent during this period may otherwise be lost (and occasionally > can > > be now, I believe). > > > > With these items in mind, I plan the following: > > 1. Solicit input (if any) on RMR and submit the CL ( > > http://codereview.appspot.com/62051). > > > > 2. Refactor rpc.js transport code into transport classes eg. > WpmTransport, > > NixTransport, etc. Core rpc.js code will call init()/setup()/call() > methods > > on these as appropriate, and each transport will signal to the core > rpc.js > > library when it is ready to send messages (should any handshake be > > necessary). > > > > 3. Implement queueing of messages sent before transport is ready, > utilizing > > work from #2. When the transport signals its readiness, de-queue messages > > and pass all subsequent calls through immediately. > > > > 4. Remove IFPC code: in rpc.js and in rpc_relay.html - assuming no > remaining > > viable use case for it is identified in the meantime. > > > > 5. Deprecate/remove gadgets.rpc.setRelayUrl(...) method. Without IFPC the > > relayUrl for each gadget is simply its own URL. > > > > 6. Consider deprecation/removal of gadgets.rpc.setAuthToken(...) method. > We > > can remove this method as well, parsing the token directly from the > gadget's > > iframe.src, assuming we trust the gadget not to replace/remove its > fragment. > > > > Comments welcome - cheers, > > John > > >
