data returned from gadgets.io.makeRequest

[Brian Eaton]

(For possible inclusion in opensocial 0.9)

The callback function passed to gadgets.io.makeRequest is called with
an object containing various attributes about the response. Those
attributes are:

text: the body of the response
data: a parsed version of the text, depending on the content-type
requested. At the moment this can be either XML or JSON.
errors: a list of errors (no semantics defined as yet)
oauthApprovalUrl, oauthError, oauthErrorText: used for OAuth responses

I've been looking at integration of gadgets.io.makeRequest with
various web apps, and I think we should add a couple of additional
parameters to that list.

rc: the HTTP response code
headers: a javascript object with HTTP headers returned from the response.

We should not return all of the HTTP headers, because most are not
useful to clients, and returning them all would waste bandwidth. I'd
like to return just the set-cookie and location headers for now. We
can add more as needed.

Comments?

[Zhen Wang]

While this sounds like a nice feature to me, I'm curious to know some
typical use cases which will benefit from the extra information
returned by makeRequest.

[Brian Eaton]

On Mon, Sep 8, 2008 at 11:56 AM, Zhen Wang <wa...@google.com> wrote:
> While this sounds like a nice feature to me, I'm curious to know some
> typical use cases which will benefit from the extra information
> returned by makeRequest.

Right now you can't use makeRequest to work with any site that
requires cookies. As an example, the google calendar web service
requires cookies, and so you can't use it through makeRequest.

[Zhen Wang]

Returning set-cookie header from a makeRequest call doesn't solve this
problem, or does it? I'd assume that we'll also need to allow
developers to set cookies through makeRequest.

[Kevin Brown]

On Mon, Sep 8, 2008 at 2:14 PM, Zhen Wang <wa...@google.com> wrote:

Returning set-cookie header from a makeRequest call doesn't solve this
problem, or does it? I'd assume that we'll also need to allow
developers to set cookies through makeRequest.

Correct.

Currently, we don't actively restrict what they can send in the spec. The "headers" param has no documented restriction.

In practice, though, very few containers are likely allowing this. Shindig (and by extension all containers based on it) certainly doesn't.

I worry about the security implications of allowing Cookie headers in the request, but if the web service in question can be used in another way (say, passing a session id in the Set-Cookie but accepting it in the query string), it's probably ok.

I'm +1 on allowing the headers to be returned in the makeRequest response, but I'm -1 on blindly allowing Cookie headers sent to makeRequest. The potential for exploits here seems very high to me.
 

[Brian Eaton]

On Mon, Sep 8, 2008 at 2:33 PM, Kevin Brown <et...@google.com> wrote:
> I worry about the security implications of allowing Cookie headers in the
> request, but if the web service in question can be used in another way (say,
> passing a session id in the Set-Cookie but accepting it in the query
> string), it's probably ok.
>
> I'm +1 on allowing the headers to be returned in the makeRequest response,
> but I'm -1 on blindly allowing Cookie headers sent to makeRequest. The
> potential for exploits here seems very high to me.

What's the practical difference between allowing javascript to specify
cookies in headers vs the same parameter in a query string?

The main differences between the two mechanisms in a normal web app are:
1) Cookies are sent automatically, so developers need to think about
other mechanisms of CSRF protection if they are using cookies.
2) Referer headers can leak, so if developers are sticking secrets in
URLs they need to be careful about creating links to untrusted sites.
3) Sticking session IDs in query parameters requires careful
programming. Sticking them in cookies is easy.

AFAICT, none of those issues are relevant for apps built using
gadgets.io.makeRequest.

The one new security concern I can see is HTTP request smuggling,
where someone passes a cookie name like "foo\nbar", confusing various
HTTP proxy servers. That's a risk today, it applies to any API that
lets people specify header names or values.

[jeremi]

Hi,
What is the status of this proposition in the specs for opensocial
0.9?

Would it be possible to have a parameter in RequestParameters such
as :
<static> object GET_HEADER
if the response contains header, it return all the headers; defaults
to false.

For example, this can be useful when you want to connect to a webdav
backend.
https://issues.apache.org/jira/browse/SHINDIG-882

Thanks,
Jeremi

[Scott Seely]

This isn't in 0.9. You can check on what is and is not in 0.9 by going
to http://opensocial-resources.googlecode.com/svn/spec/draft/.