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>> 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
