You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@shindig.apache.org by "Davies,Douglas" <da...@oclc.org> on 2011/07/18 16:51:47 UTC

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

Re: Common container rpc request uses wrong security token

Posted by daviesd <da...@oclc.org>.

Ryan,

I agree that the security token in the gadget holder should be done on the
navigate.  It appears this was the intention, but I think there are a few
things about security tokens that haven¹t been completed in the common
container (I wish these holes were documented).  My first attempt WAS to
patch the code, however we¹ve been trying to use the maven artifacts and not
override any of the base stuff but instead plug in where we think
appropriate.  I guess as far as the community is concerned I should be
patching the code, however I think the google guys have a better idea of
what the intentions were here.  As far as intercepting the RPC call.  I hate
this.  I really wish I could figure out how to bubble down the gadget
security token to the jsonrpcrequest.  Thanks for the confirmations.

doug

On 7/20/11 7:42 PM, "Ryan J Baxter" <rj...@us.ibm.com> wrote:

> Doug I am glad you found a solution.  I feel like the first part where you
> are setting the security token in the gadget holder, should be done by the
> common container code automatically when you call
> container.navigateGadget.  Maybe you can look into doing this can creating
> a patch?
> 
> The second part where you are intercepting the RCP call and getting the
> security token out of the gadget holder, still seems a little odd....but I
> can't think of a better solution right now.
> 
> -Ryan
> 
> Email: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile

RE: Common container rpc request uses wrong security token

Posted by Ryan J Baxter <rj...@us.ibm.com>.

Doug I am glad you found a solution.  I feel like the first part where you 
are setting the security token in the gadget holder, should be done by the 
common container code automatically when you call 
container.navigateGadget.  Maybe you can look into doing this can creating 
a patch?

The second part where you are intercepting the RCP call and getting the 
security token out of the gadget holder, still seems a little odd....but I 
can't think of a better solution right now.

-Ryan

Email: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile



From:   "Davies,Douglas" <da...@oclc.org>
To:     <de...@shindig.apache.org>, 
Date:   07/20/2011 10:41 AM
Subject:        RE: Common container rpc request uses wrong security token



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

RE: Common container rpc request uses wrong security token

Posted by "Davies,Douglas" <da...@oclc.org>.

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