I have a question about refreshing container and gadget security tokens.
When I call updateContainerSecurityToken on the container, do I then need to
call forceRefreshAllTokens for the gadgets?
I was looking at OpenSocial Explorer (http://opensocial.github.io/explorer —
Stanton and Ryan) and
DESCRIPTION
Apache Shindig is an Opensocial Reference implementation in wide use by
both social networks and enterprise software. Shindig graduated from the
Incubator in January 2010.
ISSUES
The Shindig PMC has no issues that require board attention.
COMMUNITY
The Shindig community has
Thanks Stanton. That’s what I am attempting to do, but it seems like I have to
go through the whole process twice before it “sticks”. I’m trying to determine
if there is a timing issue here. The code for the container refresh is really
cryptic to read. But it appears to me like it might
Hi Doug,
You should forceRefreshAllTokens. Treat the gadget security tokens like
they are derived from the container security token (because they are). The
gadget tokens in your case will have the old viewer id baked-in because
they were derived from the old container token which also had the
It would appear that if I call container.forceRefreshAllTokens() as follows,
the gadget tokens are still the old ones
container.updateContainerSecurityToken(function() {
container.forceRefreshAllTokens();
}, token, 1800);
if I put a delay, then it works
I got it to work. Not sure why I was using the callback flavor of
updateContainerSecurityToken. If I change to this
container.updateContainerSecurityToken(null, token, 1800);
container.forceRefreshAllTokens();
it works fine.
doug
On Apr 8, 2015, at 2:15 PM, Davies,Douglas
I'm not sure why non-callback approach would work any differently. I'm
wondering if you're getting into a situation where your container token is
flagged as needing a refresh, because you explicitly provide a new token,
but it's not expired. Thus, your callback executes immediately, finishes,
