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 > >
