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: rjbax...@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: "Davies,Douglas" <davi...@oclc.org>
To: <dev@shindig.apache.org>,
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" <rjbax...@us.ibm.com> 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: rjbax...@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
>
>
> From: "Davies,Douglas" <davi...@oclc.org>
> To: <dev@shindig.apache.org>,
> 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: '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
>
>
>
>
>
>
