Dan, In the Shindig code, who is responsible to set "osapi.container.RenderParam.MODULE_ID" in the render params for services's getGadgetMetadata() function?
- Henry On Mon, Jan 23, 2012 at 10:44 AM, Dan Dumont <[email protected]> wrote: > Not a problem. > > mid is for the moduleId. (maybe it wasn't always so... but for > consistency sake it probably should remain so) > IIRC, Prefs.getModuleId returns the value in the ifr url 'mid' param. > > Your GET_PREFERENCES/SET_PREFERENCES impl should be getting the siteid, > which it can look up a gadget site with. > You can then determine the moduleId (which should be 0 for now). > > I agree, if the rpc requests do not pass the gadget's token along, they > probably should now. Most people will be wanting to key things off of the > moduleId rather than the siteId. The moduleId is baked in the token and > not something one could spoof with firebug. > > > From: daviesd <[email protected]> > To: <[email protected]>, > Date: 01/23/2012 01:34 PM > Subject: Re: getModuleId > > > > In pref.js shindig was setting the Prefs moduleId to the "mid" parameter. > Perhaps something is different here now. So for whatever reason that use > to > return me whatever I had as my siteId and now it doesn't. > > At any rate, this is a TEST gadget that is probably trying to access > something it shouldn't. When the userprefs are stored they are stored > using > the siteId granted by our container implementation (the container > registers > SET_PREFERENCES and GET_PREFERENCES handlers). I think I opened up this > ticket because of that. > > https://issues.apache.org/jira/browse/SHINDIG-1557 > > It would really be nice if the rpc requests used the gadget security token > (that would hopefully have the moduleId set now that you've implemented > that). > > So in my test gadget I don't know what the siteId is. For some reason I > was > calling Prefs().getModuleId (I think this thread suggests that). > > http://shindig-dev.markmail.org/thread/zyi2zvpn7akhrbi3 > > Is there another way for a gadget to know this? I realize implementing > moduleId would probably give me this (although a gadget doesn't really > know > what's in it's security token, but it can certainly pass it along to api > calls). > > Sorry if I'm muddying the waters. I should have been more active in your > moduleId discussion. > > doug > > > On 1/23/12 12:57 PM, "Dan Dumont" <[email protected]> wrote: > >> Hrmm... I don't recall moduleId ever being anything other than 0. >> >> The discussions have focused around what a moduleId is (a number that's >> baked into the security token, primarily used to identify saved > instances >> of a gadget) and what a siteId is ( a string value that's used in or as > an >> id attribute of a DOM element in the container ). The recent patches >> created a way to generate, save, and track moduleIds on the server, > should >> you choose to implement the bits, otherwise they return 0 as they always >> have. >> >> I'm curious how you got numbers other than 0. Especially for the > security >> token, moduleId was always 0 in shindig. >> >> >> >> From: daviesd <[email protected]> >> To: shindig <[email protected]>, >> Date: 01/23/2012 12:51 PM >> Subject: getModuleId >> >> >> >> I have a gadget that was using >> >> var moduleId = new gadgets.Prefs().getModuleId(); >> >> To get the current moduleId (siteId) of the gadget so that it could >> retrieve >> userprefs >> >> osapi.userprefs.get( { siteId : moduleId } ) >> >> This is now return 0 instead of the id I have for the element the gadget >> was >> rendered into. >> >> I haven¹t kept up with the whole moduleId/siteId patch that is going on, >> but >> perhaps something has changed here and is not backwards compatible? >> >> Any ideas? It¹s been a while since I¹ve played around with userprefs > and >> today was the first I noticed it wasn¹t working. >> >> doug >> > > >
