Here's my experience. First the setup. locahost:8080/opensocial - shindig server localhost:9090/opensocial-demo - demo client
The client includes the shindig javascript as follows: <script type='text/javascript' src='http://localhost:8080/opensocial/gadgets/js/container:rpc.js?nocache=1&; c=1&debug=1&container=default'></script> And creates the container as follows: var config = {}; config[osapi.container.ServiceConfig.API_HOST] = "http://localhost:8080";; config[osapi.container.ServiceConfig.API_PATH] = "/opensocial/rpc"; var container = new osapi.container.Container(config); In this configuration I get the following errors OPTIONS http://localhost:8080/opensocial/rpc?st=... 400 (Bad Request) and XMLHttpRequest cannot load http://localhost:8080/opensocial/rpc?st=... Origin http://localhost:9090 <http://localhost/> is not allowed by Access-Control-Allow-Origin. Now if I deploy my proxy in the root context (/) that does the following <rule match-type='wildcard'> <condition type="port" operator="equal">9090</condition> <from>/opensocial/**</from> <to type="proxy">http://localhost:8080/opensocial/$1</to> </rule> And switch the API_HOST and API_PATH to use the proxy config[osapi.container.ServiceConfig.API_HOST] = "http://localhost:9090";; config[osapi.container.ServiceConfig.API_PATH] = "/opensocial/rpc"; Everything works properly. However I don't like the proxy running as the root context, so I tried to change it to run at /opensocial-proxy and changed the API_PATH to config[osapi.container.ServiceConfig.API_PATH] = "/opensocial-proxy/opensocial/rpc"; However in this configuration the rpc calls still seemed to be going to localhost:9090/opensocial/rpc NOT localhost:9090/opensocial-proxy/opensocial/rpc So not sure what I'm doing wrong there. When I patched the JsonRpcServlet to accept the OPTIONS requests I was able to eliminate OPTIONS bad request, but nothing else changed. I also think as was suggested that osapi call from the gadgets failed as well. So for me the only scenarios that work are: - deploying the shindig server and container to the same domain (we let the load balancer direct /opensocial calls to the servers). or - provide a proxy to shuttle local /opensocial requests to the real server. However as I stated I could only do this if running the proxy in the ROOT context. This may just be my configuration issue, not sure. Hope that helps. doug On 3/28/12 7:30 AM, "Ciancetta, Jesse E." <[email protected]> wrote: >> -----Original Message----- >> From: Dan Dumont [mailto:[email protected]] >> Sent: Tuesday, March 27, 2012 8:52 AM >> To: [email protected] >> 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." <[email protected]> >> To: "[email protected]" <[email protected]>, >> 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:[email protected]] >>> Sent: Monday, March 26, 2012 8:16 PM >>> To: [email protected] >>> 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 <[email protected]> >>> To: <[email protected]>, >>> 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" <[email protected]> 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 >>>> >>>> >>> >>> >> > >
