What about the osapi calls like osapi.http that go to the container and then to the shindig server?
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.gm >odul > >es.com%2Fig%2Fgadgets%2Ffile%2F112581010116074801021%2Fhamster.xml >&container >=default&view=default&lang=%25lang%25&country=%25country%25&debug >=0&nocache= >0&sanitize=%25sanitize%25&v=d699982ddc921667a106a76c22bc8e22&testmo >de=0&pare >nt=http%3A%2F%2Flocalhost%3A9090&mid=0#up_hamsterName=%25up_ha >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=%25up >_eyeColor%25 >&up_feetColor=%25up_feetColor%25&up_tailColor=%25up_tailColor%25&up >_waterCol >or=%25up_waterColor%25&up_foodColor=%25up_foodColor%25&up_wheel >Color=%25up_w >heelColor%25&up_wheelOuterColor=%25up_wheelOuterColor%25&up_whe >elCenterColor >=%25up_wheelCenterColor%25&up_wheelSpokeColor=%25up_wheelSpoke >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 >> >> > >
