Gary As far as a rendered gadget is concerned the security token should be entirely opaque, it should only be interpretable by the Shindig gadgets renderer and opensocial REST/RPC APis. The BasicSecurityToken class used in the Shindig samples should not be used in real life. Take a look at BlobCrypterSecurityToken and BlobCrypterSecurityTokenDecoder. Your container needs to generate a token in the form the bound SecurityTokenDecoder expected in Shinding and add it to the iframe URL at render time or by passing it in the params to gadgets.Gadget constructor from gadgets.js.
Hope that helps -Louis On Thu, Mar 12, 2009 at 7:23 AM, Gary Stevens <[email protected]> wrote: > Hello all, > > I have been working on my own openSocial container to work with shindig. I > would like to specify my own security token for my container, but I have > not found a way to do it other than hardcoding the values I want for owner > and viewer into the secureToken variable inside of gadgets.js. I have > tried implementing my own feature to replace the security token, but hit a > dead end because each gadget loads in its own IFrame and I cannot access > secureToken from the container. Has anyone else figured this out that can > point me in the right direction? > > Thank you, > Gary F Stevens ([email protected]) > Emerging Standards , IBM Software Group
