>-----Original Message----- >From: Dan Dumont [mailto:ddum...@us.ibm.com] >Sent: Monday, December 12, 2011 2:21 PM >To: dev@shindig.apache.org >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: 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? > > >
