Mailing-List: contact dev-help@shindig.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@shindig.apache.org
Received-SPF: softfail (athena.apache.org: transitioning domain of
 ddumont@us.ibm.com does not designate 192.147.106.25 as permitted sender)
In-Reply-To: 
 <OF6FF4A965.C068307D-ON85257992.004F7E0A-85257992.004F8FEF@notesdev.ibm.com>
References: 
 <OF9C1D854B.765240BF-ON8525798E.00625221-8525798E.0062A884@notesdev.ibm.com>
	<CB431202.D402%daviesd@oclc.org>
	<OF6F2F7BCA.96080C9B-ON8525798E.0066567F-8525798E.0066F2C3@notesdev.ibm.com>
 <CALuGr6Z5R79zd0cSg5o6Y+VzGEeJQzx6cRcJ5MbzUikRqQDEVg@mail.gmail.com>
 <OF6FF4A965.C068307D-ON85257992.004F7E0A-85257992.004F8FEF@notesdev.ibm.com>
To: dev@shindig.apache.org
MIME-Version: 1.0
Subject: Re: getModuleId
From: "Dan Dumont" <ddumont@us.ibm.com>
Message-ID: 
 <OF1CD7B48C.707B123A-ON85257992.004FD118-85257992.004FFA33@notesdev.ibm.com>
Date: Fri, 27 Jan 2012 09:33:34 -0500
Content-Type: multipart/alternative;
 boundary="=_alternative 004FF9FF85257992_="

--=_alternative 004FF9FF85257992_=
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

I had assumed you meant the navigate chain of calls.   The metadata call=20
doesn't deal with specific moduleIds, and in fact I've been talking to=20
Jesse about removing the security token from the metadata response if we=20
can figure out a sane way to bundle the token request and metadata request =

together (it's possible)


From:   Dan Dumont/Westford/IBM@Lotus
To:     dev@shindig.apache.org,=20
Date:   01/27/2012 09:31 AM
Subject:        Re: getModuleId


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


From:   Henry Saputra <henry.saputra@gmail.com>
To:     dev@shindig.apache.org,=20
Date:   01/27/2012 02:16 AM
Subject:        Re: getModuleId


Dan,

In the Shindig code, who is responsible to set
"osapi.container.RenderParam.MODULE=5FID" in the render params for
services's getGadgetMetadata() function?

- Henry

On Mon, Jan 23, 2012 at 10:44 AM, Dan Dumont <ddumont@us.ibm.com> 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=5FPREFERENCES/SET=5FPREFERENCES impl should be getting the sitei=
d,
> 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=20
the
> moduleId rather than the siteId.  The moduleId is baked in the token and
> not something one could spoof with firebug.
>
>
> From:   daviesd <daviesd@oclc.org>
> To:     <dev@shindig.apache.org>,
> Date:   01/23/2012 01:34 PM
> Subject:        Re: getModuleId
>
>
>
> In pref.js shindig was setting the Prefs moduleId to the "mid"=20
parameter.
> Perhaps something is different here now.  So for whatever reason that=20
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=5FPREFERENCES and GET=5FPREFERENCES handlers).  I think I opened up t=
his
> 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=20
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=20
your
> moduleId discussion.
>
> doug
>
>
> On 1/23/12 12:57 PM, "Dan Dumont" <ddumont@us.ibm.com> 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=20
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 <daviesd@oclc.org>
>> To:     shindig <dev@shindig.apache.org>,
>> Date:   01/23/2012 12:51 PM
>> Subject:        getModuleId
>>
>>
>>
>> I have a gadget that was using
>>
>> var moduleId =3D 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=20
gadget
>> was
>> rendered into.
>>
>> I haven=B9t kept up with the whole moduleId/siteId patch that is going=20
on,
>> but
>> perhaps something has changed here and is not backwards compatible?
>>
>> Any ideas?  It=B9s been a while since I=B9ve played around with userprefs
> and
>> today was the first I noticed it wasn=B9t working.
>>
>> doug
>>
>
>
>


--=_alternative 004FF9FF85257992_=--