>-----Original Message----- >From: Dan Dumont [mailto:ddum...@us.ibm.com] >Sent: Wednesday, December 14, 2011 9:25 AM >To: dev@shindig.apache.org >Subject: RE: CommonContainer token refresh changes > >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?
Our gadget tokens do expire, but we don't fetch them from shindig -- we fetch them from our container implementation directly (which is a completely separate web application from Shindig entirely). So in our case we don't have any use for a container token at all. Here is a quick and simplified rundown of our rendering process: -- An HTTP request comes in to render a given page for a given user -- We fetch their page from the DB and then enumerate all of the gadgets on the page -- for each gadget we: ++++ Mint a security token ++++ Make a server-side call to shindig to fetch the gadget metadata -- We then embed all of the tokens/metadata into the HTTP response we send down to the client -- On the client side we initialize a common container object -- Push the pre-generated tokens and pre-fetched metadata into the container instance -- Enumerate each gadget and ask common container to render it -- Since common container already has a gadget token and metadata there is no need for any XHR calls back to shindig to fetch anything (and therefore no need for a container token) For gadget token refresh the XHR will be made from the container page back to the container application (which is all same domain XHR) and since the user is logged into the container application we know who they are and can generate updated security tokens for them. >> +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? >> > >> > >> > >> >
