Stanton,
Thanks for the rundown on the different ids and what they are. That’s helpful
(and along the same lines as the conclusion I came to).
So I tried changing ModuleIdManagerImpl to return 1234L. However when I do the
following in the gadget
alert(gadgets.Prefs().getModuleId());
I still see 0. I set a breakpoint and I do NOT see the generate method get
called.
I also tried doing the following in my js container.
renderParams[osapi.container.RenderParam.MODULE_ID] = 1234;
I do see an rpc request as follows:
[{"method":"gadgets.token","id":"gadgets.token","params":{"container":"sandbox","ids":["https://dl.dropboxusercontent.com/u/445894/gadgets/userprefs-consistency.xml#moduleId=1234"],"fields":["token","tokenTTL","moduleId"],"userId":"@viewer","groupId":"@self"}}]
with a response of
[{
"result": {
"https://dl.dropboxusercontent.com/u/445894/gadgets/userprefs-consistency.xml#moduleId=1234":
{
"moduleId": 0,
"token":
"sandbox:zHzRL-vIuzoZ_84zMMigXr87NIBfvDijZdW-eF8cXSsAbIzCwWeLtr8I6tP0zrBL_iFcYO3c4AQwdZTUE_Bnvc5mB4i-PQ5QvUI-Z_SfWU7hBmIKEGNSJ1JznG8NWX_jdfGfkRe3hfjGlwOimVhcuynZheLfEHzssTL3WwWHa0xxmzmmlwbGkYwlClbKG5QLli4X8Tw4llnepPjYKwL7xu1pVWyF2VlSTaU-z1OZLQQ7fuHQszzTwUW77G2vDnSX49xIoCXmud52am10xEU_zpmbjDMb3AQ6trCkcEcwnGiurZExfiyMPa97VKlnXKiB2vC_0B22mbu9_moCU-vfFaNYcHXBKXlO6nsmV8SOSFOGi9l_9aQTX5YOaox0TJ4QU3vJYaarooQVwy2BWchS9qE216metnRvKHtFZ4pSuEw_aAdda8rlQ8LBkMLroqQaozJzi3OLdZ6y0SI3HRwSjAlZ77epTSk7b3m0_GmWIP7j4Qth-jcuVjgf_Gbs8tY3E6HFlGBsUzXcgLxLIKqNYZk_41XTErzYGtOxSMXJl_3mFALX",
"responseTimeMs": 1430141170844,
"tokenTTL": 3600
}
},
"id": "gadgets.token"
}
]
I see the #moduleId of 1234 tacked onto the gadget spec url, however it appears
the moduleId comes back as 0 in the response.
I must be missing something here.
Again, it feels like I should be using moduleId in userPrefs instead of siteId,
since it’s baked into the security token and it can’t be spoofed easily and
isn’t exposed as a parameter.
I’ll keep playing around with this, but thanks for the clarifications. Did you
and Ryan ever implement this in the container you were working on?
Thanks,
doug
On Apr 25, 2015, at 9:01 AM, Stanton Sievers
<ssiev...@apache.org<mailto:ssiev...@apache.org>> wrote:
Hi Doug,
You may have already gotten to the bottom of this but I'll provide a quick
rundown here anyway.
siteId: Client-side ID that is generated to help manage communication
between the container and the gadget sites for services like actions,
selection, and more
appId: An id that is unique to the application, i.e. gadget, being
rendered. AppId in the case of gadgets is generally just the URL to the
gadget XML. Thus, this ID is the same across all instances of a given
gadget and is for storing data like app data.
moduleId: An id that is unique to the instance of a gadget. If multiple
instances of the same gadget are rendering on the page, they should have
unique module ids. The server is also aware of module ids, as you saw with
ModuleIdManager, and is the one responsible for generating them. They are
included in security tokens to differentiate between separate instances of
a gadget. The module id for a gadget instance should be the same across
page reloads. A gadget preferences implementation would use the module id
to store instance-specific information.
Shindig's default implementation of moduleId is naive (it's always 0!) but
a ModuleIdManager implementation can be injected that handles them more
intelligently.
I hope that helps!
On Fri, Apr 24, 2015 at 4:10 PM, Davies,Douglas
<davi...@oclc.org<mailto:davi...@oclc.org>> wrote:
I think I just had an ah ha moment. I realized the ModuleIdManager is
concerned about persistence. I’m not sure that’s what I need here. I
think the piece I was missing it RenderParam.MODULE_ID on the container
side. I’m gonna play with this and I’ll be back if I have more questions.
Thanks,
doug
On Apr 24, 2015, at 2:15 PM, Davies,Douglas
<davi...@oclc.org<mailto:davi...@oclc.org>> wrote:
Ok, I think I’ve figured this out (at least our use-case).
We are using the siteId all over the place in the container and having
to pass it along to the userPrefs calls. I’m guessing I shouldn’t be doing
this and allowed the moduleId bake into the security token to be used
server-side to identify the gadget.
So… I implemented my own ModuleIdManager, however I noticed it NEVER
gets called. I traced it back to getToken in GadgetsHandlerService, which
in turn is called by the token method over in GadgetsHandler. It looks as
follows
@Operation(httpMethods = {"POST", "GET"}, path = "token")
public Map<String, GadgetsHandlerApi.BaseResponse> token(BaseRequestItem
request)
throws ProtocolException {
return new AbstractExecutor() {
@Override
protected Callable<CallableData> createJob(String url,
BaseRequestItem request)
throws ProcessingException {
return createTokenJob(url, request);
}
}.execute(request);
}
However I NEVER see this endpoint hit. I see the metadata endpoint get
called. Does the js container need to be doing something with the “token”
endpoint? I don’t see it documented anywhere. The common container that
comes with shindig doesn’t seem to call this endpoint either.
Thanks,
doug
On Apr 22, 2015, at 12:49 PM, Davies,Douglas
<davi...@oclc.org<mailto:davi...@oclc.org><mailto:
davi...@oclc.org<mailto:davi...@oclc.org>>> wrote:
I’ve been combing through past conversations and wikis, but I’ve yet to
find a good explanation of the difference between appId, moduleId, and
siteId. Does anyone know where I can find a good explanation of where I
should be using each one? Right now I think the default ModuleIIdManager
always returns 0. We are using siteId quite a bit in our container to
indicate which gadget is making requests. I know the moduleId is baked
into the SecurityToken and it would be a better implementation. Any
guidance on this would be appreciated.
Thanks,
Doug
