Ryan, Thanks. Still seems strange that this is not working. I would think anyone using the common container for anything substantial would have hit the same issue. Perhaps no one else cares that their security token has the right appid, etc. I guess the viewerid will be the same for all.
Anyway... Still gonna play with it to see if I am doing something wrong. I logged the rpcArgs in set_pref and the only security token is on the iframe. There is a security token in the gadget site but it is empty as is the token cache. I had to patch every rpc call to apply the right security token. The set_pref gets called from the common container so not sure that swapping for the REST API is gonna be doable. Maybe I'll open up a bug report for this. Hopefully Michael will see this and have some ideas. Doug Sent from my iPad On Jul 14, 2011, at 8:28 PM, "Ryan J Baxter" <[email protected]> wrote: > Doug, like you said I assume its using the container token because your > calling the API in the context of the container. What about using the > REST API instead? May be more of a pain but could be a work around to the > problem. > > -Ryan > > Email: [email protected] > Phone: 978-899-3041 > developerWorks Profile > > > > From: "Davies,Douglas" <[email protected]> > To: <[email protected]>, > Date: 07/13/2011 09:39 PM > Subject: Re: jsonrpctransport.js > > > > Ryan, > > Thanks for responding. Was starting to wonder if my messages were making > it to > the mail list. > > Yes I'm using appdata for a userpref store. Regardless of whether that is > the right > approach or not, the rpc call still seems like it should be using the > gadget security token > instead of the container one. I think I understand why it does what it > does since the > rpc handler is in the container context and not gadget. > > Any help is appreciated. I must be doing something wrong because this just > seems like too > glaring of a bug. > > Doug > > Sent from my iPad > > On Jul 13, 2011, at 9:01 PM, "Ryan J Baxter" <[email protected]> wrote: > >> Doug just try to understand your situation, are using app data as a way > >> to store preferences? So your registering an RPC handler for set pref > in >> your container and your container is calling osapi.appdata.update(...)? >> >> -Ryan >> >> Email: [email protected] >> Phone: 978-899-3041 >> developerWorks Profile >> >> >> >> From: "Davies,Douglas" <[email protected]> >> To: <[email protected]>, >> Date: 07/13/2011 03:04 PM >> Subject: RE: jsonrpctransport.js >> >> >> >> 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: '[email protected]' >> 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: '[email protected]' >> 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 >> >> >> >> >> >> > > > >
