>-----Original Message----- >From: Henry Saputra [mailto:[email protected]] >Sent: Wednesday, December 14, 2011 11:02 AM >To: [email protected] >Subject: Re: CommonContainer token refresh changes > >I believe the container token also needed by common container to make >rpc call to server to get gadget metadata in the navigate scenario.
Good point -- I'd forgotten about that. Although in our use case we push the gadget metadata down to the client and into the common container instance directly (to avoid the need to make XHR calls back to shindig to fetch it) -- more details on that in the response I just sent to Dan in another thread. > >- Henry > >On Wed, Dec 14, 2011 at 6:09 AM, Ciancetta, Jesse E. <[email protected]> >wrote: >>>-----Original Message----- >>>From: Dan Dumont [mailto:[email protected]] >>>Sent: Monday, December 12, 2011 2:21 PM >>>To: [email protected] >>>Subject: Re: CommonContainer token refresh changes >>> >>>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. >> >> I'm assuming you mean that they need to write a refresh mechanism from >the ground up for the container token, right? >> >> That may be true -- but only for implementers who use container tokens. If >I recall from the last time I dug around in the code the container token is >really >only needed to support gadget token requests back to shindig, and for >implementers who are providing their own token management infrastructure >as part of their container implementation there is no need for the concept of >a container token. >> >> So I guess the point is that we just need to remember that not all containers >use a container token so any code we put in place to refresh container tokens >needs to be smart enough to only attempt to do so if there is a container >token already registered. >> >>>* 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. >> >> +1 >> >>>* 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]) >> >> +1 -- except that a list of raw gadget urls alone isn't enough. So this >> starts to >get back to the work I was doing a few months ago to get proper moduleId >support into the common container code -- I think if we're going to crack open >the security token code we should go ahead and get it updated to properly >support moduleId's (and I'll be happy to help make that happen). >> >>>* 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. >> >> That sounds familiar -- I think I did that already when I was doing the >moduleId work a couple of months ago. >> >> I'll plan to dust off that patch today and get it integrated back into trunk >> and >put it back out on the review board so we can have another look at it. >> >> I think the roadblock with it last time was that we weren't sure that we >wanted to treat the siteId as the moduleId because you guys had some kind >of use case where existing gadgetSite's were re-used to render different >gadgets. Does that sound about right? >> >>> >>> >>>From: Dan Dumont/Westford/IBM@Lotus >>>To: [email protected], >>>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? >>> >>> >>> >>
