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
