Stanton,
Let me give that some thought today (wrap my head around the flow).
Looking through some archived messages I see a thread where it was discussed
whether a gadget needed to do something to refresh an expired security token.
It seems to me that is taken care of automatically and the
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
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,
