You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Gabriel Guardincerri <gg...@gmail.com> on 2010/10/14 01:29:22 UTC

Different subdomains for each gadget

Hi,

We would like increase the security of each gadget by having each one in a
different subdomain. This is, have each iframe in a different subdomain to
use the cross-domain security of the browsers.
We found that we can define the urls using our own container.js, but there's
no way to assign a different subdomain for each gadget. So, is there a way
to make that more dynamic, or to do something else to have a different
subdomain for each gadget?

Thanks,

Gabriel

Re: Different subdomains for each gadget

Posted by John Hjelmstad <fa...@google.com>.
We don't -- a gadget developer is free to (attempt to... I've seen mixed
results doing this) compromise his/her own security if desired :)

--j

On Wed, Oct 13, 2010 at 7:16 PM, Gagandeep singh <ga...@gmail.com>wrote:

> I don't know understand locked domains much, but one doubt:
> Do you also disallow scripts from setting document.domain to the parent
> domain ? Usually the Same Origin policy which prevents different documents
> from interacting with each other allows interactions  once document.domain
> when set to a parent domain.
>
> On Thu, Oct 14, 2010 at 5:44 AM, Gabriel Guardincerri <gguardin@gmail.com
> >wrote:
>
> > Awesome, I was just looking at container.js and wondering what was
> > locked-domain. Thanks for the fast response.
> >
> > Gabriel
> >
> > On Wed, Oct 13, 2010 at 8:40 PM, John Hjelmstad <fa...@google.com>
> wrote:
> >
> > > Hi Gabriel:
> > >
> > > This is precisely what the "locked-domain" feature does.
> > >
> > > The default implementation in Shindig - which Google uses - is to
> > generate
> > > a
> > > URL w/ prefix base32(sha1(gadgetUrl)).
> > >
> > > This occurs when:
> > > A) the gadget requires "locked-domain" explicitly
> > > B) the gadget requires another feature that has a <dependency> on
> > > locked-domain
> > > C) the container is set up (in its ContainerConfig, via key
> > > "gadgets.uri.iframe.lockedDomainRequired" with type boolean) to demand
> > > locked-domain for all renders
> > >
> > > The validation algorithm is thus:
> > > A. when a gadget requires locked-domain, it MUST have a locked-domain
> > > prefix.
> > > B. if the domain on which a gadget is rendered has *any* valid
> > > locked-domain
> > > *suffix*, mark as invalid.
> > >
> > > Doing this ensures the domain isolation of each gadget.
> > >
> > > The bulk of this functionality is implemented in the Java
> implementation
> > > in:
> > >
> > >
> >
> http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/uri/DefaultIframeUriManager.java
> > >
> > > INVALID_DOMAIN is returned in the mismatched cases. locked-domain URLs
> > are
> > > generated if (usingLockedDomain(...)).
> > >
> > > The default prefix generator is:
> > >
> > >
> >
> http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/uri/HashShaLockedDomainPrefixGenerator.java
> > >
> > > --j
> > >
> > > On Wed, Oct 13, 2010 at 4:29 PM, Gabriel Guardincerri <
> > gguardin@gmail.com
> > > >wrote:
> > >
> > > > Hi,
> > > >
> > > > We would like increase the security of each gadget by having each one
> > in
> > > a
> > > > different subdomain. This is, have each iframe in a different
> subdomain
> > > to
> > > > use the cross-domain security of the browsers.
> > > > We found that we can define the urls using our own container.js, but
> > > > there's
> > > > no way to assign a different subdomain for each gadget. So, is there
> a
> > > way
> > > > to make that more dynamic, or to do something else to have a
> different
> > > > subdomain for each gadget?
> > > >
> > > > Thanks,
> > > >
> > > > Gabriel
> > > >
> > >
> >
>

Re: Different subdomains for each gadget

Posted by Gagandeep singh <ga...@gmail.com>.
I don't know understand locked domains much, but one doubt:
Do you also disallow scripts from setting document.domain to the parent
domain ? Usually the Same Origin policy which prevents different documents
from interacting with each other allows interactions  once document.domain
when set to a parent domain.

On Thu, Oct 14, 2010 at 5:44 AM, Gabriel Guardincerri <gg...@gmail.com>wrote:

> Awesome, I was just looking at container.js and wondering what was
> locked-domain. Thanks for the fast response.
>
> Gabriel
>
> On Wed, Oct 13, 2010 at 8:40 PM, John Hjelmstad <fa...@google.com> wrote:
>
> > Hi Gabriel:
> >
> > This is precisely what the "locked-domain" feature does.
> >
> > The default implementation in Shindig - which Google uses - is to
> generate
> > a
> > URL w/ prefix base32(sha1(gadgetUrl)).
> >
> > This occurs when:
> > A) the gadget requires "locked-domain" explicitly
> > B) the gadget requires another feature that has a <dependency> on
> > locked-domain
> > C) the container is set up (in its ContainerConfig, via key
> > "gadgets.uri.iframe.lockedDomainRequired" with type boolean) to demand
> > locked-domain for all renders
> >
> > The validation algorithm is thus:
> > A. when a gadget requires locked-domain, it MUST have a locked-domain
> > prefix.
> > B. if the domain on which a gadget is rendered has *any* valid
> > locked-domain
> > *suffix*, mark as invalid.
> >
> > Doing this ensures the domain isolation of each gadget.
> >
> > The bulk of this functionality is implemented in the Java implementation
> > in:
> >
> >
> http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/uri/DefaultIframeUriManager.java
> >
> > INVALID_DOMAIN is returned in the mismatched cases. locked-domain URLs
> are
> > generated if (usingLockedDomain(...)).
> >
> > The default prefix generator is:
> >
> >
> http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/uri/HashShaLockedDomainPrefixGenerator.java
> >
> > --j
> >
> > On Wed, Oct 13, 2010 at 4:29 PM, Gabriel Guardincerri <
> gguardin@gmail.com
> > >wrote:
> >
> > > Hi,
> > >
> > > We would like increase the security of each gadget by having each one
> in
> > a
> > > different subdomain. This is, have each iframe in a different subdomain
> > to
> > > use the cross-domain security of the browsers.
> > > We found that we can define the urls using our own container.js, but
> > > there's
> > > no way to assign a different subdomain for each gadget. So, is there a
> > way
> > > to make that more dynamic, or to do something else to have a different
> > > subdomain for each gadget?
> > >
> > > Thanks,
> > >
> > > Gabriel
> > >
> >
>

Re: Different subdomains for each gadget

Posted by Gabriel Guardincerri <gg...@gmail.com>.
Awesome, I was just looking at container.js and wondering what was
locked-domain. Thanks for the fast response.

Gabriel

On Wed, Oct 13, 2010 at 8:40 PM, John Hjelmstad <fa...@google.com> wrote:

> Hi Gabriel:
>
> This is precisely what the "locked-domain" feature does.
>
> The default implementation in Shindig - which Google uses - is to generate
> a
> URL w/ prefix base32(sha1(gadgetUrl)).
>
> This occurs when:
> A) the gadget requires "locked-domain" explicitly
> B) the gadget requires another feature that has a <dependency> on
> locked-domain
> C) the container is set up (in its ContainerConfig, via key
> "gadgets.uri.iframe.lockedDomainRequired" with type boolean) to demand
> locked-domain for all renders
>
> The validation algorithm is thus:
> A. when a gadget requires locked-domain, it MUST have a locked-domain
> prefix.
> B. if the domain on which a gadget is rendered has *any* valid
> locked-domain
> *suffix*, mark as invalid.
>
> Doing this ensures the domain isolation of each gadget.
>
> The bulk of this functionality is implemented in the Java implementation
> in:
>
> http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/uri/DefaultIframeUriManager.java
>
> INVALID_DOMAIN is returned in the mismatched cases. locked-domain URLs are
> generated if (usingLockedDomain(...)).
>
> The default prefix generator is:
>
> http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/uri/HashShaLockedDomainPrefixGenerator.java
>
> --j
>
> On Wed, Oct 13, 2010 at 4:29 PM, Gabriel Guardincerri <gguardin@gmail.com
> >wrote:
>
> > Hi,
> >
> > We would like increase the security of each gadget by having each one in
> a
> > different subdomain. This is, have each iframe in a different subdomain
> to
> > use the cross-domain security of the browsers.
> > We found that we can define the urls using our own container.js, but
> > there's
> > no way to assign a different subdomain for each gadget. So, is there a
> way
> > to make that more dynamic, or to do something else to have a different
> > subdomain for each gadget?
> >
> > Thanks,
> >
> > Gabriel
> >
>

Re: Different subdomains for each gadget

Posted by John Hjelmstad <fa...@google.com>.
On Thu, Oct 14, 2010 at 10:58 AM, Zhenhua Guo <je...@gmail.com> wrote:

>  If I understand it right, client side needs to get the domain prefix
> (which is base32(sha1(gadget_url)) for now). There are couple ways to
> get it
>  1) Retrieve the gadget metadata.
>    the url is included in the gadget metadata (can be obtained via
> call to the metadata interface)
>  2) calculate it in javascript
>

Correct. Option #1 is preferable to let a single place (the server) be the
source of truth for domain information.


>  My question is that DNS must be modified to make all <*.example.com>
> (assume example.com is my domain)  point to example.com. Is that
> right? Otherwise, the domain with hash prefix cannot be resolved?
>

That's correct.

-j


>
> Gerald
>
>
> On Wed, Oct 13, 2010 at 7:40 PM, John Hjelmstad <fa...@google.com> wrote:
> > Hi Gabriel:
> >
> > This is precisely what the "locked-domain" feature does.
> >
> > The default implementation in Shindig - which Google uses - is to
> generate a
> > URL w/ prefix base32(sha1(gadgetUrl)).
> >
> > This occurs when:
> > A) the gadget requires "locked-domain" explicitly
> > B) the gadget requires another feature that has a <dependency> on
> > locked-domain
> > C) the container is set up (in its ContainerConfig, via key
> > "gadgets.uri.iframe.lockedDomainRequired" with type boolean) to demand
> > locked-domain for all renders
> >
> > The validation algorithm is thus:
> > A. when a gadget requires locked-domain, it MUST have a locked-domain
> > prefix.
> > B. if the domain on which a gadget is rendered has *any* valid
> locked-domain
> > *suffix*, mark as invalid.
> >
> > Doing this ensures the domain isolation of each gadget.
> >
> > The bulk of this functionality is implemented in the Java implementation
> in:
> >
> http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/uri/DefaultIframeUriManager.java
> >
> > INVALID_DOMAIN is returned in the mismatched cases. locked-domain URLs
> are
> > generated if (usingLockedDomain(...)).
> >
> > The default prefix generator is:
> >
> http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/uri/HashShaLockedDomainPrefixGenerator.java
> >
> > --j
> >
> > On Wed, Oct 13, 2010 at 4:29 PM, Gabriel Guardincerri <
> gguardin@gmail.com>wrote:
> >
> >> Hi,
> >>
> >> We would like increase the security of each gadget by having each one in
> a
> >> different subdomain. This is, have each iframe in a different subdomain
> to
> >> use the cross-domain security of the browsers.
> >> We found that we can define the urls using our own container.js, but
> >> there's
> >> no way to assign a different subdomain for each gadget. So, is there a
> way
> >> to make that more dynamic, or to do something else to have a different
> >> subdomain for each gadget?
> >>
> >> Thanks,
> >>
> >> Gabriel
> >>
> >
>

Re: Different subdomains for each gadget

Posted by Zhenhua Guo <je...@gmail.com>.
  If I understand it right, client side needs to get the domain prefix
(which is base32(sha1(gadget_url)) for now). There are couple ways to
get it
  1) Retrieve the gadget metadata.
    the url is included in the gadget metadata (can be obtained via
call to the metadata interface)
  2) calculate it in javascript
  My question is that DNS must be modified to make all <*.example.com>
(assume example.com is my domain)  point to example.com. Is that
right? Otherwise, the domain with hash prefix cannot be resolved?

Gerald


On Wed, Oct 13, 2010 at 7:40 PM, John Hjelmstad <fa...@google.com> wrote:
> Hi Gabriel:
>
> This is precisely what the "locked-domain" feature does.
>
> The default implementation in Shindig - which Google uses - is to generate a
> URL w/ prefix base32(sha1(gadgetUrl)).
>
> This occurs when:
> A) the gadget requires "locked-domain" explicitly
> B) the gadget requires another feature that has a <dependency> on
> locked-domain
> C) the container is set up (in its ContainerConfig, via key
> "gadgets.uri.iframe.lockedDomainRequired" with type boolean) to demand
> locked-domain for all renders
>
> The validation algorithm is thus:
> A. when a gadget requires locked-domain, it MUST have a locked-domain
> prefix.
> B. if the domain on which a gadget is rendered has *any* valid locked-domain
> *suffix*, mark as invalid.
>
> Doing this ensures the domain isolation of each gadget.
>
> The bulk of this functionality is implemented in the Java implementation in:
> http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/uri/DefaultIframeUriManager.java
>
> INVALID_DOMAIN is returned in the mismatched cases. locked-domain URLs are
> generated if (usingLockedDomain(...)).
>
> The default prefix generator is:
> http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/uri/HashShaLockedDomainPrefixGenerator.java
>
> --j
>
> On Wed, Oct 13, 2010 at 4:29 PM, Gabriel Guardincerri <gg...@gmail.com>wrote:
>
>> Hi,
>>
>> We would like increase the security of each gadget by having each one in a
>> different subdomain. This is, have each iframe in a different subdomain to
>> use the cross-domain security of the browsers.
>> We found that we can define the urls using our own container.js, but
>> there's
>> no way to assign a different subdomain for each gadget. So, is there a way
>> to make that more dynamic, or to do something else to have a different
>> subdomain for each gadget?
>>
>> Thanks,
>>
>> Gabriel
>>
>

Re: Different subdomains for each gadget

Posted by John Hjelmstad <fa...@google.com>.
Hi Gabriel:

This is precisely what the "locked-domain" feature does.

The default implementation in Shindig - which Google uses - is to generate a
URL w/ prefix base32(sha1(gadgetUrl)).

This occurs when:
A) the gadget requires "locked-domain" explicitly
B) the gadget requires another feature that has a <dependency> on
locked-domain
C) the container is set up (in its ContainerConfig, via key
"gadgets.uri.iframe.lockedDomainRequired" with type boolean) to demand
locked-domain for all renders

The validation algorithm is thus:
A. when a gadget requires locked-domain, it MUST have a locked-domain
prefix.
B. if the domain on which a gadget is rendered has *any* valid locked-domain
*suffix*, mark as invalid.

Doing this ensures the domain isolation of each gadget.

The bulk of this functionality is implemented in the Java implementation in:
http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/uri/DefaultIframeUriManager.java

INVALID_DOMAIN is returned in the mismatched cases. locked-domain URLs are
generated if (usingLockedDomain(...)).

The default prefix generator is:
http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/uri/HashShaLockedDomainPrefixGenerator.java

--j

On Wed, Oct 13, 2010 at 4:29 PM, Gabriel Guardincerri <gg...@gmail.com>wrote:

> Hi,
>
> We would like increase the security of each gadget by having each one in a
> different subdomain. This is, have each iframe in a different subdomain to
> use the cross-domain security of the browsers.
> We found that we can define the urls using our own container.js, but
> there's
> no way to assign a different subdomain for each gadget. So, is there a way
> to make that more dynamic, or to do something else to have a different
> subdomain for each gadget?
>
> Thanks,
>
> Gabriel
>