Followup on this issue. I circled back and did some more digging, I have a solution to the problem now, but I am not sure if I have created a vulnerability in the nix transport setup.
I found that the problem I was having is when switching to canvas view, I was only changing the source on an existing iframe for a gadget. When that happened (in IE 7), the window.opener property for that frame was wiped. Since the nix transport assigns a VBScript wrapper to the window.opener property, the gadget was left with no way to communicate with the container, and all RPC calls were failing after that. I found that if I were to set the AuthToken again using gadgets.rpc.setAuthToken(frameid, token), it would tell the rpc library to attempt to setup the transport channel again. The problem was that the rpc setupFrame method saw that frame was already configured for that iframe (from the initial load) and didn't proceed with setting up the channel. Since the gadget's iframe was trying to initialize its' rpc transport again, it always failed on the opener being null. My workaround was add a parameter to the gadgets.rpc.setAuthToken method that would force the setupFrame method to re-initialize the transport for that gadget. And everything works. What I don't like about this approach is that I am avoiding reloading the entire gadget just to switch the view so I am not changing the Auth Token, I am just using gadgets.rpc.setAuthToken to tell the rpc library to setup the transport again for that gadget. This seems hacky. Does anyone have any thoughts over whether or not this is exposing the transport channel to a vulnerability? I read through this long discussion (http://mail-archives.apache.org/mod_mbox/incubator-shindig-dev/200807.mbox/%3c973792251.1215051165146.javamail.j...@brutus%3e) about the winow.opener implementation for IE and I think I am still good, but wanted some input or possibly a better approach before I attempted submitting a bug/patch. Sorry for such a long post, but I wanted to be sure I got all of the details in it. Steve T. -----Original Message----- From: Terlecki, Stephen [mailto:[email protected]] Sent: Tuesday, September 29, 2009 6:55 AM To: [email protected] Subject: RE: Having trouble with IE 7 RPC calls after changing the view Are there any other thoughts as to why IE might be having trouble like this with RPC calls? Steve T. -----Original Message----- From: Jasvir Nagra [mailto:[email protected]] Sent: Wednesday, September 23, 2009 11:52 AM To: [email protected] Subject: Re: Having trouble with IE 7 RPC calls after changing the view On Wed, Sep 23, 2009 at 8:12 AM, Terlecki, Stephen < [email protected]> wrote: > When in IE 7, rpc calls work fine after the initial rendering, but > when I change the view for a gadget to canvas (changing the src of the > iframe to the new view), the rpc calls don't work anymore. I tracked > the problem through the NIX transport and it appears that the problem > is that the gadget tries to attach to the NIX channel that the > container has already opened when the view has changed, but the > window.opener property is null (from what I can tell from the windows > scripting debugger and stepping through). Since the opener property > is null, the gadget can't initialize the transport and the rpc code > sets the transport to the fallbackTransport that just ignores all rpc calls > for that particular gadget. > > Has anyone else experienced this problem? Or does anyone have > suggestions for how I change the view on the gadget that might avoid > this issue altogether? Is the answer to just dump the iframe > rendering approach and switch to caja, since I seem to have nothing > but problems with the iframes lately? > As it stands today on Shindig, caja renders inside an iframe too. To remove the iframe would require refactoring Shindig at the very least to separate the gadget content rewriting from the feature injection. See Abe Music's earlier emails on this list. > > Thanks, > > Steve T. > >
