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?