Re: appId, moduleId, siteId

[Davies,Douglas]

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