AFAIK there is already a time interval based security token refresh from common container via osapi.container.Container.prototype.scheduleRefreshTokens_ ?
It will later visited each gadget site and call rpc update_security_token to the iframe to update the ST. Is the approach you proposed is different from what already exist? - Henry On Mon, Dec 12, 2011 at 11:20 AM, Dan Dumont <ddum...@us.ibm.com> wrote: > Wow that didn't keep any of my formatting. Let me clean some of that up. > > Our concerns are: > > * The current implementation only deals with refreshing the gadget tokens. > Every implementer of the CommonContainer needs to write a refresh > mechanism from the ground up. > * There's no way to force all tokens to refresh. > * If there are expired tokens and an operation requiring a valid security > token is performed (like navigate in the case of a cached metadata and an > expired token), the operation will fail rather than wait until a valid > token could be obtained. > > I'd like to propose rewriting the refresh implementation to allow for UX > improvements w.r.t. expired tokens. > > * Allow containers to register a function that can be used by the > CommonContainer to get a new container security token. The > CommonContainer code will use this when it needs to refresh a container > token. Container token refreshes will now be managed by the > CommonContainer code using the supplied function. > * Expose a new API that will allow the container to force the > CommonContainer code to refresh tokens (optionally specify which to > refresh 'container'|'gadgets'|[list-of-gadget-urls]) > * Introduce a new callback in the render chain of a gadget that will > attempt to refresh tokens (if needed!) and delay the rendering of a gadget > until the new token is found. > > > > From: Dan Dumont/Westford/IBM@Lotus > To: dev@shindig.apache.org, > Date: 12/12/2011 02:17 PM > Subject: CommonContainer token refresh changes > > > > Recently we have noticed some shortcomings with the common container > around the current implementation of security token refreshes. > Our concerns are: > > The current implementation only deals with refreshing the gadget tokens. > Every implementer of the CommonContainer needs to write a refresh > mechanism from the ground up. > There's no way to force all tokens to refresh. > If there are expired tokens and an operation requiring a valid security > token is performed (like navigate in the case of a cached metadata and an > expired token), the operation will fail rather than wait until a valid > token could be obtained. > > I'd like to propose rewriting the refresh implementation to allow for UX > improvements w.r.t. expired tokens. > > Allow containers to register a function that can be used by the > CommonContainer to get a new container security token. The > CommonContainer code will use this when it needs to refresh a container > token. Container token refreshes will now be managed by the > CommonContainer code using the supplied function. > Expose a new API that will allow the container to force the > CommonContainer code to refresh tokens (optionally specify which to > refresh 'container'|'gadgets'|[list-of-gadget-urls]) > Introduce a new callback in the render chain of a gadget that will attempt > > to refresh tokens (if needed!) and delay the rendering of a gadget until > the new token is found. > > Any thoughts on these changes? Any suggestions? > Are there any other APIs that you can think of that would benefit by this > new functionality? > > > >
