shindig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Saputra <henry.sapu...@gmail.com>
Subject Re: getModuleId
Date Wed, 25 Jan 2012 06:46:04 GMT
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 <ddumont@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 <daviesd@oclc.org>
> To:     <dev@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" <ddumont@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 <daviesd@oclc.org>
>> To:     <dev@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" <ddumont@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 <daviesd@oclc.org>
>>> To:     <dev@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" <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_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 <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"
>>> 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" <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
>>> 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 = 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
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>

Mime
View raw message