Ahhhhhhhhhhhhhhhhhhhh... yes total impedance mismatch. I was starting from the spec, from which it is not clear at first glance that gadgets.io.makeRequest is a totally different proxy than gadgets.io.getProxyUrl. This makes much more sense now.
Would anyone oppose some updates to the spec with stronger language about the intentions of each of these methods? Here's a stab at some explanation, please correct me if I've made any misstatements: http://opensocial-resources.googlecode.com/svn/spec/2.0/Core-Gadget.xml#gadgets.io.getProxyUrl The spec is not clear, but this is apparently intended to be a "content proxy" for use with images, etc. It will help cache resources on the shindig server to avoid many hits to target servers. When using locked domains, requests made through this proxy from a "locked domain" will be all denied. It is expected that the server admin would configure the proxy to only be available at a non-locked domain, thus preventing the ability for applications to use it for XHR, but allowing them to use it for an image src, for example. http://opensocial-resources.googlecode.com/svn/spec/2.0/Core-Gadget.xml#gadgets.io.makeRequest This api is meant to be used for all xhr transactions. It has mechanisms to specify authentication (OAUTH, mostly) that will automatically get applied to the request going out. There are currently no API's to build a request URL to this endpoint and handle the xhr separately. From: John Hjelmstad <[email protected]> To: [email protected], Date: 09/22/2011 12:09 AM Subject: Re: Lcoked domains and proxy requests in shindig Hey Dan, I think we're just having a communication impedance mismatch :) The proxy URI being on locked domain doesn't matter at all, functionally speaking. In fact, it's prohibited by default as a precautionary measure, to protect the gadget. The only one that does matter on the locked domain is makeRequest, since it's done via XHR (you could make an argument that it too could be deployed as JSONP in many situations). --j On Wed, Sep 21, 2011 at 7:57 PM, Dan Dumont <[email protected]> wrote: > Perhaps I'm being dense, but I don't understand why the proxy URI being on > a locked domain matters. Is this just an attempt to more effectively cache > common requests for all gadgets? > > I was under the impression that the same origin policy would prevent you > from being able to use xhr for requests built to use a proxy URL on a > different host than the one the gadget is rendered in (locked). Do you set > cors header to allow all gadgets to reach your proxy URI? If so, what about > older browsers? > > > > tively > -----John Hjelmstad <[email protected]> wrote: ----- > > ======================= > To: Dan Dumont/Westford/IBM@Lotus > From: John Hjelmstad <[email protected]> > Date: 09/21/2011 07:28PM > Cc: [email protected]@IBMUS@LOTUS > Subject: Re: Lcoked domains and proxy requests in shindig > ======================= > On Wed, Sep 21, 2011 at 4:08 PM, Dan Dumont <[email protected]> wrote: > > > Hi John, Craig > > > > You mentioned some interesting things about the proxy in your thread, and > I > > didn't want to hijack it, but I have some tangent questions of my own. > > > > In shindig I see: > > ProxyServlet.java > > ... > > // *TODO*: Consider removing due to redundant logic. > > String host = request.getHeader("Host"); > > *if*(!lockedDomainService.isSafeForOpenProxy(host)) { > > ... > > > > > > But the implementation for isSafeForOpenProxy() is to return false if > > domain locking is enabled and the request came in on a locked domain. > > > > From your conversations about the content-disposition header, it looks > like > > for Jive and Google the locked gadgets can use the proxy. Do either of > you > > have any idea why the code is like this in shindig? Is it assumed to be > so > > implementation specific that no one wanted to even bother with guessing > so > > they just turned it off? > > > > Do either of you have any good guidelines for an implementation of > > isSafeForOpenProxy that allows some use of the proxy from domain locked > > gadgets? > > > The default impl should allow use from locked domain gadgets -- for > ProxyServlet -- so long as the provided domain isn't a locked domain. > > At Google, we reserve the URL suffix -a-opensocial.googleusercontent.comfor > locked domains. Other domains are fair game for proxy use, eg - > opensocial.googleusercontent.com (which is the overarching URL suffix used > for the reverse proxy to our service instance). > > You basically then just need to make sure that gadgets.io.getProxyUrl > returns such a URL. Per the previous discussion, there's no strong reason > you need the proxy to be on the same domain as the gadget itself (**). > > That config is in gadgets.features/core.io/proxyUrl; for server-side > rewriting it's in "gadgets.uri.proxy.host". You can point them to one > another with a config like: > > "gadgets.features": { > "core.io": { > "proxyUrl": > > "${Cur['gadgets.uri.proxy.host']}/gadgets/proxy?refresh=%refresh%&url=%url%%rewriteMime%" > } > } > > --j > >
