RE: Common container rpc request uses wrong security token

[Davies,Douglas]

Here's what I'm implementing.

 

Add a lifecycle handler for onNavigated.  It calls 

 

        token = container.service_.getGadgetToken 

 

and then uses that to call 

 

        var holder = gadgetSite.getActiveGadgetHolder();

        gadgets.rpc.call(holder.getIframeId(), 'update_security_token',
null, token);

        holder.setSecurityToken(token);

 

then in my set_pref handler I do

 

        var holder =
rpcArgs[osapi.container.GadgetSite.RPC_ARG_KEY].getActiveGadgetHolder();

        var token = holder.securityToken_;

        gadgets.log('using token: ' + token);

        var oldToken = shindig.auth.getSecurityToken();

        shindig.auth.updateSecurityToken(token);

        osapi.appdata.update(...)

 

Not ideal, but at least I now have a reference to the gadget security
token when set_pref calls osapi and I can use the appropriate appid.
I'm hoping what I'm doing fits in with whatever the common container
ends up doing when this is fully implemented.  I'm assuming the gadget
holder security token was meant for this purpose, but not sure.  Of
course anywhere I need the gadget security token instead of the
container one I'm gonna have to intercept the rpc call.  I'd love to
trickle this down to the jsonrpcrequest level, but I couldn't figure out
how to get access to the gadget or gadget site at that level.

 

doug

 

From: Davies,Douglas 
Sent: Monday, July 18, 2011 10:52 AM
To: 'dev@shindig.apache.org'
Subject: Common container rpc request uses wrong security token

 

I have opened https://issues.apache.org/jira/browse/SHINDIG-1557.  The
gadget security token is not being used on rpc calls.  The container one
is.  Thus calls like appdata and userprefs do not have access to the
gadget information as they need.

 

In the meantime I'm going to try to work around this in my own
container.  Does anyone have any ideas how to get a hold of the
requesting gadget inside of jsonrpctransport? 

 

Thanks,

doug