I put logging in my gadget and printed out the value of
shindig.auth.getSecurityToken and it was the correct one from the iframe
st param. I then log the same value before the osapi.appdata call and
it's the container value. So obviously they are using different
instances of the shindig.auth object. This must have to do with my
set_pref being registered with the container (my set_pref is the one
using appdata). I'm not sure how to get the osapi calls to use the
gadget security token.
doug
From: Davies,Douglas
Sent: Wednesday, July 13, 2011 11:05 AM
To: 'dev@shindig.apache.org'
Subject: RE: jsonrpctransport.js
(Piggy backing on my own thread - and I meant calling appdata, not
userprefs)
I just had a lightbulb go off (I think). Since each gadget is in it's
own iframe I'm thinking that each gadget has it's own shindig.auth
reference. Thus, the security token is per gadget, right? But the
gadget writer is not suppose to call updateSecurityToken (and shouldn't
even know anything about it). I'm digging through the code to find out
where this is set after the metadata request is made to get the iframe
url. Does that make sense or am I on the wrong track?
doug
From: Davies,Douglas
Sent: Wednesday, July 13, 2011 9:45 AM
To: 'dev@shindig.apache.org'
Subject: jsonrpctransport.js
jsonrpctransport.js is using shindig.auth.getSecurityToken(). This is
great if the json rpc request is coming from the container. However,
not if it's coming from the gadget. For example let's say my gadget is
calling userprefs
osapi.appdata.update({
userid : '@me',
groupid : '@self',
appId : '@app',
data : data
})
This instruct the request to use the appid from the security token
passed in on the call. But this will end up using the appid that was
set by the container, not by the gadget. Should this be using the
security token of the gadget?
I've posed this as a more general usage question over in users but I
thought maybe the devs would have a better idea of why this is coded
this way.
Doug
