On Wed, Aug 18, 2010 at 2:50 AM, Tim Wintle wrote:
> On Tue, 2010-08-17 at 11:35 -0700, ๏̯͡๏ Jasvir Nagra wrote:
> >
> > For code in the caja subset of javascript/html, the cajoled gadget can
> > safely be on the same origin as the container. The security policy
> > does not rely on origin but ra
On Tue, 2010-08-17 at 11:35 -0700, ๏̯͡๏ Jasvir Nagra wrote:
>
> For code in the caja subset of javascript/html, the cajoled gadget can
> safely be on the same origin as the container. The security policy
> does not rely on origin but rather the choice and implementation of
> APIs that the contain
So the choices (security-wise) are:
Everything in the same url: a non-trusted gadget can take full control of
the user's session, accessing the server and all the other gadgets in the
page.
The site in a different url than ifr: a non-trusted gadget can take full
control of the other gadgets in th
On Tue, Aug 17, 2010 at 10:32 AM, Pablo Graña wrote:
> I partially understand the same origin policy, but not all of its
> consequences. If all gadgets are rendered from the same ifr 'service', they
> share the same origin. Does that mean that every gadget can walk the dom of
> every other gadget
I partially understand the same origin policy, but not all of its
consequences. If all gadgets are rendered from the same ifr 'service', they
share the same origin. Does that mean that every gadget can walk the dom of
every other gadget in the same page? At least, they could share the cookies,
but
I think you have it right... I will look into that more. Thanks for the tip.
On Aug 17, 2010, at 6:16 AM, Tim Wintle wrote:
> On Wed, 2010-08-11 at 13:01 -0400, Gregg Horan wrote:
>> I've been successful using apache in front and doing rewrites on /
>> gadgets, /social, etc.
>
> I may be mis
You probably even want each gadget iframe to be rendered on a different sub
domain or else they'll be able to influence eachother through the dom.
Anyway, I ended up doing the metadata call on the serverside and passing
only the result to the client js which seems to work fine.
On Tue, Aug 17, 201
If shindig and your container are on the same domain all gadgets have
full access to your container javascript, can manipulate the dom of
your page and access your user's cookies.
See http://en.wikipedia.org/wiki/Same_origin_policy
2010/8/17 Pablo Graña :
> I apologize for my ignorance, but I can
I apologize for my ignorance, but I can't figure out why is it a security
risk.
On Tue, Aug 17, 2010 at 7:16 AM, Tim Wintle wrote:
> On Wed, 2010-08-11 at 13:01 -0400, Gregg Horan wrote:
> > I've been successful using apache in front and doing rewrites on /
> > gadgets, /social, etc.
>
> I may be
On Wed, 2010-08-11 at 13:01 -0400, Gregg Horan wrote:
> I've been successful using apache in front and doing rewrites on /
> gadgets, /social, etc.
I may be misunderstanding, but you don't really want to be hosting your
site on the same (domain, port) as shindig for security reasons.
/p/partuza/ . He does it this way.
Justin
> Date: Wed, 11 Aug 2010 14:07:39 +0200
> Subject: Cross domain call to metadata
> From: christi...@q42.nl
> To: dev@shindig.apache.org
>
> Hi,
>
> I'm trying to set up a new container.
> I used the samplecontainer as
I've been successful using apache in front and doing rewrites on /
gadgets, /social, etc.
I'm new to it though - so would be curious to see what other options
are suggested.
Gregg
On Aug 11, 2010, at 8:07 AM, Christiaan Hees wrote:
Hi,
I'm trying to set up a new container.
I used the sam
12 matches
Mail list logo
