Preloads for OAuth

[Brian Eaton]

Hi folks -

I'd like to propose that opensocial containers support OAuth preloads
in much the same way they support preloads for signed fetch. This is
a latency win. The change is backwards compatible: if a gadget has a
Preload tag with authz=oauth, containers that don't support OAuth
preloads will simply ignore the tag. The gadget will be slower, but
will still function.

If the authz attribute of the Preload tag is set to "oauth", the
Preload tag will support four additional attributes:

oauth_service_name
oauth_token_name
oauth_request_token
oauth_request_token_secret

These attributes have the same semantics and defaults as the
corresponding parameters to gadgets.io.makeRequest.

All of the additional attributes support hangman variable substitution
of user prefs and other values. (This is useful for bootstrapping a
gadget with a user pref that contains a preapproved request token.
The container will immediately be able to access the user's data via
OAuth, without needing an extra popup window so the user can grant
approval.)

I've built a patch to Shindig for this, as a proof-of-concept:
https://issues.apache.org/jira/browse/SHINDIG-488

Cheers,
Brian

[chabotc]

Makes sense to me, has my +1

[Cassie]

+1

[Zhen Wang]

+1

[Gonzalo Aune]

+1, that would give me an extra work to do =)

G.-

[Louis Ryan]

+1!

[Kevin Brown]

These same attributes would be needed for proxied content (when authz="oauth") as well.

On Fri, Aug 1, 2008 at 8:50 AM, Brian Eaton <bea...@google.com> wrote:

[Brian Eaton]

On Mon, Aug 11, 2008 at 1:05 PM, Kevin Brown <et...@google.com> wrote:
> These same attributes would be needed for proxied content (when
> authz="oauth") as well.

They are already there.

[Kevin Brown]

I was referring to the proposal for proxied type gadgets -- my original proposal only did some hand waving on using oauth, and only had oauth_service_name as an attribute on the Content element.
 

[Brian Eaton]

On Mon, Aug 11, 2008 at 1:27 PM, Kevin Brown <et...@google.com> wrote:
>> They are already there.
>
> I was referring to the proposal for proxied type gadgets -- my original
> proposal only did some hand waving on using oauth, and only had
> oauth_service_name as an attribute on the Content element.

Ah, I thought you were talking about makeRequest. Yes, you'd want all
of the options in there.