You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@shindig.apache.org by "Davies,Douglas" <da...@oclc.org> on 2011/07/05 20:28:36 UTC
Security Tokens
I'm trying to figure out the whole security token flow using common
container. Here's what I'm thinking.
Container set security token to specify who I am (
shindig.auth.updateSecurityToken('owner:viewer:appid:cont:url:0:default'
) ).
Container makes call to get metadata.
The meta data request uses this value in DefaultIframeUriManager to
generate a security token and pass it back on the iframe url (via the st
parameter) that is returned from the metadata request.
This st param is then passed to any subsequent makeRequest, appData,
userPref, etc. calls made from the gadget.
I set gadgets.uri.iframe.alwaysAppendSecurityToken in container.js to
make sure the security token is always returned. I also thought at one
point all the subsequent makeRequest calls automatically had the st
param set, but I'm not seeing that with 3.0.0 beta 2. Strange... st is
empty.
I haven't even gotten to oauth and how it fits into all this. Right now
I'm just trying to figure out how to convey the current user to the
container and make sure all makeRequest, appData, userPref, etc. calls
have the correct context. I also haven't tackled any encryption yet.
Right now I'm just trying to get this working in clear text.
Any help is appreciated.
Doug
RE: Security Tokens
Posted by Justin Wyllie <ju...@hotmail.co.uk>.
Hi Doug
I don't know if this helps or is the correct way but what we did was log the user in on our main server using the usual authentication mechanism and then built our own token using the same libraries which I'd copied across from the shindig server to our main one. I just found the code in shindig which builds a token and copied that basically. This token I then built onto the url of the gadget iframes (which we were rendering on the server - but this would work if you were rendering them client-side as well as you could just pass the token as a Javascript variable) and now when the iframe was rendered in the page and made a call to the shindig server the token was on the url - decoded by Shindig and validated.
Justin
> Subject: RE: Security Tokens
> Date: Thu, 7 Jul 2011 09:35:18 -0400
> From: daviesd@oclc.org
> To: users@shindig.apache.org
>
> Agustin,
>
> In my case the shindig server does not have access to the session. It's in a different domain/host. So I'm looking for the correct way to communicate the current user to the shindig server. I thought this would happen on the metadata call via the st param. The server would then use this to generate st tokens for return on the iframe urls. Then any subsequent requests from the gadgets would pass this along so that the server has some key (userid/viewer) to use for things like appdata, userprefs, etc. Again... I might be totally confused on this. It just seems I have to have some way to tell the container who I am and all I have is the shindig javascript apis to do this with.
>
> Thanks,
> doug
>
> -----Original Message-----
> From: Agustin Casiva [mailto:casivaagustin@gmail.com]
> Sent: Thursday, July 07, 2011 7:04 AM
> To: users@shindig.apache.org
> Subject: Re: Security Tokens
>
> >
> > I haven't even gotten to oauth and how it fits into all this. Right now
> > I'm just trying to figure out how to convey the current user to the
> > container and make sure all makeRequest, appData, userPref, etc. calls
> > have the correct context. I also haven't tackled any encryption yet.
> > Right now I'm just trying to get this working in clear text.
> >
>
> Hi Doug, the secure token used on the Container context haven't nothing
> related with Oauth, this sounds
> a little bit confusing but it's like that.
>
> The secure token is a "package" of information used between the gadget and
> the social container to share
> some specific data (defined by the creator of the Social Container) like
> AppId, moduleId, Views, etc.
>
> This secure token can be encrypted or not, (see plain tokens options in the
> configuration files).
>
> The authorization an authentication of the request is handled by the user
> session, the secure token doesn't have
> that responsibility.
>
> I hope this help you.
>
> Regards
>
> --
> Ing. Casiva Agustin
>
> Mail/Msn/GTalk/Jabber: casivaagustin@gmail.com
> Skype: casivaagustin
> CEL : 054-03722-15270639
> Site: http://www.casivaagustin.com.ar
RE: Security Tokens
Posted by "Davies,Douglas" <da...@oclc.org>.
Agustin,
In my case the shindig server does not have access to the session. It's in a different domain/host. So I'm looking for the correct way to communicate the current user to the shindig server. I thought this would happen on the metadata call via the st param. The server would then use this to generate st tokens for return on the iframe urls. Then any subsequent requests from the gadgets would pass this along so that the server has some key (userid/viewer) to use for things like appdata, userprefs, etc. Again... I might be totally confused on this. It just seems I have to have some way to tell the container who I am and all I have is the shindig javascript apis to do this with.
Thanks,
doug
-----Original Message-----
From: Agustin Casiva [mailto:casivaagustin@gmail.com]
Sent: Thursday, July 07, 2011 7:04 AM
To: users@shindig.apache.org
Subject: Re: Security Tokens
>
> I haven't even gotten to oauth and how it fits into all this. Right now
> I'm just trying to figure out how to convey the current user to the
> container and make sure all makeRequest, appData, userPref, etc. calls
> have the correct context. I also haven't tackled any encryption yet.
> Right now I'm just trying to get this working in clear text.
>
Hi Doug, the secure token used on the Container context haven't nothing
related with Oauth, this sounds
a little bit confusing but it's like that.
The secure token is a "package" of information used between the gadget and
the social container to share
some specific data (defined by the creator of the Social Container) like
AppId, moduleId, Views, etc.
This secure token can be encrypted or not, (see plain tokens options in the
configuration files).
The authorization an authentication of the request is handled by the user
session, the secure token doesn't have
that responsibility.
I hope this help you.
Regards
--
Ing. Casiva Agustin
Mail/Msn/GTalk/Jabber: casivaagustin@gmail.com
Skype: casivaagustin
CEL : 054-03722-15270639
Site: http://www.casivaagustin.com.ar
Re: Security Tokens
Posted by Agustin Casiva <ca...@gmail.com>.
>
> I haven't even gotten to oauth and how it fits into all this. Right now
> I'm just trying to figure out how to convey the current user to the
> container and make sure all makeRequest, appData, userPref, etc. calls
> have the correct context. I also haven't tackled any encryption yet.
> Right now I'm just trying to get this working in clear text.
>
Hi Doug, the secure token used on the Container context haven't nothing
related with Oauth, this sounds
a little bit confusing but it's like that.
The secure token is a "package" of information used between the gadget and
the social container to share
some specific data (defined by the creator of the Social Container) like
AppId, moduleId, Views, etc.
This secure token can be encrypted or not, (see plain tokens options in the
configuration files).
The authorization an authentication of the request is handled by the user
session, the secure token doesn't have
that responsibility.
I hope this help you.
Regards
--
Ing. Casiva Agustin
Mail/Msn/GTalk/Jabber: casivaagustin@gmail.com
Skype: casivaagustin
CEL : 054-03722-15270639
Site: http://www.casivaagustin.com.ar