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,
and then the rest of the updateContainerSecurityToken method executes.
That's probably why not providing a callback, or setting a timeout in your
callback is working. You're allowing updateContainerSecurityToken to
finish and actually call shindig.auth.updateSecurityToken via the refresh
method.
Hopefully that makes sense. :)
On Wed, Apr 8, 2015 at 2:20 PM, Davies,Douglas <davi...@oclc.org> wrote:
> 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 <davi...@oclc.org<mailto:
> davi...@oclc.org>> wrote:
>
> 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><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><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><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
>
>
>
>
>
>
>
>
>
