restfulcontainer.js and the gadget auth token

[Brian Eaton <be...@google.com>]

Hey folks -

Can someone explain what restfultoken.js is doing in this code?

// Hopefully we can get rid of these with special @viewer and @owner tokens
// in the restful spec.
RestfulContainer.prototype.parseSecurityToken = function() {
  var parts = this.securityToken_.split(":");
  this.ownerId_ = parts[0];
  this.viewerId_ = parts[1];
  this.appId_ = parts[2];
};

That isn't going to work in the real world, since the gadget auth
token is encrypted.  I'd like to move the security token handling into
its own javascript package, but I don't see any way to migrate that
code.

Cheers,
Brian

Re: restfulcontainer.js and the gadget auth token

[Brian Eaton <be...@google.com>]

On Tue, May 13, 2008 at 1:02 AM, Cassie <do...@apache.org> wrote:
>  As for your earlier thread, removing .st from the getUrlParameters
>  will break people using Shindig. (including the company we work for)
>  So... we'll need to handle that nicely somehow.

Yeah, that's on my list.  My SHINDIG-264 patch leaves it on the URL
parameters and should be backwards compatible with existing tokens.

Re: restfulcontainer.js and the gadget auth token

[Cassie <do...@apache.org>]

Right now, the restful java server does not fetch the security token
from the url and does not use it. So, in order to have any working
code for the wip restful js container I have to parse the viewer and
owner ids out of the security token so i can pass them to the
container directly. This definitely won't work in real life but is a
placeholder until we get more restful impl stuff done.

When the restful impl is finished the js will pass the whole st up to
the server blindly, just like it does on the json side. And at that
point it will use special @viewer and @owner tokens so that it does
not have to figure out how the owner and viewer are.

As for your earlier thread, removing .st from the getUrlParameters
will break people using Shindig. (including the company we work for)
So... we'll need to handle that nicely somehow.

- Cassie


On Mon, May 12, 2008 at 5:24 AM, Brian Eaton <be...@google.com> wrote:
> On Sun, May 11, 2008 at 5:22 PM, Kevin Brown <et...@google.com> wrote:
>> This code seems pretty useless to me. I think the ideal way to get the
>>  viewer / owner / app id would be to do one of the following:
>>
>>  - Pass them unencrypted into iframe params (encourages developers to rely on
>>  them being there or to not use signed / oauth requests, which is bad)
>>  - Retrieve them from the parent page using gadgets.rpc (my preferred
>>  solution)
>>  - Retrieve them from the social data service
>
> I like the third option, since it can be efficiently implemented using
> either of the first two mechanisms.  The social data API should be
> able to answer questions about owner and viewer id without requiring
> round trips to the server (or the container page, for that matter.)
>
> The comment in the code about special @viewer and @owner tokens in the
> RESTful spec seemed like a reasonable option as well.
>

Re: restfulcontainer.js and the gadget auth token

[Brian Eaton <be...@google.com>]

On Sun, May 11, 2008 at 5:22 PM, Kevin Brown <et...@google.com> wrote:
> This code seems pretty useless to me. I think the ideal way to get the
>  viewer / owner / app id would be to do one of the following:
>
>  - Pass them unencrypted into iframe params (encourages developers to rely on
>  them being there or to not use signed / oauth requests, which is bad)
>  - Retrieve them from the parent page using gadgets.rpc (my preferred
>  solution)
>  - Retrieve them from the social data service

I like the third option, since it can be efficiently implemented using
either of the first two mechanisms.  The social data API should be
able to answer questions about owner and viewer id without requiring
round trips to the server (or the container page, for that matter.)

The comment in the code about special @viewer and @owner tokens in the
RESTful spec seemed like a reasonable option as well.

Re: restfulcontainer.js and the gadget auth token

[Kevin Brown <et...@google.com>]

This code seems pretty useless to me. I think the ideal way to get the
viewer / owner / app id would be to do one of the following:

- Pass them unencrypted into iframe params (encourages developers to rely on
them being there or to not use signed / oauth requests, which is bad)
- Retrieve them from the parent page using gadgets.rpc (my preferred
solution)
- Retrieve them from the social data service

On Sun, May 11, 2008 at 4:24 PM, Brian Eaton <be...@google.com> wrote:

> Hey folks -
>
> Can someone explain what restfultoken.js is doing in this code?
>
> // Hopefully we can get rid of these with special @viewer and @owner
> tokens
> // in the restful spec.
> RestfulContainer.prototype.parseSecurityToken = function() {
>  var parts = this.securityToken_.split(":");
>  this.ownerId_ = parts[0];
>  this.viewerId_ = parts[1];
>  this.appId_ = parts[2];
> };
>
> That isn't going to work in the real world, since the gadget auth
> token is encrypted.  I'd like to move the security token handling into
> its own javascript package, but I don't see any way to migrate that
> code.
>
> Cheers,
> Brian
>