shindig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Dumont" <>
Subject Re: getModuleId
Date Fri, 27 Jan 2012 14:33:34 GMT
I had assumed you meant the navigate chain of calls.   The metadata call 
doesn't deal with specific moduleIds, and in fact I've been talking to 
Jesse about removing the security token from the metadata response if we 
can figure out a sane way to bundle the token request and metadata request 
together (it's possible)

From:   Dan Dumont/Westford/IBM@Lotus
Date:   01/27/2012 09:31 AM
Subject:        Re: getModuleId

The container wishing to navigate a gadget to a saved instance, a new 
saved instance, or the default unsaved instance of 0.

From:   Henry Saputra <>
Date:   01/27/2012 02:16 AM
Subject:        Re: getModuleId


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 <> 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 
> moduleId rather than the siteId.  The moduleId is baked in the token and
> not something one could spoof with firebug.
> From:   daviesd <>
> To:     <>,
> Date:   01/23/2012 01:34 PM
> Subject:        Re: getModuleId
> In pref.js shindig was setting the Prefs moduleId to the "mid" 
> Perhaps something is different here now.  So for whatever reason that 
> 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.
> It would really be nice if the rpc requests used the gadget security 
> (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).
> 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 
> moduleId discussion.
> doug
> On 1/23/12 12:57 PM, "Dan Dumont" <> 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 
>> have.
>> I'm curious how you got numbers other than 0.  Especially for the
> security
>> token, moduleId was always 0 in shindig.
>> From:   daviesd <>
>> To:     shindig <>,
>> 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 
>> was
>> rendered into.
>> I haven¹t kept up with the whole moduleId/siteId patch that is going 
>> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message