Proxy forwarding cookies

[Piotr Jaroszyński <p....@gmail.com>]

Hello,

I have already asked this question on the gadgets-api mailing list - [1], but 
I suppose here might be a better place.

I am wondering whether adding an option to forward cookies from the fetched 
sites back to the gadgets would be something desirable? Where by forward I 
mean just passing them along other content to the callback function if e.g. 
GET_COOKIES option was specified. Looking at the proxy code it doesn't seem 
hard to do.

[1] - 
http://groups.google.com/group/Google-Gadgets-API/browse_thread/thread/b857a8ecd448c01

-- 
Best Regards,
Piotr Jaroszyński

Re: Proxy forwarding cookies

[Piotr Jaroszyński <p....@gmail.com>]

On Thursday 31 of January 2008 18:27:08 Brian Eaton wrote:
> On Jan 31, 2008 7:43 AM, Piotr Jaroszyński <p....@gmail.com> wrote:
> > I understand the problems with that, but that's not what I am proposing
> > here. You are talking about gadget <-> user stuff and I am talking about
> > gadget <-> proxy <-> 3rd-party site. What I want to be able to do is to
> > fetch the cookies sent by the 3rd-party site to the proxy and handle them
> > in the gadget, e.g. use for another fetch of the 3rd-party site. User's
> > browser wouldn't be involved in that at all. Think about the cookies as
> > extra data you get along the fetched content.
>
> I agree, it would be cool to have a way to do this.  The HEADERS
> parameter to makeRequest (currently unimplemented) might be where to
> start.

Happy to hear that!

Implementation of the HEADERs (it is cool for other reasons too and seems 
rather simple to do) in make_request is indeed necessary to handle the 
gadget -> proxy -> 3rd-party site part. I have actually managed to make it 
work with the old(current) gadget API by hacking with the internals of 
_IG_FetchContent a bit (the google proxy already has the support for extra 
headers). The other way around would need additional changes.

btw. how close is the shindig project to how Google is doing things? Do 
changes made here have a good chance of being backported to the Google 
backend?

-- 
Best Regards,
Piotr Jaroszyński

Re: Proxy forwarding cookies

[Piotr Jaroszyński <p....@gmail.com>]

On Thursday 31 of January 2008 23:00:55 Kevin Brown wrote:
> If they're not being used as real cookies, there's not a lot of value in
> constraining them. If you want data from a third party site, just get it
> back as part of the normal response. Sending cookies certainly has value,
> but retrieving them doesn't seem to offer any real benefit over just
> including that data in the message body.

They are real cookies in the proxy <-> 3rd-party site context. I just don't 
see why they must be treated specially in the gadget context yet, but I will 
think about the Bruno's example once I learn how Cajo works.

-- 
Best Regards,
Piotr Jaroszyński

Re: Proxy forwarding cookies

[Bruno Bowden <br...@google.com>]

> If they're not being used as real cookies, there's not a lot of value in
> constraining them. If you want data from a third party site, just get it
> back as part of the normal response. Sending cookies certainly has value,
> but retrieving them doesn't seem to offer any real benefit over just
> including that data in the message body.
>

This is more syntactic sugar than anything. I agree is doesn't add
functionality but it would make porting easier and allow more shared code
with the web service and gadget version.

Re: Proxy forwarding cookies

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

On Jan 31, 2008 11:49 AM, Piotr Jaroszyński <p....@gmail.com> wrote:

> On Thursday 31 of January 2008 20:26:45 Bruno Bowden wrote:
> > > That's an interesting idea. I think it could work for most cases, but
> > > some lower level API would be nice too, if greater flexibility is
> > > necessary.
> >
> > Whatever we do, the "cookie" should never be manipulated directly. For
> > Caja, it's important that we use an interface so that we can change
> > implementation - as Kevin mentioned, Caja will not allow you manipulate
> a
> > cookie directly.
>
> I don't quite understand this point. A cookie, fetched from a 3rd-party
> site
> via the proxy, from the gadget POV is just a list of key value pairs. I
> don't
> see how even manipulating that data directly can do any harm?


If they're not being used as real cookies, there's not a lot of value in
constraining them. If you want data from a third party site, just get it
back as part of the normal response. Sending cookies certainly has value,
but retrieving them doesn't seem to offer any real benefit over just
including that data in the message body.

Re: Proxy forwarding cookies

[Bruno Bowden <br...@google.com>]

> > Whatever we do, the "cookie" should never be manipulated directly. For
> > Caja, it's important that we use an interface so that we can change
> > implementation - as Kevin mentioned, Caja will not allow you manipulate
> a
> > cookie directly.
>
> I don't quite understand this point. A cookie, fetched from a 3rd-party
> site
> via the proxy, from the gadget POV is just a list of key value pairs. I
> don't
> see how even manipulating that data directly can do any harm?


Consider a Cajoled gadget that's inlined on the container page. If the
cajoled gadget was able to access the cookie directly, then it would be
using the same cookie that the site does - that's insecure and allows naming
collisions. For these reasons Caja will prevent access to the cookie
entirely. An interface like a cookie, that acts as one on the proxy
satisfies Caja and the behaviour you want.

Re: Proxy forwarding cookies

[Piotr Jaroszyński <p....@gmail.com>]

On Thursday 31 of January 2008 20:26:45 Bruno Bowden wrote:
> > That's an interesting idea. I think it could work for most cases, but
> > some lower level API would be nice too, if greater flexibility is
> > necessary.
>
> Whatever we do, the "cookie" should never be manipulated directly. For
> Caja, it's important that we use an interface so that we can change
> implementation - as Kevin mentioned, Caja will not allow you manipulate a
> cookie directly.

I don't quite understand this point. A cookie, fetched from a 3rd-party site 
via the proxy, from the gadget POV is just a list of key value pairs. I don't 
see how even manipulating that data directly can do any harm?

> To make the feedback loop tighter, we should provide better tools for
> developers. Checking the gadget DOM, intercepting makeRequests and so on,
> can all provide useful feedback. When a developer is adding their gadget to
> the directory, advising them that their image fetches aren't being cached
> and could swamp their servers, would be very helpful. Encoding those best
> practices into an automated tool would help developers a lot.

Mmmm, these are really good ideas.

-- 
Best Regards,
Piotr Jaroszyński

Re: Proxy forwarding cookies

[Bruno Bowden <br...@google.com>]

> That's an interesting idea. I think it could work for most cases, but some
> lower level API would be nice too, if greater flexibility is necessary.


Whatever we do, the "cookie" should never be manipulated directly. For Caja,
it's important that we use an interface so that we can change implementation
- as Kevin mentioned, Caja will not allow you manipulate a cookie directly.

> For sites that are dependent on cookies, this would make porting to a
> > gadget much easier. I'm sure there are more issues, e.g. cost of
> uploading
> > large cookies.
>
> Hmm, large cookies, didn't think about this... We could probably limit the
> cookie size, but on the other hand I think slow gadgets will just die on
> their own :)


When a user removes a gadget (e.g. if it's slow or doesn't work), we use
that information to drive ranking in the directory. That's a long feedback
loop.

To make the feedback loop tighter, we should provide better tools for
developers. Checking the gadget DOM, intercepting makeRequests and so on,
can all provide useful feedback. When a developer is adding their gadget to
the directory, advising them that their image fetches aren't being cached
and could swamp their servers, would be very helpful. Encoding those best
practices into an automated tool would help developers a lot.

--
> Best Regards,
> Piotr Jaroszyński
>

Re: Proxy forwarding cookies

[Piotr Jaroszyński <p....@gmail.com>]

On Thursday 31 of January 2008 18:27:39 Bruno Bowden wrote:
> That's a very interesting point Piotr. What about a special type of
> UserPref that has the same interface as a cookie. The makeRequest would
> then treat that UserPref as the cookie data when communicating with the
> proxy (whether it puts the data in the request or not is an implementation
> detail). Then on the proxy, it would retrieve that data and use it as a
> real cookie on the external request. If the request result included
> changing the cookie, that data would be passed all the way back to the
> UserPref.

That's an interesting idea. I think it could work for most cases, but some 
lower level API would be nice too, if greater flexibility is necessary.

> For sites that are dependent on cookies, this would make porting to a
> gadget much easier. I'm sure there are more issues, e.g. cost of uploading
> large cookies.

Hmm, large cookies, didn't think about this... We could probably limit the 
cookie size, but on the other hand I think slow gadgets will just die on 
their own :)

-- 
Best Regards,
Piotr Jaroszyński

Re: Proxy forwarding cookies

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

On Jan 31, 2008 7:43 AM, Piotr Jaroszyński <p....@gmail.com> wrote:
> I understand the problems with that, but that's not what I am proposing here.
> You are talking about gadget <-> user stuff and I am talking about gadget <->
> proxy <-> 3rd-party site. What I want to be able to do is to fetch the
> cookies sent by the 3rd-party site to the proxy and handle them in the
> gadget, e.g. use for another fetch of the 3rd-party site. User's browser
> wouldn't be involved in that at all. Think about the cookies as extra data
> you get along the fetched content.

I agree, it would be cool to have a way to do this.  The HEADERS
parameter to makeRequest (currently unimplemented) might be where to
start.

Cheers,
Brian

Re: Proxy forwarding cookies

[Bruno Bowden <br...@google.com>]

That's a very interesting point Piotr. What about a special type of UserPref
that has the same interface as a cookie. The makeRequest would then treat
that UserPref as the cookie data when communicating with the proxy (whether
it puts the data in the request or not is an implementation detail). Then on
the proxy, it would retrieve that data and use it as a real cookie on the
external request. If the request result included changing the cookie, that
data would be passed all the way back to the UserPref.

For sites that are dependent on cookies, this would make porting to a gadget
much easier. I'm sure there are more issues, e.g. cost of uploading large
cookies.


On Jan 31, 2008 7:43 AM, Piotr Jaroszyński <p....@gmail.com> wrote:

> On Thursday 31 of January 2008 16:25:39 Reinoud Elhorst wrote:
> > The problem is that the gadget is being loaded from (for instance)
> > a.gmodules.com. This mean that any cookies that get set are set on
> > a.gmodules.com. This is a restriction in the browser. The security issue
> is
> > here:
> > (snip)
>
> I understand the problems with that, but that's not what I am proposing
> here.
> You are talking about gadget <-> user stuff and I am talking about gadget
> <->
> proxy <-> 3rd-party site. What I want to be able to do is to fetch the
> cookies sent by the 3rd-party site to the proxy and handle them in the
> gadget, e.g. use for another fetch of the 3rd-party site. User's browser
> wouldn't be involved in that at all. Think about the cookies as extra data
> you get along the fetched content.
>
> --
> Best Regards,
> Piotr Jaroszyński
>

Re: Proxy forwarding cookies

[Piotr Jaroszyński <p....@gmail.com>]

On Thursday 31 of January 2008 16:25:39 Reinoud Elhorst wrote:
> The problem is that the gadget is being loaded from (for instance)
> a.gmodules.com. This mean that any cookies that get set are set on
> a.gmodules.com. This is a restriction in the browser. The security issue is
> here:
> (snip)

I understand the problems with that, but that's not what I am proposing here. 
You are talking about gadget <-> user stuff and I am talking about gadget <-> 
proxy <-> 3rd-party site. What I want to be able to do is to fetch the 
cookies sent by the 3rd-party site to the proxy and handle them in the 
gadget, e.g. use for another fetch of the 3rd-party site. User's browser 
wouldn't be involved in that at all. Think about the cookies as extra data 
you get along the fetched content.

-- 
Best Regards,
Piotr Jaroszyński

Re: Proxy forwarding cookies

[Reinoud Elhorst <cl...@claude.nl>]

The problem is that the gadget is being loaded from (for instance)
a.gmodules.com. This mean that any cookies that get set are set on
a.gmodules.com. This is a restriction in the browser. The security issue is
here:
Other gadgets that run on a.gmodules.com can read/write/alter your cookies
(since from a browsers point of view, it's the same domain)
The other problem is that next time your gadget is shown, it may be served
from b.gmodules.com, so you can't read your cookie back (again: browser
security).
There is no way that your cookie will ever be returned when the user goes to
your own website!

(actually, you might be able to do some of the things you want by using an
iframe within your gadget, but that is totally outside the scope of this
document. Also, that functionality will probably cease to exist if
containers require caja.



On 1/31/08, Piotr Jaroszyński <p....@gmail.com> wrote:
>
> On Thursday 31 of January 2008 13:58:17 Reinoud Elhorst wrote:
> > I was about to answer, then I remembered Kevin having done that before:
> >
> > (snip)
>
> That's not what I meant. I don't want to be able to push cookies to the
> users
> browsers. What I want to be able to do is something like that:
> gadgets.io.makeRequest("example.org/?user=foo&pass=blah, callback, {
> GET_COOKIES: true }), and the callback function would save the cookie for
> later use in example.org fetches like:
> gadgets.io.makeRequest("example.org", callback, { HEADERS: { "Cookie" :
> my_saved_cookie} })
>
> --
> Best Regards,
> Piotr Jaroszyński
>

Re: Proxy forwarding cookies

[Piotr Jaroszyński <p....@gmail.com>]

On Thursday 31 of January 2008 13:58:17 Reinoud Elhorst wrote:
> I was about to answer, then I remembered Kevin having done that before:
>
> (snip)

That's not what I meant. I don't want to be able to push cookies to the users 
browsers. What I want to be able to do is something like that:
gadgets.io.makeRequest("example.org/?user=foo&pass=blah, callback, { 
GET_COOKIES: true }), and the callback function would save the cookie for 
later use in example.org fetches like:
gadgets.io.makeRequest("example.org", callback, { HEADERS: { "Cookie" : 
my_saved_cookie} })

-- 
Best Regards,
Piotr Jaroszyński

Re: Proxy forwarding cookies

[Reinoud Elhorst <cl...@claude.nl>]

I was about to answer, then I remembered Kevin having done that before:

"You may want to save cookies, but we explicitly don't do it on purpose,
because it's a big security vulnerability. You can never rely on cookies
being available between page renders (on igoogle the domain changes every
time you move a gadget on your page and on orkut the domain changes every
month or so), and when gadgets are cajoled writing cookies will be disabled
completely. Gadget developers are told to use setprefs for storing data (and
with open social we'll have the infinitely more robust appdata to rely on).
The parent site may store / read cookies to implement setprefs and appdata,
but actual cookie interaction is intentionally not a part of the gadget spec
for these reasons."

So, basically, the answer tot your
question is that you shouldn't want to use cookies.


On 1/31/08, Piotr Jaroszyński <p....@gmail.com> wrote:
>
> Hello,
>
> I have already asked this question on the gadgets-api mailing list - [1],
> but
> I suppose here might be a better place.
>
> I am wondering whether adding an option to forward cookies from the
> fetched
> sites back to the gadgets would be something desirable? Where by forward I
> mean just passing them along other content to the callback function if e.g
> .
> GET_COOKIES option was specified. Looking at the proxy code it doesn't
> seem
> hard to do.
>
> [1] -
>
> http://groups.google.com/group/Google-Gadgets-API/browse_thread/thread/b857a8ecd448c01
>
> --
> Best Regards,
> Piotr Jaroszyński
>