You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Reinoud Elhorst <cl...@claude.nl> on 2008/01/30 02:39:03 UTC
Shindig Hello World
Hi all,
In the process of trying to make Hyves an OpenSocial container, I tried my
hand tonight at making the Hello World OpenSocial Gadget example work in our
site, through Shindig. I ran into some small issues, which I rather "hacked"
my way around. Now I understand that Shindig is work in progress, and don't
blame anyone for this not being s finished product. Au contraire, I was
pleasantly surprised by how far I've come in just one night: thumbs up for
the readability and documentation of most of the code, and obviously the
lavish explanations I've been able to enjoy on this list!
I hope someone can give some feedback on the following issues:
- I included the js and css files from the /javascript/container directory
into the parent page. When copying the code from the sample files, there are
some options I'm missing in the gadgets.js file. It seems to me that the
result of gadgets.container.createGadget, should have methods to set the
"nocache=1" and the security token (or just generally, everything behind the
#). Am I thinking in the right direction here, or is this being handled in
some other way?
- The opensocial part consists of a lot of general javascript, and some
container-specific javascript. How does shindig know where to get this
container specific javascript? Would this done in a call to the result of
gadgets.container.createGadget as well?
- For the ifpc to work correctly, the ifpc_relay.html file has to be present
on the same domain as the parent page is on (so, basically, your SNS
domain). Is there any documentation yet on what the security implications of
this are?
Presently, I'm at the point where pretty much everything works except for
the API calls back to the site; I wanted to make sure I was going in the
right direction with regard to the exchange of the security token.
Thanks,
Reinoud Elhorst
Hyves Senior Developer
Re: Shindig Hello World
Posted by Kevin Brown <et...@google.com>.
On Jan 29, 2008 5:39 PM, Reinoud Elhorst <cl...@claude.nl> wrote:
> Hi all,
>
> In the process of trying to make Hyves an OpenSocial container, I tried my
> hand tonight at making the Hello World OpenSocial Gadget example work in
> our
> site, through Shindig. I ran into some small issues, which I rather
> "hacked"
> my way around. Now I understand that Shindig is work in progress, and
> don't
> blame anyone for this not being s finished product. Au contraire, I was
> pleasantly surprised by how far I've come in just one night: thumbs up for
> the readability and documentation of most of the code, and obviously the
> lavish explanations I've been able to enjoy on this list!
>
> I hope someone can give some feedback on the following issues:
> - I included the js and css files from the /javascript/container
> directory
> into the parent page. When copying the code from the sample files, there
> are
> some options I'm missing in the gadgets.js file. It seems to me that the
> result of gadgets.container.createGadget, should have methods to set the
> "nocache=1" and the security token (or just generally, everything behind
> the
> #). Am I thinking in the right direction here, or is this being handled in
> some other way?
You're right (though there may still be 'another way' that I'm not aware of;
bear in mind, though, that the gadgets.js code isn't necessarily required to
generate the iframes. Feel free to do this however you like. As long as
you're generating the right parameters and you have the right container side
JS for handling interframe communication calls, you're a compliant gadgets
server.
>
> - The opensocial part consists of a lot of general javascript, and some
> container-specific javascript. How does shindig know where to get this
> container specific javascript? Would this done in a call to the result of
> gadgets.container.createGadget as well?
The opensocial stuff needs a lot of work. Currently you'll basically have to
implement your own opensocial-0.6 (or 0.7) feature that hooks in your site's
data and rebuild the server to support it.
>
> - For the ifpc to work correctly, the ifpc_relay.html file has to be
> present
> on the same domain as the parent page is on (so, basically, your SNS
> domain). Is there any documentation yet on what the security implications
> of
> this are?
There is (although it might need to be cleaned up to remove some google
proprietary stuff), but currently there's nowhere to publish it. When we
have a place to publish docs, we'll get it published.
> Presently, I'm at the point where pretty much everything works except for
> the API calls back to the site; I wanted to make sure I was going in the
> right direction with regard to the exchange of the security token.
It sounds like you're going in the right direction, and you're mostly just
encountering the shortcomings of what we have in Shindig right now. This
should all be changing shortly.
Re: Shindig Hello World
Posted by Kevin Brown <et...@google.com>.
On Jan 30, 2008 12:05 AM, Martin Webb <ma...@gmail.com> wrote:
> On 30/01/2008, Kevin Brown <et...@google.com> wrote:
> >
> > Real production sites should always render the iframe on a different
> > domain
> > from the parent site This is critical for security. Without it, none of
> > the
> > other security solutions matter.
> >
>
> This would be true for 3rd party gadgets - but what about the domain's own
> gadgets? For example, http://www.google.com/ig also hosts gadgets for
> Google's other applications, e.g. mail, Google reader, Google Calendar,
> GGE
> etc, etc... For the domain's own gadgets wouldn't they be server from an
> iframe on the same domain? This then supports SSO across the apps from
> the
> same domain?
You could, but currently shindig has no way to discriminate between gadgets
from different domains, so there's no way to do this securely without server
side changes at this point in time. If you really trust a gadget, you can do
whatever you want with it (even inline it without Caja). I think this is
valuable functionality, but we need a solution that ensures that only
trusted gadgets can be rendered on the domain. This dovetails into an
implementation of locked domain.
Ideally a solution like this wouldn't just require the same domain, but that
the gadget be served from the server itself (in the file system or perhaps
as a resource file). This eliminates potential DNS related exploits as well.
If so, does this imply there needs to be two instances of ifpc_relay.html
> file - one for 3rd party gadgets that is not hosted on the main domain but
> somewhere else, and one for the domain's own gadgets?
If it's the same domain, ifpc_relay isn't necessary at all; either the
gadget could modify the parent page directly, or gadgets.rpc could be
implemented in such a way that it was domain aware and just used ifpc when
it was a third party gadget. The latter is recommended, and it's what we'll
need anyway to support inline cajoled gadgets in the near future.
Re: Shindig Hello World
Posted by Martin Webb <ma...@gmail.com>.
On 30/01/2008, Kevin Brown <et...@google.com> wrote:
>
> Real production sites should always render the iframe on a different
> domain
> from the parent site This is critical for security. Without it, none of
> the
> other security solutions matter.
>
This would be true for 3rd party gadgets - but what about the domain's own
gadgets? For example, http://www.google.com/ig also hosts gadgets for
Google's other applications, e.g. mail, Google reader, Google Calendar, GGE
etc, etc... For the domain's own gadgets wouldn't they be server from an
iframe on the same domain? This then supports SSO across the apps from the
same domain?
If so, does this imply there needs to be two instances of ifpc_relay.html
file - one for 3rd party gadgets that is not hosted on the main domain but
somewhere else, and one for the domain's own gadgets?
Martin
Re: Shindig Hello World
Posted by Kevin Brown <et...@google.com>.
On Jan 29, 2008 6:14 PM, Brian Eaton <be...@google.com> wrote:
> On Jan 29, 2008 5:39 PM, Reinoud Elhorst <cl...@claude.nl> wrote:
> > Presently, I'm at the point where pretty much everything works except
> for
> > the API calls back to the site; I wanted to make sure I was going in the
> > right direction with regard to the exchange of the security token.
>
> There is very little server-side container implemented in Shindig at
> the moment. I'm taking a first pass at it. Feedback on the approach
> is welcome:
>
> - user logs in to the container
> - container uses the GadgetServer to render the gadget in 'Container'
> mode (which doesn't do much at the moment)
> - container uses GadgetSigner (which I'm renaming to
> GadgetTokenSigner) to create the security token for the gadget
> - container creates an iframe that passes in the security token like
> this: <iframe src='/gadgets/ifr?url=<gadget>&mid=<module-id>#st=<the
> security token>
Real production sites should always render the iframe on a different domain
from the parent site This is critical for security. Without it, none of the
other security solutions matter.
>
> - GadgetServer behind /gadgets/ifr works its magic to render the gadget.
> - gadgets.io javascript pulls security token out of the URL.
> - gadgets.io javascripts passes security token as
> X-Gadget-Security-Token in XHR requests to the JSON proxy.
>
> Cheers,
> Brian
>
Re: Shindig Hello World
Posted by Brian Eaton <be...@google.com>.
On Jan 29, 2008 5:39 PM, Reinoud Elhorst <cl...@claude.nl> wrote:
> Presently, I'm at the point where pretty much everything works except for
> the API calls back to the site; I wanted to make sure I was going in the
> right direction with regard to the exchange of the security token.
There is very little server-side container implemented in Shindig at
the moment. I'm taking a first pass at it. Feedback on the approach
is welcome:
- user logs in to the container
- container uses the GadgetServer to render the gadget in 'Container'
mode (which doesn't do much at the moment)
- container uses GadgetSigner (which I'm renaming to
GadgetTokenSigner) to create the security token for the gadget
- container creates an iframe that passes in the security token like
this: <iframe src='/gadgets/ifr?url=<gadget>&mid=<module-id>#st=<the
security token>
- GadgetServer behind /gadgets/ifr works its magic to render the gadget.
- gadgets.io javascript pulls security token out of the URL.
- gadgets.io javascripts passes security token as
X-Gadget-Security-Token in XHR requests to the JSON proxy.
Cheers,
Brian
Re: Shindig Hello World
Posted by Akash Xavier <ak...@gmail.com>.
Kevin......
remember?
That day I had asked you how to provide site's data to the gadget?
Can u please explain how to do it?
Which files I have to edit? and info like that........
On Jan 30, 2008 4:18 PM, Kevin Brown <et...@google.com> wrote:
> On Jan 30, 2008 2:46 PM, Cassie <do...@apache.org> wrote:
>
> > On Wed, Jan 30, 2008 at 12:30 PM, Reinoud Elhorst <cl...@claude.nl>
> > wrote:
> >
> > > On 1/30/08, Brian Eaton <be...@google.com> wrote:
> > > >
> > > > OK, I think the answer to this question is that the container and
> the
> > > > gadget server need to collaborate closely. If the gadget server has
> > > > enough information to validate and decrypt the security token it is
> > > > already tightly coupled (sharing keys) with the container. They
> need
> > > > to have a common understanding of policy as well.
> > > >
> > > > There's more than one way to pass that policy information between
> the
> > > > container and the gadget server. Depending on how much information
> > > > there is it might fit into the security token, or you might want to
> > > > have them share a backend data store that they use to reference
> > > > policy.
> > > >
> > > I think I'm staring to get it. Still, there may be situations that the
> > > permission to view the viewer information is obtained client side (so
> > > neither the container nor the gadget server have any knowledge of
> this)
> > > though opensocial.requestPermission. I can imagine that in quite some
> > > implementations, this call will pop up something on the container-page
> > > (through rpc/ifpc) asking for permission to send viewer data to the
> > > gadget.
> > > As I come to think of it, if you don't want to route your opensocial
> > > dataRequest calls through ifpc to the container page, you're going to
> > > need
> > > some extra token there to let the dataRequest call know that
> permission
> > > was
> > > obtained. This same token can (should?) then be used to let the gadget
> > > server know that the gadget has access to the viewer information.
> > >
> > > I'm actually not quite sure on how much of the requestPermission has
> > > already
> > > been implemented in shindig; perhaps I'm just stating the status quo
> > here.
> >
> >
> > We haven't implemented it yet in shindig. I would imagine though that if
> > you
> > want to pop up a dialog to the user you would ifpc to the parent page,
> the
> > parent page would pop up a dialog and get the users input. You would
> then
> > need a server call from that outer page back to your server to store the
> > bit
> > in your data storage. Then, the ifpc calls back to the inner iframe with
> > the
> > result (if needed).
> >
> > You could instead just have that call be a redirect to a new page on
> your
> > site and when it completes you would just go back to the original page
> and
> > reload all of the gadgets. This is also perfectly spec compliant.
> >
> > So either way you either need to navigate the page or use ifpc for
> > anything
> > that needs user input (because you can't trust anything that comes from
> > the
> > iframe)
> >
> > This is slightly different from any calls that just get data from the
> > server
> > though. Because you don't need any user input the calls can not be faked
> > from the users perspective, which means you can call directly back to
> your
> > server and do not need any ifpc to the outer container if you use the
> > special token on the hash.
> >
> > Does that makes sense at all or did I just confuse everybody more, lol
> :)
>
>
> You can't trust anything from anyone (on your server). It's no more
> difficult to pretend to be myspace than it is to pretend to be the iframe,
> so making an ifpc call doesn't really help you any (unless your gadget is
> only trying to authenticate against the parent site, in which case that's
> what the GadgetSigner interface is for). Without signing support,
> authentication of requests is non-existent (unless you're rendering the
> gadget on your parent domain and letting it access cookies or something).
> Anything that requires this sort of support must be done as a redirect
> today.
>
--
Akash Manohar
akashmanohar@gmail.com
Re: Shindig Hello World
Posted by Kevin Brown <et...@google.com>.
On Jan 30, 2008 2:46 PM, Cassie <do...@apache.org> wrote:
> On Wed, Jan 30, 2008 at 12:30 PM, Reinoud Elhorst <cl...@claude.nl>
> wrote:
>
> > On 1/30/08, Brian Eaton <be...@google.com> wrote:
> > >
> > > OK, I think the answer to this question is that the container and the
> > > gadget server need to collaborate closely. If the gadget server has
> > > enough information to validate and decrypt the security token it is
> > > already tightly coupled (sharing keys) with the container. They need
> > > to have a common understanding of policy as well.
> > >
> > > There's more than one way to pass that policy information between the
> > > container and the gadget server. Depending on how much information
> > > there is it might fit into the security token, or you might want to
> > > have them share a backend data store that they use to reference
> > > policy.
> > >
> > I think I'm staring to get it. Still, there may be situations that the
> > permission to view the viewer information is obtained client side (so
> > neither the container nor the gadget server have any knowledge of this)
> > though opensocial.requestPermission. I can imagine that in quite some
> > implementations, this call will pop up something on the container-page
> > (through rpc/ifpc) asking for permission to send viewer data to the
> > gadget.
> > As I come to think of it, if you don't want to route your opensocial
> > dataRequest calls through ifpc to the container page, you're going to
> > need
> > some extra token there to let the dataRequest call know that permission
> > was
> > obtained. This same token can (should?) then be used to let the gadget
> > server know that the gadget has access to the viewer information.
> >
> > I'm actually not quite sure on how much of the requestPermission has
> > already
> > been implemented in shindig; perhaps I'm just stating the status quo
> here.
>
>
> We haven't implemented it yet in shindig. I would imagine though that if
> you
> want to pop up a dialog to the user you would ifpc to the parent page, the
> parent page would pop up a dialog and get the users input. You would then
> need a server call from that outer page back to your server to store the
> bit
> in your data storage. Then, the ifpc calls back to the inner iframe with
> the
> result (if needed).
>
> You could instead just have that call be a redirect to a new page on your
> site and when it completes you would just go back to the original page and
> reload all of the gadgets. This is also perfectly spec compliant.
>
> So either way you either need to navigate the page or use ifpc for
> anything
> that needs user input (because you can't trust anything that comes from
> the
> iframe)
>
> This is slightly different from any calls that just get data from the
> server
> though. Because you don't need any user input the calls can not be faked
> from the users perspective, which means you can call directly back to your
> server and do not need any ifpc to the outer container if you use the
> special token on the hash.
>
> Does that makes sense at all or did I just confuse everybody more, lol :)
You can't trust anything from anyone (on your server). It's no more
difficult to pretend to be myspace than it is to pretend to be the iframe,
so making an ifpc call doesn't really help you any (unless your gadget is
only trying to authenticate against the parent site, in which case that's
what the GadgetSigner interface is for). Without signing support,
authentication of requests is non-existent (unless you're rendering the
gadget on your parent domain and letting it access cookies or something).
Anything that requires this sort of support must be done as a redirect
today.
Re: Shindig Hello World
Posted by Reinoud Elhorst <cl...@claude.nl>.
On 1/30/08, Cassie <do...@apache.org> wrote:
>
> On Wed, Jan 30, 2008 at 12:30 PM, Reinoud Elhorst <cl...@claude.nl>
> wrote:
>
> > On 1/30/08, Brian Eaton <be...@google.com> wrote:
> > >
> > > OK, I think the answer to this question is that the container and the
> > > gadget server need to collaborate closely. If the gadget server has
> > > enough information to validate and decrypt the security token it is
> > > already tightly coupled (sharing keys) with the container. They need
> > > to have a common understanding of policy as well.
> > >
> > > There's more than one way to pass that policy information between the
> > > container and the gadget server. Depending on how much information
> > > there is it might fit into the security token, or you might want to
> > > have them share a backend data store that they use to reference
> > > policy.
> > >
> > I think I'm staring to get it. Still, there may be situations that the
> > permission to view the viewer information is obtained client side (so
> > neither the container nor the gadget server have any knowledge of this)
> > though opensocial.requestPermission. I can imagine that in quite some
> > implementations, this call will pop up something on the container-page
> > (through rpc/ifpc) asking for permission to send viewer data to the
> > gadget.
> > As I come to think of it, if you don't want to route your opensocial
> > dataRequest calls through ifpc to the container page, you're going to
> > need
> > some extra token there to let the dataRequest call know that permission
> > was
> > obtained. This same token can (should?) then be used to let the gadget
> > server know that the gadget has access to the viewer information.
> >
> > I'm actually not quite sure on how much of the requestPermission has
> > already
> > been implemented in shindig; perhaps I'm just stating the status quo
> here.
>
>
> We haven't implemented it yet in shindig. I would imagine though that if
> you
> want to pop up a dialog to the user you would ifpc to the parent page, the
> parent page would pop up a dialog and get the users input. You would then
> need a server call from that outer page back to your server to store the
> bit
> in your data storage. Then, the ifpc calls back to the inner iframe with
> the
> result (if needed).
>
> You could instead just have that call be a redirect to a new page on your
> site and when it completes you would just go back to the original page and
> reload all of the gadgets. This is also perfectly spec compliant.
>
> So either way you either need to navigate the page or use ifpc for
> anything
> that needs user input (because you can't trust anything that comes from
> the
> iframe)
>
> This is slightly different from any calls that just get data from the
> server
> though. Because you don't need any user input the calls can not be faked
> from the users perspective, which means you can call directly back to your
> server and do not need any ifpc to the outer container if you use the
> special token on the hash.
>
> Does that makes sense at all or did I just confuse everybody more, lol :)
>
I'm all the way with you, however I wouldn't want to store the bit that some
gadget has access to the viewer on my server. This would only be useful if
we want to make the access persistent, however I think that I'd just want to
allow access for that one session (as long as the user stays on the same
container page, possibly persist it when moving to another view of the same
gadget).
I'd rather see that there are two security tokens, one always available to
the gadget (which the gadget always sends with any makeRequest, and which is
checked by the gadget server to see which gadget it is, and who are the
viewer and owner). The second is only available to the gadget when it has
access to the viewer information. So this can either be included in the
initial #-part of the iframe url (in case the business rules decide that
permission is granted from the start), or is sent to the gadget through ifpc
after a successful opensocial.requestPermission:
- the requestPermission would check for the second security token to be
present, if so, call callback right away
- if the second token is not present, send an ifpc to the container-page
- the container page shows a popup (or moves away to another page)
- if the request is granted, the container page does an ifpc to the gadget
(it would need this anyway to initiate the callback), with the second
security token.
For any request the gadget makes (through the gadget server, either by an
opensocial dataRequest, or a gadgets.io.makeRequest), both tokens are sent
(assuming that the second token is present, else only the first is sent).
By checking the second token, the gadget server knows whether the gadget has
access to the viewer without duplicating any of the container's business
logic (which is quite a big plus if the container and gadget server are in
different languages!).
By checking the second token, the container knows that the permission was
granted, and doesn't have do re-do it's own business logic, or inquire any
persistent storage.
Above description with two security tokens, could also be replaced by a
single token, that changes value. The basis is having 3 states: No access at
all (should not occur in "friendly" gadgets), access to all but viewer
information, access to all. Other permissions that persist along one
session, could be encoded in a similar way, although I believe that only the
"viewer" permission has the extra benefit of being useful to the gadget
server as such, because of the phone home.
Reinoud
Re: Shindig Hello World
Posted by Cassie <do...@apache.org>.
On Wed, Jan 30, 2008 at 12:30 PM, Reinoud Elhorst <cl...@claude.nl> wrote:
> On 1/30/08, Brian Eaton <be...@google.com> wrote:
> >
> > OK, I think the answer to this question is that the container and the
> > gadget server need to collaborate closely. If the gadget server has
> > enough information to validate and decrypt the security token it is
> > already tightly coupled (sharing keys) with the container. They need
> > to have a common understanding of policy as well.
> >
> > There's more than one way to pass that policy information between the
> > container and the gadget server. Depending on how much information
> > there is it might fit into the security token, or you might want to
> > have them share a backend data store that they use to reference
> > policy.
> >
> I think I'm staring to get it. Still, there may be situations that the
> permission to view the viewer information is obtained client side (so
> neither the container nor the gadget server have any knowledge of this)
> though opensocial.requestPermission. I can imagine that in quite some
> implementations, this call will pop up something on the container-page
> (through rpc/ifpc) asking for permission to send viewer data to the
> gadget.
> As I come to think of it, if you don't want to route your opensocial
> dataRequest calls through ifpc to the container page, you're going to
> need
> some extra token there to let the dataRequest call know that permission
> was
> obtained. This same token can (should?) then be used to let the gadget
> server know that the gadget has access to the viewer information.
>
> I'm actually not quite sure on how much of the requestPermission has
> already
> been implemented in shindig; perhaps I'm just stating the status quo here.
We haven't implemented it yet in shindig. I would imagine though that if you
want to pop up a dialog to the user you would ifpc to the parent page, the
parent page would pop up a dialog and get the users input. You would then
need a server call from that outer page back to your server to store the bit
in your data storage. Then, the ifpc calls back to the inner iframe with the
result (if needed).
You could instead just have that call be a redirect to a new page on your
site and when it completes you would just go back to the original page and
reload all of the gadgets. This is also perfectly spec compliant.
So either way you either need to navigate the page or use ifpc for anything
that needs user input (because you can't trust anything that comes from the
iframe)
This is slightly different from any calls that just get data from the server
though. Because you don't need any user input the calls can not be faked
from the users perspective, which means you can call directly back to your
server and do not need any ifpc to the outer container if you use the
special token on the hash.
Does that makes sense at all or did I just confuse everybody more, lol :)
Re: Shindig Hello World
Posted by Reinoud Elhorst <cl...@claude.nl>.
On 1/30/08, Brian Eaton <be...@google.com> wrote:
>
> OK, I think the answer to this question is that the container and the
> gadget server need to collaborate closely. If the gadget server has
> enough information to validate and decrypt the security token it is
> already tightly coupled (sharing keys) with the container. They need
> to have a common understanding of policy as well.
>
> There's more than one way to pass that policy information between the
> container and the gadget server. Depending on how much information
> there is it might fit into the security token, or you might want to
> have them share a backend data store that they use to reference
> policy.
>
I think I'm staring to get it. Still, there may be situations that the
permission to view the viewer information is obtained client side (so
neither the container nor the gadget server have any knowledge of this)
though opensocial.requestPermission. I can imagine that in quite some
implementations, this call will pop up something on the container-page
(through rpc/ifpc) asking for permission to send viewer data to the gadget.
As I come to think of it, if you don't want to route your opensocial
dataRequest calls through ifpc to the container page, you're going to need
some extra token there to let the dataRequest call know that permission was
obtained. This same token can (should?) then be used to let the gadget
server know that the gadget has access to the viewer information.
I'm actually not quite sure on how much of the requestPermission has already
been implemented in shindig; perhaps I'm just stating the status quo here.
Re: Shindig Hello World
Posted by Brian Eaton <be...@google.com>.
On Jan 30, 2008 11:44 AM, Reinoud Elhorst <cl...@claude.nl> wrote:
> Problem is that only the container-webpage knows whether this permission has
> been obtained (in the general case, obviously sometimes the permission is
> always granted or denied). So either the call needs to go through the
> container page, or the gadget needs to have some token that affirms that it
> has access to the viewer_id (or viewer_whatever), which needs to be checked
> by the gadget server.
OK, I think the answer to this question is that the container and the
gadget server need to collaborate closely. If the gadget server has
enough information to validate and decrypt the security token it is
already tightly coupled (sharing keys) with the container. They need
to have a common understanding of policy as well.
There's more than one way to pass that policy information between the
container and the gadget server. Depending on how much information
there is it might fit into the security token, or you might want to
have them share a backend data store that they use to reference
policy.
Cheers,
Brian
Re: Shindig Hello World
Posted by Reinoud Elhorst <cl...@claude.nl>.
On 1/30/08, Brian Eaton <be...@google.com> wrote:
>
> I'm not sure I understand your question. Could it be paraphrased as
> "how does the container know that the gadget has the permission to
> reveal the viewer ID by making a phone home request?"
If you replace "container" by "gadget server", that's affirmative; as I
understand it, the secure phone home (in case of running one's own gadget
server) does not go through the container, right?
so:
"how does the gadget server know that the gadget has the permission to
reveal the viewer ID by making a phone home request?"
Problem is that only the container-webpage knows whether this permission has
been obtained (in the general case, obviously sometimes the permission is
always granted or denied). So either the call needs to go through the
container page, or the gadget needs to have some token that affirms that it
has access to the viewer_id (or viewer_whatever), which needs to be checked
by the gadget server.
If that's the question, then I think the answer is you need an access
> control layer of some type within the container. The container needs
> to know that revealing the viewer ID is acceptable to the user. This
> gets into some interesting topics, like how should the viewer ID be
> chosen (is it an e-mail, or a username, or just an opaque value unique
> to each user? Should different gadgets see different viewer IDs for
> the same user, or should gadgets be able to correlate viewer IDs?)
> Does anyone know if the opensocial specs have touched on these
> questions?
Actually, I posted the some of these questions on the OpenSocial some days
back, and Arne is trying to find someone for me that can answer those
questions :)
http://groups.google.com/group/opensocial-api/browse_thread/thread/11d9300e61a2577a
Reinoud
Re: Shindig Hello World
Posted by Brian Eaton <be...@google.com>.
On Jan 30, 2008 11:21 AM, Reinoud Elhorst <cl...@claude.nl> wrote:
> I'm not convinced yet that this is enough. The secure phone home does need
> to securely transfer the viewer_id, owner_id and application_id (or
> gadget-xml-url is perhaps better), right ("securely" here means "not having
> been tampered with")? However, how does the gadget server know whether the
> gadget is allowed to view the viewer_id. I believe this is only possible if
> either allowing permission to the viewer id would set some signed value
> within the gadget, or the actual retrieval of the viewer sets some signed
> data (where the latter method seems more appropriate); perhaps I'm missing
> something here.
I'm not sure I understand your question. Could it be paraphrased as
"how does the container know that the gadget has the permission to
reveal the viewer ID by making a phone home request?"
If that's the question, then I think the answer is you need an access
control layer of some type within the container. The container needs
to know that revealing the viewer ID is acceptable to the user. This
gets into some interesting topics, like how should the viewer ID be
chosen (is it an e-mail, or a username, or just an opaque value unique
to each user? Should different gadgets see different viewer IDs for
the same user, or should gadgets be able to correlate viewer IDs?)
Does anyone know if the opensocial specs have touched on these
questions?
Those are policy decisions. I'm not sure if Shindig needs code to
support those policies, or if they can be enforced without help from
Shindig.
Cheers,
Brian
Re: Shindig Hello World
Posted by Reinoud Elhorst <cl...@claude.nl>.
On 1/30/08, Brian Eaton <be...@google.com> wrote:
>
> If the container and the gadget server are run by the same
> organization you can use the security token to initiate secure phone
> home. The flow would look like this:
>
> - gadget makes a request to the phone home endpoint on the gadget
> server (e.g. /jsonp?auth=signed) and includes the security token.
> - the gadget server validates the security token and pulls out the
> relevant information about the user and gadget.
> - the gadget server looks up the appropriate phone home key and signs
> the request.
I'm not convinced yet that this is enough. The secure phone home does need
to securely transfer the viewer_id, owner_id and application_id (or
gadget-xml-url is perhaps better), right ("securely" here means "not having
been tampered with")? However, how does the gadget server know whether the
gadget is allowed to view the viewer_id. I believe this is only possible if
either allowing permission to the viewer id would set some signed value
within the gadget, or the actual retrieval of the viewer sets some signed
data (where the latter method seems more appropriate); perhaps I'm missing
something here.
Reinoud
Re: Shindig Hello World
Posted by Brian Eaton <be...@google.com>.
On Jan 30, 2008 9:44 AM, Reinoud Elhorst <cl...@claude.nl> wrote:
> Just for the exercise, what kind of signing/encryption would be needed here?
> I guess the values (viewerid, ownerid, applicationid) need to be both
> encrypted and signed (where the encryption may actually be used as
> signature).
You at least need signing, you probably want both encryption and
signing. The signing is so a malicious gadget can't tamper with the
security token. The encryption is so you don't leak your internal
user identifiers to gadgets. Encryption alone is not enough to
authenticate the token, you want an HMAC for that. You'll also need
to use different keys for the encryption and the signing. Here's some
pseudocode:
encryptionKey = SHA1("enc" || masterkey)
signingKey = SHA1("sign" || masterkey)
plainText = owner, viewer, gadget, timestamp
IV = 128 random bytes
encryptedToken = AES-128-CBC(encryptionKey, IV, plainText)
signature = HMAC(signingKey, IV || encryptedToken)
securityToken = signature || IV || encryptedToken
You're probably going to want a time limit embedded in the security
token as well. The time limit could be fairly short if you're willing
to use AJAX to have the gadget call back to the container to refresh
the security token every few minutes. If you go with that scheme then
when someone logs out of the container their gadget security tokens
will quickly become invalid as well.
> For the ajax-calls back to the container this is not a problem,
> since a private secret can be used for that in the container. If the gadget
> server needs to be able to do secure phone-home, I guess it will not use
> this #st value, but something else it gets returned from the ajax-calls to
> the container, right?
If the container and the gadget server are run by the same
organization you can use the security token to initiate secure phone
home. The flow would look like this:
- gadget makes a request to the phone home endpoint on the gadget
server (e.g. /jsonp?auth=signed) and includes the security token.
- the gadget server validates the security token and pulls out the
relevant information about the user and gadget.
- the gadget server looks up the appropriate phone home key and signs
the request.
If the container and the gadget server aren't run by the same
organization then this is harder. You would need an IFPC call from
the gadget to the container page, then a request to a phone home
endpoint on the container, then another IFPC call from the container
page back into the gadget to return the data.
Cheers,
Brian
Re: Shindig Hello World
Posted by Reinoud Elhorst <cl...@claude.nl>.
On 1/30/08, Brian Eaton <be...@google.com> wrote:
>
> That's right. At some point we'll put actual authentication in that
> code, but for now ironing out any kinks in the high level design is
> more important.
I agree with that.
Just for the exercise, what kind of signing/encryption would be needed here?
I guess the values (viewerid, ownerid, applicationid) need to be both
encrypted and signed (where the encryption may actually be used as
signature). For the ajax-calls back to the container this is not a problem,
since a private secret can be used for that in the container. If the gadget
server needs to be able to do secure phone-home, I guess it will not use
this #st value, but something else it gets returned from the ajax-calls to
the container, right?
Would you mind outlining your architecture for me? Will you be using
> the java gadget server with a PHP container? Or are both the gadget
> server and the container going to be PHP based?
At this moment I'm experimenting with having the gadget server in java,
while the container is in php. We were looking at using the php shindig
server in the beginning, but since the java-one is much further in
development, we'll use that one for now. Even if the PHP version was as far
as the java version, I think we might still have chosen the java server.
At the very least it will really force us to keep the two platforms totally
separated :)
Our initial plans were to use google-provided gadget servers for the
official launch (I understood at the meeting at six apart that more
containers were thinking of doing things that way), but I think there is
quite some extra complexity in getting shindig to work in an environment
totally independent of the container. So, seeing how Orkut will be launching
a 0.7 service this week, and MySpace "something" next week, we might need to
speed up things a little and at least during beta use our own
shindig(-based) server. In any scenario I think its a big plus to have a
proper understanding of the inner workings of Shindig.
Re: Shindig Hello World
Posted by Brian Eaton <be...@google.com>.
On Jan 30, 2008 5:40 AM, Reinoud Elhorst <cl...@claude.nl> wrote:
> On 1/30/08, Brian Eaton <be...@google.com> wrote:
> >
> > - user logs in to the container
> > - container uses the GadgetServer to render the gadget in 'Container'
> > mode (which doesn't do much at the moment)
> > - container uses GadgetSigner (which I'm renaming to
> > GadgetTokenSigner) to create the security token for the gadget
>
> I guess this is only useful if the container site is in java as well. Our
> site is in PHP, so I guess I need to convert the GadgetSigner to PHP
> (probably make some people on the PHP branch happy by conrtributing it back
> :) ). Am I correct in seeing that there is no actual signing (so no actual
> security) in there at the moment?
That's right. At some point we'll put actual authentication in that
code, but for now ironing out any kinks in the high level design is
more important.
Would you mind outlining your architecture for me? Will you be using
the java gadget server with a PHP container? Or are both the gadget
server and the container going to be PHP based?
Cheers,
Brian
Re: Shindig Hello World
Posted by Kevin Brown <et...@google.com>.
You've got it backwards. You should have an opensocial-0.7 feature which
depends on your container implementation (alternatively, just rename your
implementation to opensocial-0.7). This way when gadget authors specify:
<Require feature="opensocial-0.7"/>
It uses YOUR implementation of opensocial-0.7, which can only qualify as a
valid implementation if it conforms to the opensocial-0.7 spec.
This problem should be addressed in Shindig proper in the near future, but
for now that's your only real option.
~Kevin
On Jan 30, 2008 11:34 AM, Reinoud Elhorst <cl...@claude.nl> wrote:
> > What does your hyvescontainer feature do/supply?
> >
> > We're currently thinking about how a shared server can satisfy the needs
> > of
> > several different containers when they have slightly different
> > configuration
> > parameters, data formats, and so on. Container-mediated communication
> > (gadget-ifpc-to-container and back) is in many cases a viable solution
> > since
> > it offloads container-specific logic to the container itself, but as
> > mentioned several times can have performance costs.
> >
> > --John
>
>
> The hyvescontainer feature is just a copy of the relevant parts of the
> opensocial-samplecontainer feature. I haven't dug into this too much yet,
> but basically all logic on how to talk to the Hyves backend is in there.
>
> The only time the container is able to pass anything to the (shared)
> gadget
> server, is in the src part of the iframe. My initial idea would be to add
> a
> parameter to this call: extra_feature_list, which would be a list of urls
> of
> feature.xml files to be included in the gadget. These external feature
> files
> would be handled just the same as internal feature.xml files, our
> hyvescontainer feature file would be something like:
>
> <feature>
> <name>hyvescontainer</name>
> <gadget>
> <dependency>opensocial-0.7</dependency>
> <script src="
> http://www.hyves-static.nl/opensocial/hyvescontainer.js
> "/>
> </gadget>
> </feature>
>
> (I have to admit, I'm not completely sure what else is possible in feature
> files, possibly this would open up a security hole. The minimal
> functionality needed is just what I mentioned above: some way to set
> dependencies, and some way to include javascript)
>
>
> Reinoud
>
Re: Shindig Hello World
Posted by Reinoud Elhorst <cl...@claude.nl>.
> What does your hyvescontainer feature do/supply?
>
> We're currently thinking about how a shared server can satisfy the needs
> of
> several different containers when they have slightly different
> configuration
> parameters, data formats, and so on. Container-mediated communication
> (gadget-ifpc-to-container and back) is in many cases a viable solution
> since
> it offloads container-specific logic to the container itself, but as
> mentioned several times can have performance costs.
>
> --John
The hyvescontainer feature is just a copy of the relevant parts of the
opensocial-samplecontainer feature. I haven't dug into this too much yet,
but basically all logic on how to talk to the Hyves backend is in there.
The only time the container is able to pass anything to the (shared) gadget
server, is in the src part of the iframe. My initial idea would be to add a
parameter to this call: extra_feature_list, which would be a list of urls of
feature.xml files to be included in the gadget. These external feature files
would be handled just the same as internal feature.xml files, our
hyvescontainer feature file would be something like:
<feature>
<name>hyvescontainer</name>
<gadget>
<dependency>opensocial-0.7</dependency>
<script src="http://www.hyves-static.nl/opensocial/hyvescontainer.js
"/>
</gadget>
</feature>
(I have to admit, I'm not completely sure what else is possible in feature
files, possibly this would open up a security hole. The minimal
functionality needed is just what I mentioned above: some way to set
dependencies, and some way to include javascript)
Reinoud
Re: Shindig Hello World
Posted by John Hjelmstad <fa...@google.com>.
On Wed, Jan 30, 2008 at 5:40 AM, Reinoud Elhorst <cl...@claude.nl> wrote:
> Thanks for the replies and shared thoughts.
>
> You can see what I had to do in the sample container for this:
> >
> >
> http://svn.apache.org/repos/asf/incubator/shindig/trunk/javascript/samplecontainer/samplecontainer.html
>
>
> I didn't realize the sample container used a security token, I think that
> is
> indeed a good place to start.
>
> [...]
> > This will hopefully get easier in shindig over time as it supports more
> > and
> > more of opensocial. The first goal is to get a real opensocial container
> > running which gets data from the server (vs the mock data in the sample
> > container). I'm not sure if we can immediately add a js api for setting
> > the
> > opensocial container class (in the same way you set up the gadget js
> code)
> > but we can probably work on it.
>
> I indeed copied the opensocial-reference to opensocial-0.7, and added a
> new
> hyvescontainer feature. This works, but I need to specify in my gadget-xml
> a
>
>
> <Require feature="hyvescontainer" />
>
> line. this isn't a problem for now, but I was wondering how this would
> work
> in the "final" version. The only thing I could think of (especially in the
> case of a shared server that would server several different non-predefined
> containers, would be to add an url parameter to the iframe src, with an
> url
> to a feature.xml to use. I was just wondering whether this was right.
What does your hyvescontainer feature do/supply?
We're currently thinking about how a shared server can satisfy the needs of
several different containers when they have slightly different configuration
parameters, data formats, and so on. Container-mediated communication
(gadget-ifpc-to-container and back) is in many cases a viable solution since
it offloads container-specific logic to the container itself, but as
mentioned several times can have performance costs.
--John
>
>
> On 1/30/08, Brian Eaton <be...@google.com> wrote:
> >
> > - user logs in to the container
> > - container uses the GadgetServer to render the gadget in 'Container'
> > mode (which doesn't do much at the moment)
> > - container uses GadgetSigner (which I'm renaming to
> > GadgetTokenSigner) to create the security token for the gadget
>
> I guess this is only useful if the container site is in java as well. Our
> site is in PHP, so I guess I need to convert the GadgetSigner to PHP
> (probably make some people on the PHP branch happy by conrtributing it
> back
> :) ). Am I correct in seeing that there is no actual signing (so no actual
> security) in there at the moment?
>
> [...]
> >
> Sounds good to me
>
>
>
> On 1/30/08, Kevin Brown <et...@google.com> wrote:
> >
> >
> > Real production sites should always render the iframe on a different
> > domain
> > from the parent site This is critical for security. Without it, none of
> > the
> > other security solutions matter.
> >
>
> I was wondering about that. Obviously a separate domain is needed to
> protect
> the parent container page from the gadget, does this also protect gadgets
> from each other (in case multiple gadgets are put on one page)?
>
Re: Shindig Hello World
Posted by Reinoud Elhorst <cl...@claude.nl>.
Thanks for the replies and shared thoughts.
You can see what I had to do in the sample container for this:
>
> http://svn.apache.org/repos/asf/incubator/shindig/trunk/javascript/samplecontainer/samplecontainer.html
I didn't realize the sample container used a security token, I think that is
indeed a good place to start.
[...]
> This will hopefully get easier in shindig over time as it supports more
> and
> more of opensocial. The first goal is to get a real opensocial container
> running which gets data from the server (vs the mock data in the sample
> container). I'm not sure if we can immediately add a js api for setting
> the
> opensocial container class (in the same way you set up the gadget js code)
> but we can probably work on it.
I indeed copied the opensocial-reference to opensocial-0.7, and added a new
hyvescontainer feature. This works, but I need to specify in my gadget-xml a
<Require feature="hyvescontainer" />
line. this isn't a problem for now, but I was wondering how this would work
in the "final" version. The only thing I could think of (especially in the
case of a shared server that would server several different non-predefined
containers, would be to add an url parameter to the iframe src, with an url
to a feature.xml to use. I was just wondering whether this was right.
On 1/30/08, Brian Eaton <be...@google.com> wrote:
>
> - user logs in to the container
> - container uses the GadgetServer to render the gadget in 'Container'
> mode (which doesn't do much at the moment)
> - container uses GadgetSigner (which I'm renaming to
> GadgetTokenSigner) to create the security token for the gadget
I guess this is only useful if the container site is in java as well. Our
site is in PHP, so I guess I need to convert the GadgetSigner to PHP
(probably make some people on the PHP branch happy by conrtributing it back
:) ). Am I correct in seeing that there is no actual signing (so no actual
security) in there at the moment?
[...]
>
Sounds good to me
On 1/30/08, Kevin Brown <et...@google.com> wrote:
>
>
> Real production sites should always render the iframe on a different
> domain
> from the parent site This is critical for security. Without it, none of
> the
> other security solutions matter.
>
I was wondering about that. Obviously a separate domain is needed to protect
the parent container page from the gadget, does this also protect gadgets
from each other (in case multiple gadgets are put on one page)?
Re: Shindig Hello World
Posted by Cassie <do...@apache.org>.
On Tue, Jan 29, 2008 at 5:39 PM, Reinoud Elhorst <cl...@claude.nl> wrote:
> Hi all,
>
> In the process of trying to make Hyves an OpenSocial container, I tried my
> hand tonight at making the Hello World OpenSocial Gadget example work in
> our
> site, through Shindig. I ran into some small issues, which I rather
> "hacked"
> my way around. Now I understand that Shindig is work in progress, and
> don't
> blame anyone for this not being s finished product. Au contraire, I was
> pleasantly surprised by how far I've come in just one night: thumbs up for
> the readability and documentation of most of the code, and obviously the
> lavish explanations I've been able to enjoy on this list!
>
> I hope someone can give some feedback on the following issues:
> - I included the js and css files from the /javascript/container
> directory
> into the parent page. When copying the code from the sample files, there
> are
> some options I'm missing in the gadgets.js file. It seems to me that the
> result of gadgets.container.createGadget, should have methods to set the
> "nocache=1" and the security token (or just generally, everything behind
> the
> #). Am I thinking in the right direction here, or is this being handled in
> some other way?
You can see what I had to do in the sample container for this:
http://svn.apache.org/repos/asf/incubator/shindig/trunk/javascript/samplecontainer/samplecontainer.html
In line 71 - 93 I basically make my own overriding gadget class and change
the getIframeUrl method to do what I want it to do.
This doesn't involve any gross hacking, but we could make this a little
cleaner though by giving a more obvious hook.
>
>
> - The opensocial part consists of a lot of general javascript, and some
> container-specific javascript. How does shindig know where to get this
> container specific javascript? Would this done in a call to the result of
> gadgets.container.createGadget as well?
Right now what you need to do is drop in some code to the shindig features
directory. More specifically, shindig currently does not response to the
opensocial requires tags that it should, like "opensocial-0.7". You would
need to create this directory in your copy of shindig, create a
features.xmlfile which included your javascript class which extends
the opensocial
container.js file, and then shindig would know what to do. (I can go into
more detail here if you haven't already done this)
This will hopefully get easier in shindig over time as it supports more and
more of opensocial. The first goal is to get a real opensocial container
running which gets data from the server (vs the mock data in the sample
container). I'm not sure if we can immediately add a js api for setting the
opensocial container class (in the same way you set up the gadget js code)
but we can probably work on it.
I hope that helps!
Nice work on getting your server up.
- Cassie
>
> - For the ifpc to work correctly, the ifpc_relay.html file has to be
> present
> on the same domain as the parent page is on (so, basically, your SNS
> domain). Is there any documentation yet on what the security implications
> of
> this are?
>
>
>
> Presently, I'm at the point where pretty much everything works except for
> the API calls back to the site; I wanted to make sure I was going in the
> right direction with regard to the exchange of the security token.
>
> Thanks,
>
> Reinoud Elhorst
> Hyves Senior Developer
>