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> 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> 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 >> >> >> >>
