No I plan to keep that. That method is to set up the schedule to refresh gadget tokens. There's no management at all of container tokens :(
Also, it's possible to arrive in a situation where gadget tokens are expired and could not be refreshed because the container token is expired and the page is pretty much dead because the next refresh timer isn't for 20 minutes or so. Rendering a gadget in that window gives you an error page instead of trying to refresh tokens immediately when the CommonContainer could know that the token is bad. This scenario mostly happens when the user's session has expired (like the machine has been left on for hours) the tokens try to refresh, but eventually they fail due to expired user session. The container pages in shindig do not exhibit this problem because they don't have user sessions. protecting the container page content. From: Henry Saputra <henry.sapu...@gmail.com> To: dev@shindig.apache.org, Date: 12/12/2011 02:33 PM Subject: Re: CommonContainer token refresh changes 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? > > > >
