You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Dan Dumont <dd...@us.ibm.com> on 2011/09/22 01:08:59 UTC
Lcoked domains and proxy requests in shindig
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?
Re: Lcoked domains and proxy requests in shindig
Posted by Ryan J Baxter <rj...@us.ibm.com>.
Dan, the spec discussion should be moved to the spec google group. I am
certainly in favor of clearing things up though.
-Ryan
Email: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: John Hjelmstad <fa...@google.com>
To: dev@shindig.apache.org,
Date: 09/23/2011 06:49 PM
Subject: Re: Lcoked domains and proxy requests in shindig
I'd be in favor of that, and thanks for the clarification.
This comes with the caveat that my experience, especially recently, is
focused purely on the existing Shindig implementation rather than the spec
itself. I *think* a logical consequence of the content vs. JSON proxying
requirements inevitably leads to a pair of (otherwise very similar,
especially on the fetching side) proxies, but it's not necessarily a
mandate.
--j
On Fri, Sep 23, 2011 at 2:41 PM, Dan Dumont <dd...@us.ibm.com> wrote:
> 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 <fa...@google.com>
> To: dev@shindig.apache.org,
> 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 <dd...@us.ibm.com> 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 <fa...@google.com> wrote: -----
> >
> > =======================
> > To: Dan Dumont/Westford/IBM@Lotus
> > From: John Hjelmstad <fa...@google.com>
> > Date: 09/21/2011 07:28PM
> > Cc: dev@shindig.apache.org@IBMUS@LOTUS
> > Subject: Re: Lcoked domains and proxy requests in shindig
> > =======================
> > On Wed, Sep 21, 2011 at 4:08 PM, Dan Dumont <dd...@us.ibm.com>
> 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
> >
> >
>
>
>
>
Re: Lcoked domains and proxy requests in shindig
Posted by John Hjelmstad <fa...@google.com>.
I'd be in favor of that, and thanks for the clarification.
This comes with the caveat that my experience, especially recently, is
focused purely on the existing Shindig implementation rather than the spec
itself. I *think* a logical consequence of the content vs. JSON proxying
requirements inevitably leads to a pair of (otherwise very similar,
especially on the fetching side) proxies, but it's not necessarily a
mandate.
--j
On Fri, Sep 23, 2011 at 2:41 PM, Dan Dumont <dd...@us.ibm.com> wrote:
> 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 <fa...@google.com>
> To: dev@shindig.apache.org,
> 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 <dd...@us.ibm.com> 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 <fa...@google.com> wrote: -----
> >
> > =======================
> > To: Dan Dumont/Westford/IBM@Lotus
> > From: John Hjelmstad <fa...@google.com>
> > Date: 09/21/2011 07:28PM
> > Cc: dev@shindig.apache.org@IBMUS@LOTUS
> > Subject: Re: Lcoked domains and proxy requests in shindig
> > =======================
> > On Wed, Sep 21, 2011 at 4:08 PM, Dan Dumont <dd...@us.ibm.com>
> 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
> >
> >
>
>
>
>
Re: Lcoked domains and proxy requests in shindig
Posted by Dan Dumont <dd...@us.ibm.com>.
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 <fa...@google.com>
To: dev@shindig.apache.org,
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 <dd...@us.ibm.com> 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 <fa...@google.com> wrote: -----
>
> =======================
> To: Dan Dumont/Westford/IBM@Lotus
> From: John Hjelmstad <fa...@google.com>
> Date: 09/21/2011 07:28PM
> Cc: dev@shindig.apache.org@IBMUS@LOTUS
> Subject: Re: Lcoked domains and proxy requests in shindig
> =======================
> On Wed, Sep 21, 2011 at 4:08 PM, Dan Dumont <dd...@us.ibm.com>
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
>
>
Re: Lcoked domains and proxy requests in shindig
Posted by John Hjelmstad <fa...@google.com>.
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 <dd...@us.ibm.com> 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 <fa...@google.com> wrote: -----
>
> =======================
> To: Dan Dumont/Westford/IBM@Lotus
> From: John Hjelmstad <fa...@google.com>
> Date: 09/21/2011 07:28PM
> Cc: dev@shindig.apache.org@IBMUS@LOTUS
> Subject: Re: Lcoked domains and proxy requests in shindig
> =======================
> On Wed, Sep 21, 2011 at 4:08 PM, Dan Dumont <dd...@us.ibm.com> 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
>
>
Re: Lcoked domains and proxy requests in shindig
Posted by Dan Dumont <dd...@us.ibm.com>.
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 <fa...@google.com> wrote: -----
=======================
To: Dan Dumont/Westford/IBM@Lotus
From: John Hjelmstad <fa...@google.com>
Date: 09/21/2011 07:28PM
Cc: dev@shindig.apache.org@IBMUS@LOTUS
Subject: Re: Lcoked domains and proxy requests in shindig
=======================
On Wed, Sep 21, 2011 at 4:08 PM, Dan Dumont <dd...@us.ibm.com> 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.com for
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
Re: Lcoked domains and proxy requests in shindig
Posted by John Hjelmstad <fa...@google.com>.
On Wed, Sep 21, 2011 at 4:08 PM, Dan Dumont <dd...@us.ibm.com> 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.com for
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