I'm going to add you to my rolling review that I have going. :) > I'm assuming you mean that they need to write a refresh mechanism from > the ground up for the container token, right?
Yes, sorry about that poor wording. > 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. I think I need my memory refreshed on what kind of scenario you guys have, and to step back a bit from the forest to see the trees. So far I've implemented a system for allowing for container token refresh. If you don't provide the optional fetch function, then the refresh should be a no-op. I'm curious though what that means for gadget tokens. Do your tokens just never expire? > +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). I'd be more than happy to get help in this area. Especially since you've been digging around here already :) > >* 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. There's some code in the container's service object (I hate that thing) that does metadata refresh and I'd like to wrap the call to get metadata in the call to ensure the container token is valid, but there's no reference to the actual container object... So for now, I've tried wrapping the navigate call itself... but it's breaking js tests. Do we have any good story/method for doing async js tests? "Ciancetta, Jesse E." <jc...@mitre.org> wrote on 12/14/2011 09:09:09 AM: > From: "Ciancetta, Jesse E." <jc...@mitre.org> > To: "dev@shindig.apache.org" <dev@shindig.apache.org>, > Date: 12/14/2011 09:10 AM > Subject: RE: CommonContainer token refresh changes > > >-----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? > > > > > > >
