>-----Original Message----- >From: Dan Dumont [mailto:ddum...@us.ibm.com] >Sent: Tuesday, March 27, 2012 8:52 AM >To: dev@shindig.apache.org >Subject: RE: Shindig running on different domain than container REVISITED > >What about the osapi calls like osapi.http that go to the container and >then to the shindig server?
Hmm..... I didn't realize that osapi calls got proxied through the container (I've never really dug into the oaspi implementation)..... That does sound like it would be problematic. :) I dug around a little bit yesterday and it looks like there are two osapi transports -- one implemented via straight XHR on the same domain as the gadget and another which uses gadgets.rpc to proxy calls via the container page. I didn't spend a ton of time digging through it but I think I saw something that made me believe that the XHR transport was the default which I think would work fine in the scenario I described -- but the comments in the gadgets.rpc transport say something about that transport being able to let the container participate in osapi calls (opening dialog boxes over the container page etc). So is all of what I've written above right? And if so -- what does that mean for installations that are using the XHR osapi transport -- does some ospai stuff just not work properly? I have a feeling I might be missing something... I think all of the core functionality in shindig (gadget server, social server and all the client side API's) should be implemented to work with shindig on a different domain than the container page -- if that's not the case now I think we should try to come up with ways to make it so. I'm fine if common container OOTB needs to run on the same domain as shindig (or hit a proxy on the container domain to talk to shindig) but I think we should ensure that its possible for implementers to do what we're doing in Rave and have it work without needing to host a proxy on the container domain. > >From: "Ciancetta, Jesse E." <jc...@mitre.org> >To: "dev@shindig.apache.org" <dev@shindig.apache.org>, >Date: 03/27/2012 08:03 AM >Subject: RE: Shindig running on different domain than container >REVISITED > > > >I've been meaning to respond to this thread for a while but have been >heads down on another project... > >Another option is to embed all of the data that common container usually >tries to fetch via XHR directly into the initial response of your >container page. > >That's the way we do it in Rave and IMO it works out nicely -- although it >is a little more work to implement it that way. You need code in your >container implementation which generates security tokens and also fetches >gadget metadata from Shindig -- but then with that in place you can embed >the tokens and metadata into the container page response for each gadget >the user has on their page and before you try to navigate each gadget you >can use the common container API's to push those embedded tokens and >metadata into the common container cache. You can also cache the gadget >metadata in your custom container so that you don't have to fetch it from >Shindig on every request. > >Doing this eliminates the need for common container to talk directly to >Shindig so then running Shindig on a different domain is no longer an >issue. It also cuts down on the number of network requests needed to get >a page of gadgets rendered which is a nice side effect (which was the real >reason we did it that way in Rave in the first place). > >--Jesse > >>-----Original Message----- >>From: Ryan J Baxter [mailto:rjbax...@us.ibm.com] >>Sent: Monday, March 26, 2012 8:16 PM >>To: dev@shindig.apache.org >>Subject: Re: Shindig running on different domain than container REVISITED >> >>Doug, I was also hacking up some code the other day that may be >>related..... >> >>Instead of setting the API_HOST and API_PATH to go through the proxy, you >>can setup a transparent proxy running on the containers domain to just >>"forward" the requests on to the Shindig server. The proxy I was using >>was the one provided by Jetty, which may be convenient if you are using >>Jetty to run you app :) >> >>http://docs.codehaus.org/display/JETTY/Asynchronous+Proxy+Servlet >> >> >>-Ryan >> >> >> >> >>From: daviesd <davi...@oclc.org> >>To: <dev@shindig.apache.org>, >>Date: 03/26/2012 04:58 PM >>Subject: Re: Shindig running on different domain than container >>REVISITED >> >> >> >>One other thing (if it helps). I see gadgets that don't do makeRequest >>fail >>as follows: >> >>Unsafe JavaScript attempt to access frame with URL >>http://localhost:9090/opensocial-demo/testcontainer/ from frame with URL >>http://localhost:8080/opensocial/gadgets/ifr?url=http%3A%2F%2Fhosting.g >m >>odul >> >>es.com%2Fig%2Fgadgets%2Ffile%2F112581010116074801021%2Fhamster.xm >l >>&container >>=default&view=default&lang=%25lang%25&country=%25country%25&debu >g >>=0&nocache= >>0&sanitize=%25sanitize%25&v=d699982ddc921667a106a76c22bc8e22&testm >o >>de=0&pare >>nt=http%3A%2F%2Flocalhost%3A9090&mid=0#up_hamsterName=%25up_h >a >>msterName%25&u >>p_bgColor=%25up_bgColor%25&up_bodyColor=%25up_bodyColor%25&up_ >e >>arColor=%25up >>_earColor%25&up_snoutColor=%25up_snoutColor%25&up_eyeColor=%25u >p >>_eyeColor%25 >>&up_feetColor=%25up_feetColor%25&up_tailColor=%25up_tailColor%25&u >p >>_waterCol >>or=%25up_waterColor%25&up_foodColor=%25up_foodColor%25&up_whe >el >>Color=%25up_w >>heelColor%25&up_wheelOuterColor=%25up_wheelOuterColor%25&up_wh >e >>elCenterColor >>=%25up_wheelCenterColor%25&up_wheelSpokeColor=%25up_wheelSpok >e >>Color%25. >>Domains, protocols and ports must match. >> >>So it's obvious I'm gonna have lots of issues getting this working. Is >>cross-domain support on the roadmap anywhere? I can try to tackle this >>but >>if it's on someone's roadmap I'll live with the proxy solution in the >>meantime. >> >>doug >> >> >>On 3/26/12 4:38 PM, "daviesd" <davi...@oclc.org> wrote: >> >>> Ok, one step forward. If I add >>> >>> servletResponse.addHeader("Access-Control-Allow-Headers", >>"Content-Type"); >>> >>> It starts working and the gadget renders. Cool. But then the first >>makeRequest >>> from a gadget seems to be having difficulty. >>> >>> doug >>> >>> >> >> >
