You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "Davies,Douglas" <da...@oclc.org> on 2015/04/08 19:27:01 UTC
container security tokens v.s. gadget security tokens
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
Re: container security tokens v.s. gadget security tokens
Posted by Stanton Sievers <ss...@apache.org>.
Yes Doug, I believe that summarizes the issue. Tokens don't normally
change viewer. The refresh is designed such that it aggressively uses
cached context while it does a refresh in the background. If it did not
certain operations would block waiting for a new token, impacting
performance.
Sent from a mobile device. Please forgive brevity or typos.
On Apr 9, 2015 9:00 AM, "Davies,Douglas" <da...@oclc.org> wrote:
> 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
> only reason I’m having to refresh here is because I’ve changed the
> container context?
>
> Thanks,
> doug
>
> On Apr 8, 2015, at 4:23 PM, Stanton Sievers <ss...@apache.org> wrote:
>
> > 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 <da...@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 <daviesd@oclc.org<mailto:
> >> daviesd@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 <daviesd@oclc.org<mailto:
> >> daviesd@oclc.org><ma...@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 <ssievers@apache.org
> <mailto:
> >> ssievers@apache.org><ma...@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 <daviesd@oclc.org
> <mailto:
> >> daviesd@oclc.org><ma...@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
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
>
>
>
Re: container security tokens v.s. gadget security tokens
Posted by "Davies,Douglas" <da...@oclc.org>.
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 only reason I’m having to refresh here is because I’ve changed the container context?
Thanks,
doug
On Apr 8, 2015, at 4:23 PM, Stanton Sievers <ss...@apache.org> wrote:
> 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 <da...@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 <daviesd@oclc.org<mailto:
>> daviesd@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 <daviesd@oclc.org<mailto:
>> daviesd@oclc.org><ma...@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 <ssievers@apache.org<mailto:
>> ssievers@apache.org><ma...@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 <daviesd@oclc.org<mailto:
>> daviesd@oclc.org><ma...@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
>>
>>
>>
>>
>>
>>
>>
>>
>>
Re: container security tokens v.s. gadget security tokens
Posted by Stanton Sievers <ss...@apache.org>.
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 <da...@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 <daviesd@oclc.org<mailto:
> daviesd@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 <daviesd@oclc.org<mailto:
> daviesd@oclc.org><ma...@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 <ssievers@apache.org<mailto:
> ssievers@apache.org><ma...@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 <daviesd@oclc.org<mailto:
> daviesd@oclc.org><ma...@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
>
>
>
>
>
>
>
>
>
Re: container security tokens v.s. gadget security tokens
Posted by "Davies,Douglas" <da...@oclc.org>.
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 <da...@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 <da...@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 <ss...@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 <da...@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
Re: container security tokens v.s. gadget security tokens
Posted by "Davies,Douglas" <da...@oclc.org>.
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 <da...@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 <ss...@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 <da...@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
Re: container security tokens v.s. gadget security tokens
Posted by "Davies,Douglas" <da...@oclc.org>.
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 <ss...@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 <da...@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
>>
>>
>>
>>
Re: container security tokens v.s. gadget security tokens
Posted by Stanton Sievers <ss...@apache.org>.
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 <da...@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
>
>
>
>