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: [email protected] > To: [email protected] > > 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:[email protected]] > Sent: Thursday, July 07, 2011 7:04 AM > To: [email protected] > 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: [email protected] > Skype: casivaagustin > CEL : 054-03722-15270639 > Site: http://www.casivaagustin.com.ar
