I believe the container token also needed by common container to make rpc call to server to get gadget metadata in the navigate scenario.
- 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? >> >> >> >
