You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "Ciancetta, Jesse E." <jc...@mitre.org> on 2011/10/04 18:24:47 UTC
RE: Review Request: Common container currently doesnt include the
siteId (moduleId) in any of it's security token processing/handling
>-----Original Message-----
>From: Ryan J Baxter [mailto:rjbaxter@us.ibm.com]
>Sent: Friday, September 30, 2011 4:01 PM
>To: dev@shindig.apache.org
>Cc: Stanton Sievers
>Subject: RE: Review Request: Common container currently doesnt include the
>siteId (moduleId) in any of it's security token processing/handling
>
>Couldn't I reuse a site though? So if I have one gadget rendered in a
>site and then I close it and reuse that site to render a new gadget
>wouldn't both gadgets then have the same module id? Or maybe that doesn't
>matter since you closed the original gadget....
I think in the use case your describing it wouldn't matter. In that case it sounds like you probably don't have a persistent ID associated with the gadgets in question and therefore don't really have any use for moduleId's anyway -- so what ends up being used for the siteId and moduleId probably doesn't matter much.
But I think the most common rendering strategy for containers which do persist gadgets on a per user basis (and folks in the community -- please feel free to jump in and correct me if I'm wrong) is to render those gadgets inside of some container element which is keyed by the gadget instance ID, or moduleId. This makes lots of other code much easier to deal with since you know that if the user is trying to do X with gadget ID 1234, you can find that gadget in the DOM under an element with ID gadget_container_1234.
Take iGoogle as an example -- on one of my gadgets there I see a div wrapping the whole gadget with ID "home_gadget_box31" and inside of that I see an iframe with ID "remote_iframe_31" -- and no matter where I move that gadget or how many times I reload the page that ID stays the same. We do the same thing in Apache Rave and I've seen that same strategy used in other places as well.
So I think in any case where you have a persistent ID that you'd like used as the moduleId your also going to want to have it used in your gadget site element ID and your gadget iframe ID, and in cases where you don't it shouldn't make much difference either way.
>-Ryan
>
>Email: rjbaxter@us.ibm.com
>Phone: 978-899-3041
>developerWorks Profile
>
>
>
>From: "Ciancetta, Jesse E." <jc...@mitre.org>
>To: "dev@shindig.apache.org" <de...@shindig.apache.org>,
>Cc: Stanton Sievers/Westford/IBM@Lotus
>Date: 09/30/2011 10:51 AM
>Subject: RE: Review Request: Common container currently doesnt
>include the siteId (moduleId) in any of it's security token
>processing/handling
>
>
>
>>-----Original Message-----
>>From: Ryan J Baxter [mailto:rjbaxter@us.ibm.com]
>>Sent: Thursday, September 29, 2011 1:54 PM
>>To: Ciancetta, Jesse E.
>>Cc: dev@shindig.apache.org; Stanton Sievers
>>Subject: RE: Review Request: Common container currently doesnt include
>the
>>siteId (moduleId) in any of it's security token processing/handling
>>
>>I was having trouble trying to grasp a lot of the changes but one of the
>>over arching questions I have is does a module id necessarily equal a
>site
>>id? Could a module id be something else?
>
>Maybe -- although they seemed close enough to me that I considered them
>to
>be one and the same. It seemed to me that siteId was used to represent a
>particular gadget instance, and that's exactly what moduleId is used for
>as well.
>
>ModuleId's really come into play when you have a container that stores a
>particular set of gadgets for a particular user in a persistent store. In
>that case it's nice to have some consistent identifier associated with
>each of those gadget instances that doesn't change across page renders,
>when the gadget is moved to a different position on the page, when the
>gadget instance is moved to a different tab/page, etc, and moduleId is
>used as that identifier inside of the security token.
>
>The best use case I can think of where moduleId's are used in Shindig is
>for persisting/fetching oAuth tokens. oAuth tokens are stored on a per
>user/per gadget instance basis -- and the moduleId pulled from the
>SecurityToken is what's used as the identifier for the gadget instance.
>
>>-Ryan
>>
>>Email: rjbaxter@us.ibm.com
>>Phone: 978-899-3041
>>developerWorks Profile
>>
>>
>>
>>From: "Ciancetta, Jesse E." <jc...@mitre.org>
>>To: Ryan J Baxter/Westford/IBM@Lotus, "dev@shindig.apache.org"
>><de...@shindig.apache.org>, Stanton Sievers/Westford/IBM@Lotus,
>>Date: 09/29/2011 11:34 AM
>>Subject: RE: Review Request: Common container currently doesnt
>>include the siteId (moduleId) in any of it's security token
>>processing/handling
>>
>>
>>
>>Sounds good -- thanks Ryan.
>>
>>Just to clarify though -- I'm not necessarily suggesting that these
>>changes actually get applied as is -- I'm really more looking to start a
>>discussion around this as one possible solution to the problem. This is
>>the simplest set of changes I could come up with to get moduleId's into
>>common container, but with it comes some additional baggage in the form
>of
>>new nested callbacks when navigating a gadget.
>>
>>A better way to resolve it might be to refactor the rendering process
>>further to do any potentially XHR causing work (like fetching gadget
>>metadata and gadget tokens) in the same place during rendering to
>>eliminate the deeper nest of chained callbacks that the current patch
>>introduces, but of course that's more work with more significant changes
>>and I'm not sure which way the community would prefer to go with this.
>>
>>Looking forward to feedback and discussion from Stanton and others.
>>
>>--Jesse
>>
>>From: Ryan J Baxter [mailto:rjbaxter@us.ibm.com]
>>Sent: Wednesday, September 28, 2011 5:55 PM
>>To: dev@shindig.apache.org; Stanton Sievers
>>Cc: Ciancetta, Jesse E.
>>Subject: Re: Review Request: Common container currently doesnt include
>the
>>siteId (moduleId) in any of it's security token processing/handling
>>
>>Jesse, I know Stanton has been looking at some of this code lately and
>>might be a good person to take a look at your suggested changes. He is
>>out on vaca until next Tuesday but I can see if he can take a look when
>he
>>gets back.
>>
>>-Ryan
>>
>>Email: rjbaxter@us.ibm.com
>>Phone: 978-899-3041
>>developerWorks Profile
>>
>>
>>
>>From: "Jesse Ciancetta" <jc...@mitre.org>
>>To: "shindig" <de...@shindig.apache.org>, "Jesse Ciancetta"
>><jc...@mitre.org>,
>>Date: 09/28/2011 03:39 PM
>>Subject: Re: 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/
>>-----------------------------------------------------------
>>
>>(Updated 2011-09-28 19:36:42.867006)
>>
>>
>>Review request for shindig.
>>
>>
>>Changes
>>-------
>>
>>I've attached an updated patch which has been realigned with the current
>>shindig trunk.
>>
>>More details can be found in the review description and previous
>comments.
>>
>>I would very much appreciate some feedback on this patch.
>>
>>Thanks!
>>
>>
>>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!
>>
>>
>>This addresses bugs RAVE-198 and SHINDIG-1611.
>> https://issues.apache.org/jira/browse/RAVE-198
>> https://issues.apache.org/jira/browse/SHINDIG-1611
>>
>>
>>Diffs (updated)
>>-----
>>
>>
>>
>http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/
>
>>features/container/service.js1176946
>>
>>
>>
>http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/
>
>>features/container.util/util.js1176946
>>
>>
>>
>http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/
>
>>features/container/container.js1176946
>>
>>
>>http://svn.apache.org/repos/asf/shindig/trunk/content/samplecontainer/e
>x
>>amples/commoncontainer/assembler.js1176946
>>
>>
>>
>http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/
>
>>features/container.gadget/gadget_site.js1176946
>>
>>
>>
>http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/f
>
>>eatures/container/gadget_site_test.js1176946
>>
>>
>>
>http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/f
>
>>eatures/container/service_test.js1176946
>>
>>
>>http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java
>/
>>org/apache/shindig/gadgets/servlet/GadgetsHandler.java1176946
>>
>>
>>http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java
>/
>>org/apache/shindig/gadgets/servlet/GadgetsHandlerApi.java1176946
>>
>>
>>http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java
>/
>>org/apache/shindig/gadgets/servlet/GadgetsHandlerService.java1176946
>>
>>
>>Diff: https://reviews.apache.org/r/1632/diff
>>
>>
>>Testing
>>-------
>>
>>
>>Thanks,
>>
>>Jesse
>>
>>
>>
>>
>
>
>