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" <davi...@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 <ssiev...@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 <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
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
>
>
>
