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
container.updateContainerSecurityToken(function() {
setTimeout(function(){
container.forceRefreshAllTokens();
}, 2000);
}, token, 1800);
Looking at the updateContainerSecurityToken code in service.js it looks like my
flow would fall through the “Token no expired, but needs refresh. Don’t block
operations that need a valid token). But as far as I can tell, that
immediately returns, but it’s cryptic after that.
osapi.container.Service.prototype.updateContainerSecurityToken =
function(callback, tokenOrWait, ttl) {
var undef,
now = osapi.container.util.getCurrentTimeMs(),
token = typeof(tokenOrWait) != 'boolean' && tokenOrWait || undef,
wait = typeof(tokenOrWait) == 'boolean' && tokenOrWait,
needsRefresh = containerTokenTTL &&
(fetching || token || !lastRefresh || now > lastRefresh +
containerTokenTTL);
if (needsRefresh) {
// Hard expire in 95% of originial ttl.
var expired = !lastRefresh || now > lastRefresh + (containerTokenTTL * 95
/ 80);
if (!expired && callback) {
// Token not expired, but needs refresh. Don't block operations that
need a valid token.
callback();
} else if (callback) {
// We have a callback, there's either a fetch happening, or we
otherwise need to refresh the
// token. Place it in the callbacks queue to be run after the fetch
(currently running or
// soon to be launched) completes.
callbacks.push(callback);
}
if (token) {
// We are trying to set a token initially. Run refresh with a
fetch_once function that simply
// returns the canned values. Then schedule the refresh using the
function in the config
refresh.call(this, function(result) {
result(token, ttl);
});
} else if (!fetching && !wait) {
// There's no fetch going on right now. Unless wait is true, we need to
start one right away
// because the token needs a refresh.
// If wait is true, the callback really just wants a valid token. It
may be called with an
// error for informational purposes, but it's likely the callback will
simply queue up
// immediately if there was an error. To avoid spamming the refresh
method, we allow them to
// specify `wait` so that it can wait for success without forcing a
fetch.
refresh.call(this);
}
} else if (callback) {
// No refresh needed, run the callback because the token is fine.
callback();
}
};
})();
doug
On Apr 8, 2015, at 1:55 PM, Davies,Douglas
<davi...@oclc.org<mailto:davi...@oclc.org>> wrote:
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 return immediately and
continue to refresh the token in the background. Not sure. I’ll keep ya
posted.
doug
On Apr 8, 2015, at 1:44 PM, Stanton Sievers
<ssiev...@apache.org<mailto:ssiev...@apache.org>> wrote:
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 old
viewer id baked-in. Forcing the refresh will re-issue all of your gadget
tokens with the new viewer id.
I hope that helps!
-Stanton
On Wed, Apr 8, 2015 at 1:27 PM, Davies,Douglas
<davi...@oclc.org<mailto:davi...@oclc.org>> wrote:
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 noticed it does something similar in it’s container
I have a container where I can dynamically change the Person for testing.
So I update the container token, but it seems like subsequent services
requests (for example people.get) continue to use a token for the previous
Person.
Ideas? Hope this makes sense.
doug
