You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "Davies,Douglas" <da...@oclc.org> on 2015/04/22 18:49:30 UTC
appId, moduleId, siteId
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
Re: appId, moduleId, siteId
Posted by "Davies,Douglas" <da...@oclc.org>.
We are on the latest (2.5.2).
On Apr 27, 2015, at 11:10 AM, Martin Hoeller <ma...@xss.co.at>> wrote:
Hi!
Are you using a recent version of shindig?
There was a bug that got fixed about 2 years ago:
https://issues.apache.org/jira/browse/SHINDIG-1891
hth,
- martin
Am Mon, 27 Apr 2015 13:30:47 +0000 schrieb "Davies,Douglas" <da...@oclc.org>>:
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
<ss...@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
<da...@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
<da...@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
<da...@oclc.org><mailto:
daviesd@oclc.org<ma...@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
Re: appId, moduleId, siteId
Posted by Martin Hoeller <ma...@xss.co.at>.
Hi!
Are you using a recent version of shindig?
There was a bug that got fixed about 2 years ago:
https://issues.apache.org/jira/browse/SHINDIG-1891
hth,
- martin
Am Mon, 27 Apr 2015 13:30:47 +0000 schrieb "Davies,Douglas" <da...@oclc.org>:
> 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
> <ss...@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
> <da...@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
> <da...@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
> <da...@oclc.org><mailto:
> daviesd@oclc.org<ma...@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
>
Re: appId, moduleId, siteId
Posted by "Davies,Douglas" <da...@oclc.org>.
Ugh… so this is all starting to ring a bell from a discussion I had years ago
https://mail-archives.apache.org/mod_mbox/shindig-dev/201112.mbox/%3COF8EACEEC4.629D7942-ON8525796F.005711E2-8525796F.00572675@notesdev.ibm.com%3E
and
https://issues.apache.org/jira/browse/SHINDIG-1557
In that bug I suggested that the calls to userPrefs were being made on behalf of the container, in other words the container security token was being used. This might be working as designed, but it means on the service side I can't just do token.getModuleId(). Instead I always need to pass along the extra piece of information to the service.
Dan Dumont suggested…
I think we would certainly want to make sure that all container-proxied requests ferry along the moduleId. I'll keep that in mind as I make these changes. Thank you for pointing it out.
I don’t think those were changes that were ever made. That’s fine, I can just switch my userPrefs to key off of moduleId (instead of siteId) and just pass it along, but I was hoping to not even have to do that since the gadget security token has the moduleId embedded appropriately.
At least I’ve wrapped my head around the moduleId stuff. Not sure if it buys me anything at this point however.
Hmph!
doug
On Apr 27, 2015, at 12:47 PM, Davies,Douglas <da...@oclc.org>> wrote:
Doh! I just realized that the validate method has to return the same value. I changed it and I’m now getting back the moduleId in the json response. Sweet!
So to summarize…
If I set RenderParam.MODULE_ID to -1 it causes the back-end to generate an id using ModuleIdManager (generate and validate). This comes back in the json response to the “gadget.token” rpc call. Thereafter, if I call gadgetSite.getModuleId() I get back the generated id.
Now if I set RenderParam.MODULE_ID to 1234 and I don’t provide my own ModuleIdManager, it will return a moduleId of 0. If I instead implement the validate method (the generate does not get called in this scenario) to return the moduleId passed in then the module id is set correctly and I can use gadgetSite.getModuleId() as well.
I hope that helps someone else in the future. Is there somewhere I could document this? Not sure where the correct wiki is anymore and whether this falls under common container info or what.
Thanks!
doug
On Apr 27, 2015, at 11:35 AM, Davies,Douglas <da...@oclc.org>> wrote:
If I set renderParams[osapi.container.RenderParam.MODULE_ID] = -1
per http://comments.gmane.org/gmane.comp.web.shindig.devel/8498
* You can now request that a new moduleId be generated for a gadget when asking for a new token by setting it's
moduleId to a negative number and fetching a new token. The response will come back with a moduleId you can
save for persistence. There is a corresponding new class in Java to override if you plan on persisting
moduleIds. It has 2 methods: validate and generate which are used to verify the validity of a moduleId,
viewerId, gadgetUrl combination or to generate (and persist) a new moduleId for that combination.
I now see the “generate” method of ModuleIdManager get called. I have it returning 1234L. However, the response still has moduleId set to 0.
[{"method":"gadgets.token","id":"gadgets.token","params":{"container":"sandbox","ids":["https://dl.dropboxusercontent.com/u/445894/gadgets/userprefs-consistency.xml#moduleId=-1"],"fields":["token","tokenTTL","moduleId"],"userId":"@viewer","groupId":"@self"}}]
[{"result":{"https://dl.dropboxusercontent.com/u/445894/gadgets/userprefs-consistency.xml#moduleId=-1":{"moduleId":0,"responseTimeMs":1430148807688,"tokenTTL":3600,"token":"sandbox:hdaOrK8oPiHzbXbZqWfCReLpNJ2rgioN3pIXAX33ChO9r6rxBgB9DOHkp02PzPD7xOIwYD5MpEDB0DFjVceBq-VRnFm2xCDpIbft5CpbF8r1nQP5VLRoxf4bbsxFG13vEso2adn9eBGg516thh7MtHa-i5Om-fxkH8ycXCLsFeZPqqIS1vEgLahykYYcoaGrbwxZfNDtGfLl9pH9bXIqpjkAArpWyiABVz_5C-6AE2I0xoc8LJIjZylSDrrqxN9GQUbp5gGa3yny5Qu5GG2GqSQeSrUaTm2tjQc3n15mlSUjBjt_LqjZ8_laeChEfVJOO2FurZO1uWOXoKzB4LIQZyZTDhoQ8Vxzsa0KZpT4JmdRRmKlMh7IiJAZmc9WTVEBHffJ_KYl3pHT11JmOjvbDS9t8rltEyDtxf4TOnmLFDosIdJcNTAiBv8nv5l6sm2o7CJRRGhQvhqStNUYVS0etReoCw9T8hTVZSKeAC5F1-Ew7qOjghLK3SsLPxXJZSRVnZ3xsolOQ9CAiRe852KhhpkBsvlCpW82r4N-wresRASzMOgM"}},"id":"gadgets.token”}]
doug
Re: appId, moduleId, siteId
Posted by "Davies,Douglas" <da...@oclc.org>.
Doh! I just realized that the validate method has to return the same value. I changed it and I’m now getting back the moduleId in the json response. Sweet!
So to summarize…
If I set RenderParam.MODULE_ID to -1 it causes the back-end to generate an id using ModuleIdManager (generate and validate). This comes back in the json response to the “gadget.token” rpc call. Thereafter, if I call gadgetSite.getModuleId() I get back the generated id.
Now if I set RenderParam.MODULE_ID to 1234 and I don’t provide my own ModuleIdManager, it will return a moduleId of 0. If I instead implement the validate method (the generate does not get called in this scenario) to return the moduleId passed in then the module id is set correctly and I can use gadgetSite.getModuleId() as well.
I hope that helps someone else in the future. Is there somewhere I could document this? Not sure where the correct wiki is anymore and whether this falls under common container info or what.
Thanks!
doug
On Apr 27, 2015, at 11:35 AM, Davies,Douglas <da...@oclc.org> wrote:
> If I set renderParams[osapi.container.RenderParam.MODULE_ID] = -1
>
> per http://comments.gmane.org/gmane.comp.web.shindig.devel/8498
>
> * You can now request that a new moduleId be generated for a gadget when asking for a new token by setting it's
> moduleId to a negative number and fetching a new token. The response will come back with a moduleId you can
> save for persistence. There is a corresponding new class in Java to override if you plan on persisting
> moduleIds. It has 2 methods: validate and generate which are used to verify the validity of a moduleId,
> viewerId, gadgetUrl combination or to generate (and persist) a new moduleId for that combination.
>
> I now see the “generate” method of ModuleIdManager get called. I have it returning 1234L. However, the response still has moduleId set to 0.
>
> [{"method":"gadgets.token","id":"gadgets.token","params":{"container":"sandbox","ids":["https://dl.dropboxusercontent.com/u/445894/gadgets/userprefs-consistency.xml#moduleId=-1"],"fields":["token","tokenTTL","moduleId"],"userId":"@viewer","groupId":"@self"}}]
>
> [{"result":{"https://dl.dropboxusercontent.com/u/445894/gadgets/userprefs-consistency.xml#moduleId=-1":{"moduleId":0,"responseTimeMs":1430148807688,"tokenTTL":3600,"token":"sandbox:hdaOrK8oPiHzbXbZqWfCReLpNJ2rgioN3pIXAX33ChO9r6rxBgB9DOHkp02PzPD7xOIwYD5MpEDB0DFjVceBq-VRnFm2xCDpIbft5CpbF8r1nQP5VLRoxf4bbsxFG13vEso2adn9eBGg516thh7MtHa-i5Om-fxkH8ycXCLsFeZPqqIS1vEgLahykYYcoaGrbwxZfNDtGfLl9pH9bXIqpjkAArpWyiABVz_5C-6AE2I0xoc8LJIjZylSDrrqxN9GQUbp5gGa3yny5Qu5GG2GqSQeSrUaTm2tjQc3n15mlSUjBjt_LqjZ8_laeChEfVJOO2FurZO1uWOXoKzB4LIQZyZTDhoQ8Vxzsa0KZpT4JmdRRmKlMh7IiJAZmc9WTVEBHffJ_KYl3pHT11JmOjvbDS9t8rltEyDtxf4TOnmLFDosIdJcNTAiBv8nv5l6sm2o7CJRRGhQvhqStNUYVS0etReoCw9T8hTVZSKeAC5F1-Ew7qOjghLK3SsLPxXJZSRVnZ3xsolOQ9CAiRe852KhhpkBsvlCpW82r4N-wresRASzMOgM"}},"id":"gadgets.token”}]
>
> doug
Re: appId, moduleId, siteId
Posted by "Davies,Douglas" <da...@oclc.org>.
If I set renderParams[osapi.container.RenderParam.MODULE_ID] = -1
per http://comments.gmane.org/gmane.comp.web.shindig.devel/8498
* You can now request that a new moduleId be generated for a gadget when asking for a new token by setting it's
moduleId to a negative number and fetching a new token. The response will come back with a moduleId you can
save for persistence. There is a corresponding new class in Java to override if you plan on persisting
moduleIds. It has 2 methods: validate and generate which are used to verify the validity of a moduleId,
viewerId, gadgetUrl combination or to generate (and persist) a new moduleId for that combination.
I now see the “generate” method of ModuleIdManager get called. I have it returning 1234L. However, the response still has moduleId set to 0.
[{"method":"gadgets.token","id":"gadgets.token","params":{"container":"sandbox","ids":["https://dl.dropboxusercontent.com/u/445894/gadgets/userprefs-consistency.xml#moduleId=-1"],"fields":["token","tokenTTL","moduleId"],"userId":"@viewer","groupId":"@self"}}]
[{"result":{"https://dl.dropboxusercontent.com/u/445894/gadgets/userprefs-consistency.xml#moduleId=-1":{"moduleId":0,"responseTimeMs":1430148807688,"tokenTTL":3600,"token":"sandbox:hdaOrK8oPiHzbXbZqWfCReLpNJ2rgioN3pIXAX33ChO9r6rxBgB9DOHkp02PzPD7xOIwYD5MpEDB0DFjVceBq-VRnFm2xCDpIbft5CpbF8r1nQP5VLRoxf4bbsxFG13vEso2adn9eBGg516thh7MtHa-i5Om-fxkH8ycXCLsFeZPqqIS1vEgLahykYYcoaGrbwxZfNDtGfLl9pH9bXIqpjkAArpWyiABVz_5C-6AE2I0xoc8LJIjZylSDrrqxN9GQUbp5gGa3yny5Qu5GG2GqSQeSrUaTm2tjQc3n15mlSUjBjt_LqjZ8_laeChEfVJOO2FurZO1uWOXoKzB4LIQZyZTDhoQ8Vxzsa0KZpT4JmdRRmKlMh7IiJAZmc9WTVEBHffJ_KYl3pHT11JmOjvbDS9t8rltEyDtxf4TOnmLFDosIdJcNTAiBv8nv5l6sm2o7CJRRGhQvhqStNUYVS0etReoCw9T8hTVZSKeAC5F1-Ew7qOjghLK3SsLPxXJZSRVnZ3xsolOQ9CAiRe852KhhpkBsvlCpW82r4N-wresRASzMOgM"}},"id":"gadgets.token”}]
doug
Re: appId, moduleId, siteId
Posted by "Davies,Douglas" <da...@oclc.org>.
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 <ss...@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 <da...@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 <da...@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 <da...@oclc.org><mailto:
daviesd@oclc.org<ma...@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
Re: appId, moduleId, siteId
Posted by Stanton Sievers <ss...@apache.org>.
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 <da...@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 <da...@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 <daviesd@oclc.org<mailto:
> daviesd@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
> >
> >
> >
>
>
>
Re: appId, moduleId, siteId
Posted by "Davies,Douglas" <da...@oclc.org>.
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 <da...@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 <da...@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
>
>
>
Re: appId, moduleId, siteId
Posted by "Davies,Douglas" <da...@oclc.org>.
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 <da...@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