More concrete proposal proxied content type.

[Kevin Brown]

This is a follow up for the strawman proposal for proxied gadgets that has been brought up in the discussions around templating. There are many other outstanding issues around templating, and I'll leave those as issues for the templating discussion.

Note: The language of the prose sections is not appropriate for the more formal version in the newer xml spec, but we can clean that up if the new version is ever adopted.

Goal:

Provide a way to support a more "standard" web development model within OpenSocial, paving the way for converting virtually any existing web site or application to an OpenSocial application with little effort. Also make it easier for apps authored for other platforms, such as Facebook, to support OpenSocial.

Modifications to schema (patch):

Index: spec/0.8/gadgets/gadgets.xsd
==============================

=====================================
--- spec/0.8/gadgets/gadgets.xsd        (revision 737)
+++ spec/0.8/gadgets/gadgets.xsd        (working copy)
@@ -150,6 +151,18 @@
                 <xs:attribute name="view" type="xs:string" use="optional"/>
                 <xs:attribute name="preferred_height" type="xs:integer" use="optional"/>
                 <xs:attribute name="preferred_width" type="xs:integer" use="optional"/>
+                <xs:attribute name="authz" use="optional" default="none">
+                  <xs:simpleType>
+                    <xs:restriction base="xs:string">
+                      <xs:enumeration value="none"/>
+                      <xs:enumeration value="signed"/>
+                      <xs:enumeration value="oauth"/>
+                    </xs:restriction>
+                  </xs:simpleType>
+                </xs:attribute>
+                <xs:attribute name="sign_owner" type="xs:boolean" default="true"/>
+                <xs:attribute name="sign_viewer" type="xs:boolean" default="true"/>
+                <xs:attribute name="oauth_service" use="optional" type="xs:string"/>
               </xs:extension>
             </xs:simpleContent>
           </xs:complexType>

Requirements for compliance:

1. For the first display of the gadget and all subsequent requests, the container MUST retrieve the URI specified by /Content/@href when type is "html", adding the following parameters:

  - lang (As specified for message bundles)
  - country (As specified for message bundles)
  - OAuth or signed fetch parameters [see makeRequest documentation] depending on the value of /Content/@authz, /Content/@sign_owner, /Content/@sign_viewer, or /Content/@oauth_service

2. The container MUST honor HTTP caching semantics for all proxied requests [see "new" spec document posted to discussion group for references]. The cache key is always the destination url, plus appropriate additional components depending on the authentication mechanism used (owner / viewer / app id for signed fetch, auth credentials for OAuth). These rules MUST be identical to those used for gadgets.io.makeRequest

3. The response MAY be processed by the container, including processing of templates, rewriting optimizations, or injection of any additional script.

4. The container MUST perform all transformations required for type=html, including injection javascript libraries according to feature requirements specified in the gadget xml document, [Unsure: Should we also provide a mechanism for specifing needed features in the html response body?] localization, [Unsure: This may not be necessary since lang / country are sent to the remote site anyway] and invocation of gadgets.util.runOnLoadHandlers

5. The container MUST treat the response as a fully formed, valid HTML 4 document. This includes honoring the doctype and not adding any additional CSS [Unsure: Other than skinning features?]. This is different from html type views, where the body was only a document fragment and the container was expected to provide the envelope.

6. All links in the response document MUST be interpreted as relative to the specified /Content/@href value. Additionally, /Content/@href MUST be interpreted relative to the xml document itself. [Unsure: There are a variety of ways to achieve this, including link rewriting, injecting HTML base elements, or javascript. A specific mechanism probably doesn't need to be specified.]

[Louis Ryan]

I believe this will be a significant advance in the capability of the Gadgets platform and would likely be adopted by gadget developers in droves...

A couple of notes....

- A declarative syntax for the gadget developer to specify additional OpenSocial data to be passed to their backend when the gadget server requests content would allow developers to eliminate a large proportion of RESTful requests from their backend to the container while generating content. This should be a significant latency win. It may be sensible to say that the request to fetch the gadget content from the developers backend will always be POST to accomodate a payload even if initial implementations dont have one.

- The model described here is essentially pull. We should also consider adding the ability for gadget developer backends to programatically invalidate the containers cache of content in response to user action. I would expect this to allow gadget developers to significantly reduce serving infrastructure.

Another interesting side-effect of this proposal is that content is generated with user specific data before it goes to the client, so in many cases it can be strictly HTML with no JS. For profile/showcase style gadgets this would allow them to be inlined safely and have reasonable functionality.

[Kevin Brown]

On Wed, Jul 30, 2008 at 7:56 PM, Louis Ryan <lr...@google.com> wrote:

I believe this will be a significant advance in the capability of the Gadgets platform and would likely be adopted by gadget developers in droves...

A couple of notes....

- A declarative syntax for the gadget developer to specify additional OpenSocial data to be passed to their backend when the gadget server requests content would allow developers to eliminate a large proportion of RESTful requests from their backend to the container while generating content. This should be a significant latency win. It may be sensible to say that the request to fetch the gadget content from the developers backend will always be POST to accomodate a payload even if initial implementations dont have one.

I agree with that -- where does this go though? Barring massive overhaul of the gadget xml (which I'm not necessarily opposed to) I don't see a clear way to put it in there. Perhaps we could extend Preload to support this?
 

- The model described here is essentially pull. We should also consider adding the ability for gadget developer backends to programatically invalidate the containers cache of content in response to user action. I would expect this to allow gadget developers to significantly reduce serving infrastructure.

I'd envision this as a combination of new API calls for both JS and REST. Ideas have been kicked around for a hacky way to do this on top of app data, but I think we could come up with something significantly better for developers.  This seems to have the most potential for profile type views, which will be primarily static (along the lines of setFbml in facebook).
 

Another interesting side-effect of this proposal is that content is generated with user specific data before it goes to the client, so in many cases it can be strictly HTML with no JS. For profile/showcase style gadgets this would allow them to be inlined safely and have reasonable functionality.

That was one of the biggest potential "wins" for this. When combined with templates, it's even more compelling as you'd get significant functionality without having to cajole.
 

[Zhen Wang]

+1!
Besides the benefits Kevin listed, this change will hopefully have a
significant impact on the initial load latency.

On Wed, Jul 30, 2008 at 7:28 PM, Kevin Brown <et...@google.com> wrote:

I don't think so. The gadget xml spec should suffice. Supporting
features in the html response will also complicate static analysis of
gadgets (e.g. gadget directory filtering).

> localization, [Unsure: This may not be necessary since lang / country are
> sent to the remote site anyway] and invocation of
> gadgets.util.runOnLoadHandlers
>
> 5. The container MUST treat the response as a fully formed, valid HTML 4
> document. This includes honoring the doctype and not adding any additional
> CSS [Unsure: Other than skinning features?].

What if the returned doctype is XHTML? Should the container honor the
doctype or always treat it as HTML 4?

[Kevin Brown]

XHTML is not identified by doctype. If I specify an XHTML doctype, that doesn't make my document XHTML. For that, we'd have to get into mime type detection.

This comment was meant to say, essentially, that the container should trust what the developer sent as much as possible, including preserving their doctype, css, etc.

This means that if the response looks like this:

<![DOCTYPE whatever]>
<html>
<head><link rel="stylesheet" href="foo.css"/></head>
<body>
<script>
...some script
</script>
</body>
</html>

For a gadget like this:

<Module>
<Content type="html" view="canvas" authz="signed" sign_owner="true" sign_viewer="false href="http://example.org/gadget.php"/>
</Module>

The container should process it into something like

<![DOCTYPE whatever]>
<html>
<head>
<base href="http://example.org/gadget.php"/>
<link rel="stylesheet" href="foo.css"/>
<script src="http://www.containerdomain.com/opensocial/container-javascript-code.js"></script>
</head>
<body>
<script>
...some script...
gadgets.util.runOnLoadHandlers();
</script>
</body>
</html>

 

[Arne Roomann-Kurrik]

On Wed, Jul 30, 2008 at 7:28 PM, Kevin Brown <et...@google.com> wrote:

6. All links in the response document MUST be interpreted as relative to the specified /Content/@href value. Additionally, /Content/@href MUST be interpreted relative to the xml document itself. [Unsure: There are a variety of ways to achieve this, including link rewriting, injecting HTML base elements, or javascript. A specific mechanism probably doesn't need to be specified.]

Can you elaborate a bit more here?   Will links be fetched by the container and have their content processed according to steps 1-5?  It doesn't quite sound like this is what you mean, but supporting easier linking inside of canvas "pages" has been a feature request from developers for a while (and we've seen some hacky workarounds to address this issue).

~Arne

--
OpenSocial IRC - irc://irc.freenode.net/opensocial

[Kevin Brown]

On Thu, Jul 31, 2008 at 9:34 AM, Arne Roomann-Kurrik <kur...@google.com> wrote:

On Wed, Jul 30, 2008 at 7:28 PM, Kevin Brown <et...@google.com> wrote:

6. All links in the response document MUST be interpreted as relative to the specified /Content/@href value. Additionally, /Content/@href MUST be interpreted relative to the xml document itself. [Unsure: There are a variety of ways to achieve this, including link rewriting, injecting HTML base elements, or javascript. A specific mechanism probably doesn't need to be specified.]

Can you elaborate a bit more here?   Will links be fetched by the container and have their content processed according to steps 1-5? 

Yes, that's exactly what I had in mind. The end result should be that clicking on a link in an app stays inside the app (unless it's specified as opening a new tab or something). Depending on container policy, there are many ways to do this:

- Rewrite the link to call requestNavigateTo
- Rewrite the link to be a valid proxied url (for example, a container such as Shindig that uses security tokens could automatically append the token to each link)
- Intercept the links when they are clicked and take some other action.

It's not completely clear to me at the moment whether all subsequent clicks need authorization as well, but it's probably easier to just assume that they do and carry the authentication type forward for all dependent requests. If the developer is using signed auth, and the user clicks a link that doesn't require any auth, they can always simply skip validation.

Further refinement on this will be needed, and I'm hesitant to lay down anything concrete until we've got working implementations.
 

[Arne Roomann-Kurrik]

On Thu, Jul 31, 2008 at 10:15 AM, Kevin Brown <et...@google.com> wrote:

On Thu, Jul 31, 2008 at 9:34 AM, Arne Roomann-Kurrik <kur...@google.com> wrote:

On Wed, Jul 30, 2008 at 7:28 PM, Kevin Brown <et...@google.com> wrote:

6. All links in the response document MUST be interpreted as relative to the specified /Content/@href value. Additionally, /Content/@href MUST be interpreted relative to the xml document itself. [Unsure: There are a variety of ways to achieve this, including link rewriting, injecting HTML base elements, or javascript. A specific mechanism probably doesn't need to be specified.]

Can you elaborate a bit more here?   Will links be fetched by the container and have their content processed according to steps 1-5? 

Yes, that's exactly what I had in mind. The end result should be that clicking on a link in an app stays inside the app (unless it's specified as opening a new tab or something). Depending on container policy, there are many ways to do this:

- Rewrite the link to call requestNavigateTo
- Rewrite the link to be a valid proxied url (for example, a container such as Shindig that uses security tokens could automatically append the token to each link)
- Intercept the links when they are clicked and take some other action.

It's not completely clear to me at the moment whether all subsequent clicks need authorization as well, but it's probably easier to just assume that they do and carry the authentication type forward for all dependent requests. If the developer is using signed auth, and the user clicks a link that doesn't require any auth, they can always simply skip validation.

Would the idea of a session identifier make sense here?  I get a lot of developers wondering why $_SESSION doesn't work with content that is fetched via makeRequest - supplying a guid that tracks the current user would probably satisfy the development patterns they're used to without needing the overhead of signing each request.
 

Further refinement on this will be needed, and I'm hesitant to lay down anything concrete until we've got working implementations.

Reasonable.  I'm +1 for the current draft, understanding that it may need to change as someone attempts to implement it.  Are you aiming to include this into Shindig before adoption into the spec, then?
 

~Arne

[Kevin Brown]

On Thu, Jul 31, 2008 at 11:01 AM, Arne Roomann-Kurrik <kur...@google.com> wrote:

On Thu, Jul 31, 2008 at 10:15 AM, Kevin Brown <et...@google.com> wrote:

On Thu, Jul 31, 2008 at 9:34 AM, Arne Roomann-Kurrik <kur...@google.com> wrote:

On Wed, Jul 30, 2008 at 7:28 PM, Kevin Brown <et...@google.com> wrote:

6. All links in the response document MUST be interpreted as relative to the specified /Content/@href value. Additionally, /Content/@href MUST be interpreted relative to the xml document itself. [Unsure: There are a variety of ways to achieve this, including link rewriting, injecting HTML base elements, or javascript. A specific mechanism probably doesn't need to be specified.]

Can you elaborate a bit more here?   Will links be fetched by the container and have their content processed according to steps 1-5? 

Yes, that's exactly what I had in mind. The end result should be that clicking on a link in an app stays inside the app (unless it's specified as opening a new tab or something). Depending on container policy, there are many ways to do this:

- Rewrite the link to call requestNavigateTo
- Rewrite the link to be a valid proxied url (for example, a container such as Shindig that uses security tokens could automatically append the token to each link)
- Intercept the links when they are clicked and take some other action.

It's not completely clear to me at the moment whether all subsequent clicks need authorization as well, but it's probably easier to just assume that they do and carry the authentication type forward for all dependent requests. If the developer is using signed auth, and the user clicks a link that doesn't require any auth, they can always simply skip validation.

Would the idea of a session identifier make sense here?  I get a lot of developers wondering why $_SESSION doesn't work with content that is fetched via makeRequest - supplying a guid that tracks the current user would probably satisfy the development patterns they're used to without needing the overhead of signing each request.

The developer could do this (JSP and PHP as well as many other frameworks will do it automatically). That doesn't work for all developers though, which is why the requests would need to be re-proxied.
 

Further refinement on this will be needed, and I'm hesitant to lay down anything concrete until we've got working implementations.

Reasonable.  I'm +1 for the current draft, understanding that it may need to change as someone attempts to implement it.  Are you aiming to include this into Shindig before adoption into the spec, then?

As voted on some time ago in the aftermath of REST, nothing is finalized in the spec until there are working implementations. I'll definitely be doing it in Shindig, but I'm sure other implementations will try it out as well.

This won't be voted on for inclusion in the spec until 0.9, so we've got time to evaluate and get it right.

 

~Arne

[Louis Ryan]

One other thing I'd like to bring up is passing through a short-lived access token to the 3rd party server when fetching the content that can be used to make authenticated RESTful API calls. Even if this access token doesn't provide additional security semantics than what we have already proposed for the RESTful API it does provide a way for containers to distinguish between RESTful API traffic used to satisfy render requests and calls for other reasons. This is a useful tool to control quotas.

See comment below about preloads....

On Wed, Jul 30, 2008 at 8:09 PM, Kevin Brown <et...@google.com> wrote:

On Wed, Jul 30, 2008 at 7:56 PM, Louis Ryan <lr...@google.com> wrote:

I believe this will be a significant advance in the capability of the Gadgets platform and would likely be adopted by gadget developers in droves...

A couple of notes....

- A declarative syntax for the gadget developer to specify additional OpenSocial data to be passed to their backend when the gadget server requests content would allow developers to eliminate a large proportion of RESTful requests from their backend to the container while generating content. This should be a significant latency win. It may be sensible to say that the request to fetch the gadget content from the developers backend will always be POST to accomodate a payload even if initial implementations dont have one.

I agree with that -- where does this go though? Barring massive overhaul of the gadget xml (which I'm not necessarily opposed to) I don't see a clear way to put it in there. Perhaps we could extend Preload to support this?

I think the current discussion on OpenSocial data preloads is attempting to address this very issue and doesn't seem to require a massive overhaul. Whatever comes out of that discussion MUST address this issue as this is such a critical latency item IMHO.

[Kevin Brown]

Agreed -- if we can nail down the preloading behavior it should work pretty well for proxied content.

One additional item for clarification, though, is what to do for transitive links? If my original response outputs this:

<p><a href="someOtherPage.php">see other stuff</a></p>

Does that link need additional social data passed to it? Given that it's in response to a user action, extra latency is somewhat acceptable. For now, we could just have it pass the short-lived API token on these links, and if the developer needs additional data they can make the api calls for it.

[Kevin Brown]

While working on this implementation, it also occured to me that requestNavigateTo's parameters should be passed to the page in question. This can be used to ensure that urls that can be bookmarked will work under this model as well.

On Wed, Jul 30, 2008 at 7:28 PM, Kevin Brown <et...@google.com> wrote:

[chl...@yahoo.com]

On Jul 30, 7:56 pm, "Louis Ryan" <lr...@google.com> wrote:
> I believe this will be a significant advance in the capability of the
> Gadgets platform and would likely be adopted by gadget developers in
> droves...
>
> A couple of notes....
>
> - A declarative syntax for the gadget developer to specify additional
> OpenSocial data to be passed to their backend when the gadget server
> requests content would allow developers to eliminate a large proportion of
> RESTful requests from their backend to the container while generating
> content. This should be a significant latency win. It may be sensible to say
> that the request to fetch the gadget content from the developers backend
> will always be POST to accomodate a payload even if initial implementations
> dont have one.
>

+1 here.
Have we got the syntax nailed down?

> > be specified.]- Hide quoted text -
>
> - Show quoted text -

[chl...@yahoo.com]

On Aug 15, 2:20 pm, "Louis Ryan" <lr...@google.com> wrote:
> One other thing I'd like to bring up is passing through a short-lived access
> token to the 3rd party server when fetching the content that can be used to
> make authenticated RESTful API calls. Even if this access token doesn't
> provide additional security semantics than what we have already proposed for
> the RESTful API it does provide a way for containers to distinguish between
> RESTful API traffic used to satisfy render requests and calls for other
> reasons. This is a useful tool to control quotas.

Agree. In case of OAuth, we should actually pass the Access Token(AT)
and Access Token Secret (ATS) to the 3rd party server. Then the 3rd
party server will in turn sign the request with Consumer Key(CK),
Consumer Key Secret (CKS), AT and ATS when it tries to call RESTful
APIs provided by the container. Note, CK/CKS are issued by container
ahead of time.

> >>> be specified.]- Hide quoted text -
>

> - Show quoted text -- Hide quoted text -

[Kevin Brown]

On Mon, Sep 22, 2008 at 7:43 PM, <chl...@yahoo.com> wrote:

On Jul 30, 7:56 pm, "Louis Ryan" <lr...@google.com> wrote:
> I believe this will be a significant advance in the capability of the
> Gadgets platform and would likely be adopted by gadget developers in
> droves...
>
> A couple of notes....
>
> - A declarative syntax for the gadget developer to specify additional
> OpenSocial data to be passed to their backend when the gadget server
> requests content would allow developers to eliminate a large proportion of
> RESTful requests from their backend to the container while generating
> content. This should be a significant latency win. It may be sensible to say
> that the request to fetch the gadget content from the developers backend
> will always be POST to accomodate a payload even if initial implementations
> dont have one.
>

+1 here.
Have we got the syntax nailed down?

Discussion of syntax was moved to the data pipelining thread, since we want to avoid adding too much new syntax to support this.
 

[chl...@yahoo.com]

How about details on :

1. What parameters are passed from container to the application server
when requesting views.
2. How it is passed, get/post, and so on.


On Sep 22, 12:23 pm, "Kevin Brown" <e...@google.com> wrote:

> > > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -

[Kevin Brown]

On Thu, Sep 25, 2008 at 8:19 PM, <chl...@yahoo.com> wrote:

How about details on :

1. What parameters are passed from container to the application server
when requesting views.

This was mentioned earlier in the thread (sorry if it was lost). The proposed parameters to add were:

- country (as in current spec for Locale elements)
- lang (same)
- parameters for authentication (same as for gadgets.io.makeRequest specification)

If there are others that you think are important, please say so.
 

2. How it is passed, get/post, and so on.

The current proposal stands at using GET for the common case and POST when combined with preloaded social data. The social data preload is still somewhat undefined because we haven't been able to reach an agreement on syntax (attempting to align it with the requirements for OS templates). There's another thread discussing that syntax. We could possibly simplify this to always use POST.
 

[chl...@yahoo.com]

On Sep 25, 11:33 am, "Kevin Brown" <e...@google.com> wrote:

> On Thu, Sep 25, 2008 at 8:19 PM, <chl1...@yahoo.com> wrote:
>
> > How about details on :
>
> > 1. What parameters are passed from container to the application server
> > when requesting views.
>
> This was mentioned earlier in the thread (sorry if it was lost). The
> proposed parameters to add were:
>
> - country (as in current spec for Locale elements)
> - lang (same)
> - parameters for authentication (same as for gadgets.io.makeRequest
> specification)
>
> If there are others that you think are important, please say so.
>

-viewer guid
-owner guid
-oauth access token (used for calling back to container's RESTful
apis)
-oauth access token secret (used for calling back to container's
RESTful apis)
-user agent
-accept

[Kevin Brown]

On Thu, Sep 25, 2008 at 10:38 PM, <chl...@yahoo.com> wrote:

On Sep 25, 11:33 am, "Kevin Brown" <e...@google.com> wrote:

> On Thu, Sep 25, 2008 at 8:19 PM, <chl1...@yahoo.com> wrote:
>
> > How about details on :
>
> > 1. What parameters are passed from container to the application server
> > when requesting views.
>
> This was mentioned earlier in the thread (sorry if it was lost). The
> proposed parameters to add were:
>
> - country (as in current spec for Locale elements)
> - lang (same)
> - parameters for authentication (same as for gadgets.io.makeRequest
> specification)
>
> If there are others that you think are important, please say so.
>

-viewer guid
-owner guid
-oauth access token (used for calling back to container's RESTful
apis)
-oauth access token secret (used for calling back to container's
RESTful apis)

All of these are required in the 'parameters for authentication', as described in the makeRequest specification.
 

-user agent
-accept

We should probably define a more general notion of which HTTP headers get forwarded. Adding these to the query string would be very awkward.

[chl...@yahoo.com]

Will proxied request be treated same as makeReqeust in term of sending
parameters? If so, that probably covers it.


On Sep 25, 2:26 pm, "Kevin Brown" <e...@google.com> wrote:

> forwarded. Adding these to the query string would be very awkward.- Hide quoted text -

[Kevin Brown]

On Mon, Sep 29, 2008 at 11:42 AM, <chl...@yahoo.com> wrote:

Will proxied request be treated same as makeReqeust in term of sending
parameters? If so, that probably covers it.

Yes, with the addition of lang and country params which makeRequest currently doesn't send by default (the user could always add them manually, of course).
 

[Brian Eaton]

On Thu, Sep 25, 2008 at 1:38 PM, <chl...@yahoo.com> wrote:
> -oauth access token (used for calling back to container's RESTful
> apis)
> -oauth access token secret (used for calling back to container's
> RESTful apis)

This one is new, and I think unnecessary. OAuth for REST did not
(last time I looked) use an access token by default.

Instead the gadget home server uses two-legged OAuth to call into the
REST-ful APIs.

[Kevin Brown]

Is it possible for the token to be implementation defined, and simply an opaque string?
 

[Brian Eaton]

On Mon, Sep 29, 2008 at 3:02 PM, Kevin Brown <et...@google.com> wrote:
>> This one is new, and I think unnecessary. OAuth for REST did not
>> (last time I looked) use an access token by default.
>>
>> Instead the gadget home server uses two-legged OAuth to call into the
>> REST-ful APIs.
>
> Is it possible for the token to be implementation defined, and simply an
> opaque string?

First question is why, second question is how.

Why? There is sufficient information on a two-legged OAuth call to
make all of the necessary authorization checks, OAuth access tokens
seems unnecessary.

How? How should the container site pass the OAuth access token to the
gadget home server when the gadget is first installed?

[Kevin Brown]

Another addendum:

For relative urls, I believe the following is most appropriate:

- When the content in question came from a remote url (/Content/@href), use that url as the base.
- When the content was inline in the gadget xml, use the gadget's url as the base.

So, if I have this gadget at http://example.org/gadget.xml

<Content view="profile"><a href="profile.html">Click here</a></Content>
<Content view="canvas" href="/proxied/proxied.php"/>

where proxied.php returns:

<a href="canvas.html">Click here</a>

The resolved urls become http://example.org/profile.html and http://example.org/proxied/canvas.html, respectively.

This makes it easier to move the gadget, and many more existing applications / websites can become opensocial apps without additional work.

Does anyone disagree with this approach?

[Adam Winer]

On Wed, Oct 1, 2008 at 4:49 PM, Kevin Brown <et...@google.com> wrote:
> Another addendum:
>
> For relative urls, I believe the following is most appropriate:
>
> - When the content in question came from a remote url (/Content/@href), use
> that url as the base.
> - When the content was inline in the gadget xml, use the gadget's url as the
> base.
>
> So, if I have this gadget at http://example.org/gadget.xml
>
> <Content view="profile"><a href="profile.html">Click here</a></Content>
> <Content view="canvas" href="/proxied/proxied.php"/>
>
> where proxied.php returns:
>
> <a href="canvas.html">Click here</a>
>
> The resolved urls become http://example.org/profile.html and
> http://example.org/proxied/canvas.html, respectively.
>
> This makes it easier to move the gadget, and many more existing applications
> / websites can become opensocial apps without additional work.
>
> Does anyone disagree with this approach?

Totally agree with the approach, but a question: do "links" refer
strictly to anchor tags, or to all relative URLs (e.g IMG, SCRIPT)?
The language isn't clear. I strongly prefer the latter option.

-- Adam

[Kevin Brown]

On Thu, Oct 2, 2008 at 8:28 AM, Adam Winer <awi...@gmail.com> wrote:

On Wed, Oct 1, 2008 at 4:49 PM, Kevin Brown <et...@google.com> wrote:
> Another addendum:
>
> For relative urls, I believe the following is most appropriate:
>
> - When the content in question came from a remote url (/Content/@href), use
> that url as the base.
> - When the content was inline in the gadget xml, use the gadget's url as the
> base.
>
> So, if I have this gadget at http://example.org/gadget.xml
>
> <Content view="profile"><a href="profile.html">Click here</a></Content>
> <Content view="canvas" href="/proxied/proxied.php"/>
>
> where proxied.php returns:
>
> <a href="canvas.html">Click here</a>
>
> The resolved urls become http://example.org/profile.html and
> http://example.org/proxied/canvas.html, respectively.
>
> This makes it easier to move the gadget, and many more existing applications
> / websites can become opensocial apps without additional work.
>
> Does anyone disagree with this approach?

Totally agree with the approach, but a question:  do "links" refer
strictly to anchor tags, or to all relative URLs (e.g IMG, SCRIPT)?
The language isn't clear.  I strongly prefer the latter option.

All urls in the gadget, as I specified in the original proposal.

[chl...@yahoo.com]

On Sep 29, 3:52 pm, "Brian Eaton" <bea...@google.com> wrote:

> On Mon, Sep 29, 2008 at 3:02 PM, Kevin Brown <e...@google.com> wrote:
> >> This one is new, and I think unnecessary.  OAuth for REST did not
> >> (last time I looked) use an access token by default.
>
> >> Instead the gadget home server uses two-legged OAuth to call into the
> >> REST-ful APIs.
>
> > Is it possible for the token to be implementation defined, and simply an
> > opaque string?
>
> First question is why, second question is how.
>
> Why?  There is sufficient information on a two-legged OAuth call to
> make all of the necessary authorization checks, OAuth access tokens
> seems unnecessary.
>

The question is whether developer can use 2-legged oauth to make 3
legged call. In proxied case, when remote app want to call to get a
user's profile, shouldn't he use 3 legged token?

> How?  How should the container site pass the OAuth access token to the
> gadget home server when the gadget is first installed?

In OAuth 1.1, the access token is a temporary token rather then the
access token in the OAuth 1.0 which is persitent token. We should not
transfer OAuth1.0 access token in every request, but we probably can
for OAuth1.1 since it does not last long.

I think we are facing a much bigger question here. In current Shindig
implementation, container maintain the AT/ATS for each services the
application will use. This works fine for non-proxied app. For Proxied
app, where the credential should be? We need Brian Eaton to comment on
this.

[Scott Seely]

Do we have any updates to this proposal?

On Oct 2, 12:55 pm, chl1...@yahoo.com wrote:
> On Sep 29, 3:52 pm, "Brian Eaton" <bea...@google.com> wrote:
>
> > On Mon, Sep 29, 2008 at 3:02 PM, Kevin Brown <e...@google.com> wrote:
> > >> This one is new, and I think unnecessary.  OAuth for REST did not
> > >> (last time I looked) use an access token by default.
>
> > >> Instead the gadget home server uses two-legged OAuth to call into the
> > >> REST-ful APIs.
>
> > > Is it possible for the token to be implementation defined, and simply an
> > > opaque string?
>
> > First question is why, second question is how.
>
> > Why?  There is sufficient information on a two-legged OAuth call to
> > make all of the necessary authorization checks, OAuth access tokens
> > seems unnecessary.
>
> The question is whether developer can use 2-legged oauth to make 3

> legged call. Inproxiedcase, when remote app want to call to get a

[Kevin Brown]

The main outstanding issue is alignment between this and data pipelining.

[Chris Chabot]

See my lengthier rant response on the other thread for my longer reply :)

Can we do something to make alignment happen between these 2 proposals? Is there anyone willing to do the work on drafting a proposal for how these 2 can become part of the same spec/solution, or should we organize a (open for anyone) get-together some evening in which we try to get the different sides closer together and hopefully even resolve this?

   -- Chris

[Kevin Brown]

As promised, formal spec (and changes to existing) linked below

http://docs.google.com/Doc?id=dgf9q4v4_4824762fk

I may not be able to respond as quickly as I'd like this week due to a family emergency. Evan Gilbert and Louis Ryan can speak for me on any concerns in the meanwhile.

[Evan Gilbert]

I like this a lot, a few possible enhancements...

You should be able to send viewer / owner information without signing a request, so @sign_owner and @sign_viewer seem possibly limiting. Instead of sign_owner and sign_viewer, possibly we can have an @fields parameter with a comma delimited list of names of standard fields to send? Values would be "viewer", "owner", "lang", and "country" (added lang/country because provide no benefits unless developer is expecting them). Container would sign viewer/owner if @authz="signed" or "oauth"

For caching, I think we should also support sending the relationship between viewer and owner. Developers might have a standard view for friends that is different than anonymous viewing. A possible implementation would be to add a field parameter "relationship", with possible values "none", "@friend", "@owner". This parameter would need to be signed as well. Container could also send arbitrary group IDs (i.e. "@coworker") in relationship - the values wouldn't be defined by the spec, but would give some flexibility for providers with more than 1 type of relationship.

I'm worried about sending Data Pipelining content as a POST body but caching by URL - this makes it easy for a container to accidentally cache viewer-specific information in a URL that is shown to all users. A fix for this would be to add fields "viewer" or "owner" to the request URL if a userId of "@viewer" or @owner" is present in any of the data pipelining calls. I think this is sufficient to cover the common caching use cases.

[Kevin Brown]

On Wed, Nov 12, 2008 at 11:10 AM, Evan Gilbert <uid...@google.com> wrote:

I like this a lot, a few possible enhancements...

You should be able to send viewer / owner information without signing a request, so @sign_owner and @sign_viewer seem possibly limiting. Instead of sign_owner and sign_viewer, possibly we can have an @fields parameter with a comma delimited list of names of standard fields to send? Values would be "viewer", "owner", "lang", and "country" (added lang/country because provide no benefits unless developer is expecting them). Container would sign viewer/owner if @authz="signed" or "oauth"

That's really an orthogonal problem. These values come directly from makeRequest semantics, and the intent is that the two be intrinsically linked. Having different behavior for different request types creates even more confusion.
 

[Evan Gilbert]

On Wed, Nov 12, 2008 at 12:03 PM, Kevin Brown <et...@google.com> wrote:

On Wed, Nov 12, 2008 at 11:10 AM, Evan Gilbert <uid...@google.com> wrote:

I like this a lot, a few possible enhancements...

You should be able to send viewer / owner information without signing a request, so @sign_owner and @sign_viewer seem possibly limiting. Instead of sign_owner and sign_viewer, possibly we can have an @fields parameter with a comma delimited list of names of standard fields to send? Values would be "viewer", "owner", "lang", and "country" (added lang/country because provide no benefits unless developer is expecting them). Container would sign viewer/owner if @authz="signed" or "oauth"

That's really an orthogonal problem. These values come directly from makeRequest semantics, and the intent is that the two be intrinsically linked. Having different behavior for different request types creates even more confusion.

Not entirely orthogonal. Developers can add viewer & owner to unsigned makeRequest() calls manually by appending to the URL in JavaScript. There is no ability to accomplish the same thing with a declarative <Content> tag.

We could pass unsigned viewer/owner/etc. as separate fields from the signed ones. This feels duplicative, but does have the advantage that it makes it clear when data can be trusted to have come from the container.
 

[Arne Roomann-Kurrik]

Is there any reason not to sign requests with owner and viewer data?  It seems like developers will use the path of least resistance here, which means more apps will have vulnerabilities in the form of "POST forged data to app API endpoint to change arbitrary user data"

~Arne

--
OpenSocial IRC - irc://irc.freenode.net/opensocial

[Adam Winer]

As renders, the risk of mutating state via forged data seems low-ish, but I agree, always signing is reasonable and I'd be interested in reasons why we shouldn't require signing.

FWIW, my current prototype of adding data pipelining to proxied rendering in Shindig:

   http://codereview.appspot.com/8648/show

... does require that any use of data pipelining with owner and/or viewer data is signed accordingly.

-- Adam

[Charlie Jiang]

Hi Kevin,

 

In the doc, you mentioned that POST body should be part of cache key. How can that happen? Usually post invalidates cache rather than being cached.

 

-Charlie

 

---

[Brian Eaton]

On the topic of caching: for OAuth requests we should use the access
token as part of the cache key. This is required for cases where
three legged OAuth is used for authentication.