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>:
> 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
>
signature.asc
Description: PGP signature
