You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by daviesd <da...@oclc.org> on 2012/01/23 18:49:39 UTC
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
Re: getModuleId
Posted by Dan Dumont <dd...@us.ibm.com>.
Not a bad idea. I've never edited the wiki before. I'll start looking
into that.
From: Henry Saputra <he...@gmail.com>
To: dev@shindig.apache.org,
Date: 01/25/2012 01:47 AM
Subject: Re: getModuleId
Hi Dan, maybe good idea to add a Shindig wiki page to explain how to
hook the moduleid to siteId extractor for Shindig implementor after
your patch.
- Henry
On Mon, Jan 23, 2012 at 1:05 PM, Dan Dumont <dd...@us.ibm.com> wrote:
> The server side moduleId stuff is all there for you to implement however
> you want to persist gadget instances.
>
> It should be fairly flexible so that you can implement it many different
> ways. Just inject your implementation in place of shindig's module id
> manager
> I have a spec patch out there that specifies how to use the moduleId
> render param when navigating a gadget.
>
>
>
> From: daviesd <da...@oclc.org>
> To: <de...@shindig.apache.org>,
> Date: 01/23/2012 03:19 PM
> Subject: Re: getModuleId
>
>
>
> That's what I was kind of figuring. So can you tell me what state the
> moduleId stuff is at? Is it still under development or can I start
using
> it
> now? I hope we get another beta (or final 3.0.0 release) soon that has
> this
> and oauth2 in a stable state.
>
> doug
>
>
> On 1/23/12 3:16 PM, "Dan Dumont" <dd...@us.ibm.com> wrote:
>
>> Hrmm...
>>
>> I don't know if you'll be able to do this anymore until you hook up the
>> moduleId support.
>>
>>
>>
>> From: daviesd <da...@oclc.org>
>> To: <de...@shindig.apache.org>,
>> Date: 01/23/2012 03:08 PM
>> Subject: Re: getModuleId
>>
>>
>>
>> Like I said... An edge case... And probably not a real world use case.
>>
>> But my test gadget sets a bunch of userprefs and then it needs to
repull
>> the
>> values (from persistence) and make sure they've been set properly
(tests
> a
>> race condition we had).
>>
>> I was using osapi.userprefs.get to retrieve the values. Is there a
> gadget
>> way of triggering the get call that is in the container? I don't want
> to
>> just get the map that the container has, I need to reforce a read from
>> persistence.
>>
>> Hope that makes sense,
>> doug
>>
>>
>> On 1/23/12 3:00 PM, "Dan Dumont" <dd...@us.ibm.com> wrote:
>>
>>> I don't think so. In my opinion, the siteId is a purely container
>> piece
>>> of information.
>>> why do you need to get it inside the gadget?
>>>
>>>
>>>
>>> From: daviesd <da...@oclc.org>
>>> To: <de...@shindig.apache.org>,
>>> Date: 01/23/2012 02:57 PM
>>> Subject: Re: getModuleId
>>>
>>>
>>>
>>> I agree on everything you just stated.
>>>
>>> So my only outstanding question would be is anyone aware of a way for
a
>>> gadget to find out it's siteId (the id that was set on the element the
>>> gadget was rendered into)?
>>>
>>> Any yes, I'd like to see the rpc requests changed to use the gadget
>>> security
>>> token.
>>>
>>> doug
>>>
>>>
>>> On 1/23/12 1:44 PM, "Dan Dumont" <dd...@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_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 <da...@oclc.org>
>>>> To: <de...@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"
>>> 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" <dd...@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
>>> 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 <da...@oclc.org>
>>>>> To: shindig <de...@shindig.apache.org>,
>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
Re: getModuleId
Posted by Henry Saputra <he...@gmail.com>.
Hi Dan, maybe good idea to add a Shindig wiki page to explain how to
hook the moduleid to siteId extractor for Shindig implementor after
your patch.
- Henry
On Mon, Jan 23, 2012 at 1:05 PM, Dan Dumont <dd...@us.ibm.com> wrote:
> The server side moduleId stuff is all there for you to implement however
> you want to persist gadget instances.
>
> It should be fairly flexible so that you can implement it many different
> ways. Just inject your implementation in place of shindig's module id
> manager
> I have a spec patch out there that specifies how to use the moduleId
> render param when navigating a gadget.
>
>
>
> From: daviesd <da...@oclc.org>
> To: <de...@shindig.apache.org>,
> Date: 01/23/2012 03:19 PM
> Subject: Re: getModuleId
>
>
>
> That's what I was kind of figuring. So can you tell me what state the
> moduleId stuff is at? Is it still under development or can I start using
> it
> now? I hope we get another beta (or final 3.0.0 release) soon that has
> this
> and oauth2 in a stable state.
>
> doug
>
>
> On 1/23/12 3:16 PM, "Dan Dumont" <dd...@us.ibm.com> wrote:
>
>> Hrmm...
>>
>> I don't know if you'll be able to do this anymore until you hook up the
>> moduleId support.
>>
>>
>>
>> From: daviesd <da...@oclc.org>
>> To: <de...@shindig.apache.org>,
>> Date: 01/23/2012 03:08 PM
>> Subject: Re: getModuleId
>>
>>
>>
>> Like I said... An edge case... And probably not a real world use case.
>>
>> But my test gadget sets a bunch of userprefs and then it needs to repull
>> the
>> values (from persistence) and make sure they've been set properly (tests
> a
>> race condition we had).
>>
>> I was using osapi.userprefs.get to retrieve the values. Is there a
> gadget
>> way of triggering the get call that is in the container? I don't want
> to
>> just get the map that the container has, I need to reforce a read from
>> persistence.
>>
>> Hope that makes sense,
>> doug
>>
>>
>> On 1/23/12 3:00 PM, "Dan Dumont" <dd...@us.ibm.com> wrote:
>>
>>> I don't think so. In my opinion, the siteId is a purely container
>> piece
>>> of information.
>>> why do you need to get it inside the gadget?
>>>
>>>
>>>
>>> From: daviesd <da...@oclc.org>
>>> To: <de...@shindig.apache.org>,
>>> Date: 01/23/2012 02:57 PM
>>> Subject: Re: getModuleId
>>>
>>>
>>>
>>> I agree on everything you just stated.
>>>
>>> So my only outstanding question would be is anyone aware of a way for a
>>> gadget to find out it's siteId (the id that was set on the element the
>>> gadget was rendered into)?
>>>
>>> Any yes, I'd like to see the rpc requests changed to use the gadget
>>> security
>>> token.
>>>
>>> doug
>>>
>>>
>>> On 1/23/12 1:44 PM, "Dan Dumont" <dd...@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_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 <da...@oclc.org>
>>>> To: <de...@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"
>>> 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" <dd...@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
>>> 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 <da...@oclc.org>
>>>>> To: shindig <de...@shindig.apache.org>,
>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
Re: getModuleId
Posted by Dan Dumont <dd...@us.ibm.com>.
The server side moduleId stuff is all there for you to implement however
you want to persist gadget instances.
It should be fairly flexible so that you can implement it many different
ways. Just inject your implementation in place of shindig's module id
manager
I have a spec patch out there that specifies how to use the moduleId
render param when navigating a gadget.
From: daviesd <da...@oclc.org>
To: <de...@shindig.apache.org>,
Date: 01/23/2012 03:19 PM
Subject: Re: getModuleId
That's what I was kind of figuring. So can you tell me what state the
moduleId stuff is at? Is it still under development or can I start using
it
now? I hope we get another beta (or final 3.0.0 release) soon that has
this
and oauth2 in a stable state.
doug
On 1/23/12 3:16 PM, "Dan Dumont" <dd...@us.ibm.com> wrote:
> Hrmm...
>
> I don't know if you'll be able to do this anymore until you hook up the
> moduleId support.
>
>
>
> From: daviesd <da...@oclc.org>
> To: <de...@shindig.apache.org>,
> Date: 01/23/2012 03:08 PM
> Subject: Re: getModuleId
>
>
>
> Like I said... An edge case... And probably not a real world use case.
>
> But my test gadget sets a bunch of userprefs and then it needs to repull
> the
> values (from persistence) and make sure they've been set properly (tests
a
> race condition we had).
>
> I was using osapi.userprefs.get to retrieve the values. Is there a
gadget
> way of triggering the get call that is in the container? I don't want
to
> just get the map that the container has, I need to reforce a read from
> persistence.
>
> Hope that makes sense,
> doug
>
>
> On 1/23/12 3:00 PM, "Dan Dumont" <dd...@us.ibm.com> wrote:
>
>> I don't think so. In my opinion, the siteId is a purely container
> piece
>> of information.
>> why do you need to get it inside the gadget?
>>
>>
>>
>> From: daviesd <da...@oclc.org>
>> To: <de...@shindig.apache.org>,
>> Date: 01/23/2012 02:57 PM
>> Subject: Re: getModuleId
>>
>>
>>
>> I agree on everything you just stated.
>>
>> So my only outstanding question would be is anyone aware of a way for a
>> gadget to find out it's siteId (the id that was set on the element the
>> gadget was rendered into)?
>>
>> Any yes, I'd like to see the rpc requests changed to use the gadget
>> security
>> token.
>>
>> doug
>>
>>
>> On 1/23/12 1:44 PM, "Dan Dumont" <dd...@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_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 <da...@oclc.org>
>>> To: <de...@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"
>> 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" <dd...@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
>> 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 <da...@oclc.org>
>>>> To: shindig <de...@shindig.apache.org>,
>>>> 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
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
Re: getModuleId
Posted by daviesd <da...@oclc.org>.
That's what I was kind of figuring. So can you tell me what state the
moduleId stuff is at? Is it still under development or can I start using it
now? I hope we get another beta (or final 3.0.0 release) soon that has this
and oauth2 in a stable state.
doug
On 1/23/12 3:16 PM, "Dan Dumont" <dd...@us.ibm.com> wrote:
> Hrmm...
>
> I don't know if you'll be able to do this anymore until you hook up the
> moduleId support.
>
>
>
> From: daviesd <da...@oclc.org>
> To: <de...@shindig.apache.org>,
> Date: 01/23/2012 03:08 PM
> Subject: Re: getModuleId
>
>
>
> Like I said... An edge case... And probably not a real world use case.
>
> But my test gadget sets a bunch of userprefs and then it needs to repull
> the
> values (from persistence) and make sure they've been set properly (tests a
> race condition we had).
>
> I was using osapi.userprefs.get to retrieve the values. Is there a gadget
> way of triggering the get call that is in the container? I don't want to
> just get the map that the container has, I need to reforce a read from
> persistence.
>
> Hope that makes sense,
> doug
>
>
> On 1/23/12 3:00 PM, "Dan Dumont" <dd...@us.ibm.com> wrote:
>
>> I don't think so. In my opinion, the siteId is a purely container
> piece
>> of information.
>> why do you need to get it inside the gadget?
>>
>>
>>
>> From: daviesd <da...@oclc.org>
>> To: <de...@shindig.apache.org>,
>> Date: 01/23/2012 02:57 PM
>> Subject: Re: getModuleId
>>
>>
>>
>> I agree on everything you just stated.
>>
>> So my only outstanding question would be is anyone aware of a way for a
>> gadget to find out it's siteId (the id that was set on the element the
>> gadget was rendered into)?
>>
>> Any yes, I'd like to see the rpc requests changed to use the gadget
>> security
>> token.
>>
>> doug
>>
>>
>> On 1/23/12 1:44 PM, "Dan Dumont" <dd...@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_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 <da...@oclc.org>
>>> To: <de...@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"
>> 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" <dd...@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
>> 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 <da...@oclc.org>
>>>> To: shindig <de...@shindig.apache.org>,
>>>> 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
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
Re: getModuleId
Posted by Dan Dumont <dd...@us.ibm.com>.
Hrmm...
I don't know if you'll be able to do this anymore until you hook up the
moduleId support.
From: daviesd <da...@oclc.org>
To: <de...@shindig.apache.org>,
Date: 01/23/2012 03:08 PM
Subject: Re: getModuleId
Like I said... An edge case... And probably not a real world use case.
But my test gadget sets a bunch of userprefs and then it needs to repull
the
values (from persistence) and make sure they've been set properly (tests a
race condition we had).
I was using osapi.userprefs.get to retrieve the values. Is there a gadget
way of triggering the get call that is in the container? I don't want to
just get the map that the container has, I need to reforce a read from
persistence.
Hope that makes sense,
doug
On 1/23/12 3:00 PM, "Dan Dumont" <dd...@us.ibm.com> wrote:
> I don't think so. In my opinion, the siteId is a purely container
piece
> of information.
> why do you need to get it inside the gadget?
>
>
>
> From: daviesd <da...@oclc.org>
> To: <de...@shindig.apache.org>,
> Date: 01/23/2012 02:57 PM
> Subject: Re: getModuleId
>
>
>
> I agree on everything you just stated.
>
> So my only outstanding question would be is anyone aware of a way for a
> gadget to find out it's siteId (the id that was set on the element the
> gadget was rendered into)?
>
> Any yes, I'd like to see the rpc requests changed to use the gadget
> security
> token.
>
> doug
>
>
> On 1/23/12 1:44 PM, "Dan Dumont" <dd...@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_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 <da...@oclc.org>
>> To: <de...@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"
> 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" <dd...@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
> 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 <da...@oclc.org>
>>> To: shindig <de...@shindig.apache.org>,
>>> 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
>>>
>>
>>
>>
>
>
>
Re: getModuleId
Posted by daviesd <da...@oclc.org>.
Like I said... An edge case... And probably not a real world use case.
But my test gadget sets a bunch of userprefs and then it needs to repull the
values (from persistence) and make sure they've been set properly (tests a
race condition we had).
I was using osapi.userprefs.get to retrieve the values. Is there a gadget
way of triggering the get call that is in the container? I don't want to
just get the map that the container has, I need to reforce a read from
persistence.
Hope that makes sense,
doug
On 1/23/12 3:00 PM, "Dan Dumont" <dd...@us.ibm.com> wrote:
> I don't think so. In my opinion, the siteId is a purely container piece
> of information.
> why do you need to get it inside the gadget?
>
>
>
> From: daviesd <da...@oclc.org>
> To: <de...@shindig.apache.org>,
> Date: 01/23/2012 02:57 PM
> Subject: Re: getModuleId
>
>
>
> I agree on everything you just stated.
>
> So my only outstanding question would be is anyone aware of a way for a
> gadget to find out it's siteId (the id that was set on the element the
> gadget was rendered into)?
>
> Any yes, I'd like to see the rpc requests changed to use the gadget
> security
> token.
>
> doug
>
>
> On 1/23/12 1:44 PM, "Dan Dumont" <dd...@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_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 <da...@oclc.org>
>> To: <de...@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"
> 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" <dd...@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
> 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 <da...@oclc.org>
>>> To: shindig <de...@shindig.apache.org>,
>>> 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
>>>
>>
>>
>>
>
>
>
Re: getModuleId
Posted by Dan Dumont <dd...@us.ibm.com>.
I don't think so. In my opinion, the siteId is a purely container piece
of information.
why do you need to get it inside the gadget?
From: daviesd <da...@oclc.org>
To: <de...@shindig.apache.org>,
Date: 01/23/2012 02:57 PM
Subject: Re: getModuleId
I agree on everything you just stated.
So my only outstanding question would be is anyone aware of a way for a
gadget to find out it's siteId (the id that was set on the element the
gadget was rendered into)?
Any yes, I'd like to see the rpc requests changed to use the gadget
security
token.
doug
On 1/23/12 1:44 PM, "Dan Dumont" <dd...@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_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 <da...@oclc.org>
> To: <de...@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"
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" <dd...@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
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 <da...@oclc.org>
>> To: shindig <de...@shindig.apache.org>,
>> 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
>>
>
>
>
Re: getModuleId
Posted by Dan Dumont <dd...@us.ibm.com>.
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
To: dev@shindig.apache.org,
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 <he...@gmail.com>
To: dev@shindig.apache.org,
Date: 01/27/2012 02:16 AM
Subject: Re: getModuleId
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 <dd...@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_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 <da...@oclc.org>
> To: <de...@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"
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" <dd...@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
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 <da...@oclc.org>
>> To: shindig <de...@shindig.apache.org>,
>> 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
>>
>
>
>
Re: getModuleId
Posted by Dan Dumont <dd...@us.ibm.com>.
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 <he...@gmail.com>
To: dev@shindig.apache.org,
Date: 01/27/2012 02:16 AM
Subject: Re: getModuleId
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 <dd...@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_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 <da...@oclc.org>
> To: <de...@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"
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" <dd...@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
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 <da...@oclc.org>
>> To: shindig <de...@shindig.apache.org>,
>> 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
>>
>
>
>
Re: getModuleId
Posted by Henry Saputra <he...@gmail.com>.
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 <dd...@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_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 <da...@oclc.org>
> To: <de...@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" 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" <dd...@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 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 <da...@oclc.org>
>> To: shindig <de...@shindig.apache.org>,
>> 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
>>
>
>
>
Re: getModuleId
Posted by daviesd <da...@oclc.org>.
I agree on everything you just stated.
So my only outstanding question would be is anyone aware of a way for a
gadget to find out it's siteId (the id that was set on the element the
gadget was rendered into)?
Any yes, I'd like to see the rpc requests changed to use the gadget security
token.
doug
On 1/23/12 1:44 PM, "Dan Dumont" <dd...@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_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 <da...@oclc.org>
> To: <de...@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" 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" <dd...@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 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 <da...@oclc.org>
>> To: shindig <de...@shindig.apache.org>,
>> 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
>>
>
>
>
Re: getModuleId
Posted by Dan Dumont <dd...@us.ibm.com>.
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 <da...@oclc.org>
To: <de...@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" 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" <dd...@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 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 <da...@oclc.org>
> To: shindig <de...@shindig.apache.org>,
> 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
>
Re: getModuleId
Posted by daviesd <da...@oclc.org>.
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" <dd...@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 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 <da...@oclc.org>
> To: shindig <de...@shindig.apache.org>,
> 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
>
Re: getModuleId
Posted by Dan Dumont <dd...@us.ibm.com>.
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 <da...@oclc.org>
To: shindig <de...@shindig.apache.org>,
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