We are on the latest (2.5.2). On Apr 27, 2015, at 11:10 AM, Martin Hoeller <mar...@xss.co.at<mailto:mar...@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" <davi...@oclc.org<mailto:davi...@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 <ssiev...@apache.org<mailto: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><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><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<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
