Just to try to start some kind of dialog around this... Do people think it's important to have correct moduleId's in security tokens? And just to be clear -- I mean that as a real question -- I'm not trying to be flip... If people using common container are only using security tokens for fetching appdata (which isn’t scoped to a particular gadget instance) you might not care about moduleId's...
Thanks! --Jesse >-----Original Message----- >From: Jesse Ciancetta [mailto:jc...@mitre.org] >Sent: Wednesday, August 24, 2011 10:47 AM >To: shindig; Ciancetta, Jesse E. >Subject: Review Request: Common container currently doesnt include the >siteId (moduleId) in any of it's security token processing/handling > > >----------------------------------------------------------- >This is an automatically generated e-mail. To reply, visit: >https://reviews.apache.org/r/1632/ >----------------------------------------------------------- > >Review request for shindig. > > >Summary >------- > >Common container currently doesn't include the siteId (moduleId) in any of >it's security token processing/handling (all security tokens in common >container currently get minted with a moduleId of 0). > >This patch is a first (rough) cut at getting moduleId's into security tokens. >I am >posting it somewhat prematurely to solicit feedback before I invest any more >time in finishing up the last bits. Here are the things that I know are still >left to >do: > >-- Update unit tests on both the JS and Java side -- currently I've been >building >and deploying with skipTests=true... >-- Figure out a strategy for dealing with preloaded gadgets. The current auth- >refresh process maintains tokens for preloaded gadgets, however the preoad >JS functions just take a gadgetUrl so there is no concept of a siteId >(moduleId) >for them at this time. >-- Figure out how to get the token that is included in the original iframe to >include a moduleId. I think the token in the iframe likely comes back in the >metadata request (although I haven't looked yet to verify), which means that >the call to the metadata service would likely need to include the moduleId as >well. > >I'd greatly appreciate any comments people have on the patch and strategies >for dealing with the outstanding issues noted above. > >Thanks! > > >Diffs >----- > > >http://svn.apache.org/repos/asf/shindig/trunk/content/samplecontainer/ex >amples/commoncontainer/assembler.js 1148651 > >http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/ >features/container.gadget/gadget_site.js 1151535 > >http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/ >features/container.util/util.js 1150288 > >http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/ >features/container/container.js 1157893 > >http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/ >features/container/service.js 1158700 > >http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/ >org/apache/shindig/gadgets/servlet/GadgetsHandler.java 1098824 > >http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/ >org/apache/shindig/gadgets/servlet/GadgetsHandlerApi.java 1098824 > >http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/ >org/apache/shindig/gadgets/servlet/GadgetsHandlerService.java 1125606 > >Diff: https://reviews.apache.org/r/1632/diff > > >Testing >------- > > >Thanks, > >Jesse
