You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Fernando Padilla <fe...@alum.mit.edu> on 2008/06/28 21:40:11 UTC
cookie support
Hello.
I was wondering if there is any plans to have the shindig makeRequest
proxies support cookies between the proxy and the server side? Facebook
supports this, and it's quite useful to be able to use standard
server-side frameworks within signed requests sent via makeRequest.
Re: cookie support
Posted by Brian Eaton <be...@google.com>.
On Sat, Jun 28, 2008 at 1:13 PM, Kevin Brown <et...@google.com> wrote:
> No, cookies are intentionally avoided in opensocial, because there's no way
> to guarantee the host your gadget will render on will be the same for two
> renders (and, therefore, this becomes useless).
We could implement cookies for makeRequest without using the browser
cookie jar. We'd have to build our own, using the hostname passed
into makeRequest rather than domain the gadget is rendered on.
Re: cookie support
Posted by Brian Eaton <be...@google.com>.
On Mon, Jun 30, 2008 at 9:16 AM, Michael Ryan (Software Developer)
<Mi...@apollogrp.edu> wrote:
> Why not just have your gadget request a key/token based on the user (or
> oauth) then you can use this in place of a session cookie, just adding
> it to each request to your server? This would be more reliable across
> different implementations.
Because the end goal is "able to use standard server-side frameworks".
Re: cookie support
Posted by Fernando Padilla <fe...@alum.mit.edu>.
more reliable yes, but lots more tweaking into the guts of the framework
used.. ( tomcat, jetty, websphere, etc ). And even then, this only
works for people that support server-side sessions.. it wasn't too long
that we avoided those for performance reasons, thus offloading all state
to the cookies..
just food for thought, if this feature resonates with others.. it's a
nice to have feature to give developers options..
Michael Ryan (Software Developer) wrote:
> Why not just have your gadget request a key/token based on the user (or
> oauth) then you can use this in place of a session cookie, just adding
> it to each request to your server? This would be more reliable across
> different implementations.
>
RE: cookie support
Posted by "Michael Ryan (Software Developer)" <Mi...@apollogrp.edu>.
Why not just have your gadget request a key/token based on the user (or
oauth) then you can use this in place of a session cookie, just adding
it to each request to your server? This would be more reliable across
different implementations.
--
Michael J. Ryan -- Software Developer -- Apollo Group
> -----Original Message-----
> From: Kevin Brown [mailto:etnu@google.com]
> Sent: Saturday, June 28, 2008 1:13 PM
> To: shindig-dev@incubator.apache.org
> Subject: Re: cookie support
>
> On Sat, Jun 28, 2008 at 12:40 PM, Fernando Padilla <fe...@alum.mit.edu>
> wrote:
>
> > Hello.
> >
> > I was wondering if there is any plans to have the shindig
makeRequest
> > proxies support cookies between the proxy and the server side?
> Facebook
> > supports this, and it's quite useful to be able to use standard
> server-side
> > frameworks within signed requests sent via makeRequest.
> >
>
> No, cookies are intentionally avoided in opensocial, because there's
no
> way
> to guarantee the host your gadget will render on will be the same for
> two
> renders (and, therefore, this becomes useless).
>
> Every gadget has to be rendered on a unique subdomain to prevent
> cross-gadget scripting.
>
> You might be able to get away with using just session cookies, but it
> would
> be very hard to rely on it unless it's standardized throughout
> opensocial,
> which creates just another area where code has to be forked.
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
Re: cookie support
Posted by Brian Eaton <be...@google.com>.
On Tue, Jul 1, 2008 at 10:49 AM, Louis Ryan <lr...@google.com> wrote:
> Is the goal here to have this cookie carry across multiple renders of the
> same gadget or just for requests within a single rendering of a gadget? In
> containers like Orkut where viewer data is hidden from a gadget unless
> explicit permission is granted allowing cookies to track a user across
> multiple renders of the same gadget would likely be blocked.
document.cookie is available to gadgets, so we can't really stop them
from assigning users their own identifiers. There are numerous other
mechanisms available to accomplish that goal.
The best we can do is refuse to give the data the viewer info.
Re: using app data for this. The rules for cookies are different than
the rules for app data. For example, cookies should never be shared
across users, whereas app data is visible to other users. We should
not use app data as the cookie jar.
Re: cookie support
Posted by Fernando Padilla <fe...@alum.mit.edu>.
1) yup. these would behave as normal cookies, they would be stored for
as long as requested, etc etc.. but the proxy could always put limits on
number of cookies, size of cookies, and maybe even age of cookies.
2) yup. these would allow us to track users even before they officially
give us access to their full profile. but we still never get full
access to their identity, we get minimal anonymous tracking. Actually,
this is all through makeRequest, so I can still do full cookie-tracking
if I just have the use make requests directly to my server (except those
requests would not be signed nor authenticated ).
3) yup. most frameworks support some sort of hacked up cookie/session
through url. but those are always complicated and quite brittle (every
single url/form/link/javascript has to modify the url with the proper
current session id, else you lose the session). and these days you
can't do anything on the web without javascript and cookies turned on,
so I believe all of these old mechanisms are just slowly dieing from
non-use.
- keeping sessionId in the urls is just out of the question for reliable
applications.
- cookies are still the most expected and reliable mechanism that all
web frameworks expect to associate state with a client (track a
conversation)
Louis Ryan wrote:
> Is the goal here to have this cookie carry across multiple renders of the
> same gadget or just for requests within a single rendering of a gadget? In
> containers like Orkut where viewer data is hidden from a gadget unless
> explicit permission is granted allowing cookies to track a user across
> multiple renders of the same gadget would likely be blocked.
>
> Most frameworks allow for URL parameters to identify sessions rather than
> cookies and could easily be used in conjunction with VIEWER app data to
> achieve the same effect.
>
> On Tue, Jul 1, 2008 at 2:17 AM, Henning P. Schmiedehausen <hp...@intermeta.de>
> wrote:
>
>> "Kevin Brown" <et...@google.com> writes:
>>
>>> ------=_Part_24352_2474838.1214684004406
>>> Content-Type: text/plain; charset=ISO-8859-1
>>> Content-Transfer-Encoding: 7bit
>>> Content-Disposition: inline
>>> On Sat, Jun 28, 2008 at 12:40 PM, Fernando Padilla <fe...@alum.mit.edu>
>>> wrote:
>>>> Hello.
>>>>
>>>> I was wondering if there is any plans to have the shindig makeRequest
>>>> proxies support cookies between the proxy and the server side? Facebook
>>>> supports this, and it's quite useful to be able to use standard
>> server-side
>>>> frameworks within signed requests sent via makeRequest.
>>>>
>>> No, cookies are intentionally avoided in opensocial, because there's no
>> way
>>> to guarantee the host your gadget will render on will be the same for two
>>> renders (and, therefore, this becomes useless).
>> Let's see if I got this wrong, but I think he wants to have the http
>> fetchers (stuff implementing HttpFetcher) to support cookies so that
>> the "other side" can request setting a cookie on the HttpFetcher when
>> Shindig is proxying content in. This should be doable, however one
>> would have to juggle a number of cookie jars (probably one per
>> gadget/domain) through the ProxyHandler.
>>
>> Those cookies would never go out from the Server to the Browser. They
>> are used for Shindig <-> outside server communication. This would
>> allow the server serving the Gadget to use frameworks that e.g. want
>> to have session tracking. Or Google Analytics. ;-)
>>
>> Ciao
>> Henning
>>
>> --
>> Henning P. Schmiedehausen -- hps@intermeta.de | J2EE, Linux,
>> 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person
>> Open Source Consulting, Development, Design | Velocity - Turbine guy
>>
>> INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350
>> Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen
>>
>> "Professor Peach in the library with the lead piping!" -- Donna
>>
>
Re: cookie support
Posted by Louis Ryan <lr...@google.com>.
Is the goal here to have this cookie carry across multiple renders of the
same gadget or just for requests within a single rendering of a gadget? In
containers like Orkut where viewer data is hidden from a gadget unless
explicit permission is granted allowing cookies to track a user across
multiple renders of the same gadget would likely be blocked.
Most frameworks allow for URL parameters to identify sessions rather than
cookies and could easily be used in conjunction with VIEWER app data to
achieve the same effect.
On Tue, Jul 1, 2008 at 2:17 AM, Henning P. Schmiedehausen <hp...@intermeta.de>
wrote:
> "Kevin Brown" <et...@google.com> writes:
>
> >------=_Part_24352_2474838.1214684004406
> >Content-Type: text/plain; charset=ISO-8859-1
> >Content-Transfer-Encoding: 7bit
> >Content-Disposition: inline
>
> >On Sat, Jun 28, 2008 at 12:40 PM, Fernando Padilla <fe...@alum.mit.edu>
> >wrote:
>
> >> Hello.
> >>
> >> I was wondering if there is any plans to have the shindig makeRequest
> >> proxies support cookies between the proxy and the server side? Facebook
> >> supports this, and it's quite useful to be able to use standard
> server-side
> >> frameworks within signed requests sent via makeRequest.
> >>
>
> >No, cookies are intentionally avoided in opensocial, because there's no
> way
> >to guarantee the host your gadget will render on will be the same for two
> >renders (and, therefore, this becomes useless).
>
> Let's see if I got this wrong, but I think he wants to have the http
> fetchers (stuff implementing HttpFetcher) to support cookies so that
> the "other side" can request setting a cookie on the HttpFetcher when
> Shindig is proxying content in. This should be doable, however one
> would have to juggle a number of cookie jars (probably one per
> gadget/domain) through the ProxyHandler.
>
> Those cookies would never go out from the Server to the Browser. They
> are used for Shindig <-> outside server communication. This would
> allow the server serving the Gadget to use frameworks that e.g. want
> to have session tracking. Or Google Analytics. ;-)
>
> Ciao
> Henning
>
> --
> Henning P. Schmiedehausen -- hps@intermeta.de | J2EE, Linux,
> 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person
> Open Source Consulting, Development, Design | Velocity - Turbine guy
>
> INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350
> Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen
>
> "Professor Peach in the library with the lead piping!" -- Donna
>
RE: cookie support
Posted by "Michael Ryan (Software Developer)" <Mi...@apollogrp.edu>.
This should be fun.. :) For my applications, it doesn't matter too
much, since the gadgets, and hosted pages will be in the same domain
anyhow.. but will have to make considerations for this in
OpenCampfire... still setting up my isolated development environment for
the project.
At least I get to spend some on-the-clock time on this stuff.. :D
--
Michael J. Ryan -- Software Developer -- Apollo Group
> -----Original Message-----
> From: Brian Eaton [mailto:beaton@google.com]
> Sent: Tuesday, July 01, 2008 4:14 PM
> To: shindig-dev@incubator.apache.org
> Subject: Re: cookie support
>
> On Tue, Jul 1, 2008 at 4:09 PM, Michael Ryan (Software Developer)
> <Mi...@apollogrp.edu> wrote:
> > Hmm, I'll have to test this in a couple recent browsers, iirc you
> don't
> > see cookies you don't have access to via the dom...
>
> Check out Amit Klein's write-up:
>
> http://www.webappsec.org/lists/websecurity/archive/2006-
> 03/msg00000.html
>
> The only surefire way to separate two web sites is to host them on
> different domains. The same-origin policy doesn't offer you any other
> guarantees to work from. The Caja team is working on a javascript
> compiler that can offer additional security guarantees, so someday you
> might be able to host all your gadgets on the same domain and still
> isolate them from each other.
>
> Cheers,
> Brian
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
Re: cookie support
Posted by Brian Eaton <be...@google.com>.
On Tue, Jul 1, 2008 at 4:09 PM, Michael Ryan (Software Developer)
<Mi...@apollogrp.edu> wrote:
> Hmm, I'll have to test this in a couple recent browsers, iirc you don't
> see cookies you don't have access to via the dom...
Check out Amit Klein's write-up:
http://www.webappsec.org/lists/websecurity/archive/2006-03/msg00000.html
The only surefire way to separate two web sites is to host them on
different domains. The same-origin policy doesn't offer you any other
guarantees to work from. The Caja team is working on a javascript
compiler that can offer additional security guarantees, so someday you
might be able to host all your gadgets on the same domain and still
isolate them from each other.
Cheers,
Brian
RE: cookie support
Posted by "Michael Ryan (Software Developer)" <Mi...@apollogrp.edu>.
> -----Original Message-----
> From: Brian Eaton [mailto:beaton@google.com]
> On Tue, Jul 1, 2008 at 2:28 PM, Michael Ryan (Software Developer)
> <Mi...@apollogrp.edu> wrote:
> > It's worth noting that you can also assign cookies to a given path
as
> > well as a domain... as an alternative to a *.mygadgetserver.com with
> a
> > dns for each gadget...
>
> This does not work for security purposes. The gadgets can still
> inspect each other's DOM, which includes the cookies.
Hmm, I'll have to test this in a couple recent browsers, iirc you don't
see cookies you don't have access to via the dom...
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
Re: cookie support
Posted by Brian Eaton <be...@google.com>.
On Tue, Jul 1, 2008 at 2:28 PM, Michael Ryan (Software Developer)
<Mi...@apollogrp.edu> wrote:
> It's worth noting that you can also assign cookies to a given path as
> well as a domain... as an alternative to a *.mygadgetserver.com with a
> dns for each gadget...
This does not work for security purposes. The gadgets can still
inspect each other's DOM, which includes the cookies.
RE: cookie support
Posted by "Michael Ryan (Software Developer)" <Mi...@apollogrp.edu>.
Comments inline...
--
Michael J. Ryan -- Software Developer -- Apollo Group
> -----Original Message-----
> From: Brian Eaton [mailto:beaton@google.com]
> Subject: Re: cookie support
>
> > to set a cookie from gadgetprovider.com) or it will be available to
> > all gadgets that come from renderer.mydomain.com. Or am I wrong?
>
> No, you're right. If you are putting important information in
> gadgets, you need to keep them separate from each other by using the
> locked-domain feature. This forces the gadgets to render on their own
> DNS domains.
>
> Re: the browser cookie domain checks: we'd completely bypass those.
> The gadget would get a response from the proxy server that included,
> in JSON, the cookies sent with the response. The cookies would be
> parsed and managed entirely in javascript.
It's worth noting that you can also assign cookies to a given path as
well as a domain... as an alternative to a *.mygadgetserver.com with a
dns for each gadget...
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
Re: cookie support
Posted by Brian Eaton <be...@google.com>.
On Tue, Jul 1, 2008 at 1:43 PM, Henning P. Schmiedehausen
<hp...@intermeta.de> wrote:
> Wouldn't that allow one gadget to steal cookies from another one? All
> our gadgets are rendered from a central render instance, no matter
> from where the content came. If I pass a backend cookie to the
> browser, it will either reject it (because renderer.mydomain.com wants
> to set a cookie from gadgetprovider.com) or it will be available to
> all gadgets that come from renderer.mydomain.com. Or am I wrong?
No, you're right. If you are putting important information in
gadgets, you need to keep them separate from each other by using the
locked-domain feature. This forces the gadgets to render on their own
DNS domains.
Re: the browser cookie domain checks: we'd completely bypass those.
The gadget would get a response from the proxy server that included,
in JSON, the cookies sent with the response. The cookies would be
parsed and managed entirely in javascript.
Re: cookie support
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Brian Eaton" <be...@google.com> writes:
>On Tue, Jul 1, 2008 at 2:17 AM, Henning P. Schmiedehausen
><hp...@intermeta.de> wrote:
>> Those cookies would never go out from the Server to the Browser. They
>> are used for Shindig <-> outside server communication.
>Why not send them to the browser? You wouldn't send them as
>set-cookie headers, since the browser cookie jar will misunderstand,
>but you could return them as additional attributes in the response to
>makeRequest and let the javascript code cache/manage them.
Wouldn't that allow one gadget to steal cookies from another one? All
our gadgets are rendered from a central render instance, no matter
from where the content came. If I pass a backend cookie to the
browser, it will either reject it (because renderer.mydomain.com wants
to set a cookie from gadgetprovider.com) or it will be available to
all gadgets that come from renderer.mydomain.com. Or am I wrong?
Ciao
Henning
--
Henning P. Schmiedehausen -- hps@intermeta.de | J2EE, Linux,
91054 Buckenhof, Germany -- +49 9131 506540 | Apache person
Open Source Consulting, Development, Design | Velocity - Turbine guy
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350
Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen
"Professor Peach in the library with the lead piping!" -- Donna
Re: cookie support
Posted by Brian Eaton <be...@google.com>.
On Tue, Jul 1, 2008 at 2:17 AM, Henning P. Schmiedehausen
<hp...@intermeta.de> wrote:
> Those cookies would never go out from the Server to the Browser. They
> are used for Shindig <-> outside server communication.
Why not send them to the browser? You wouldn't send them as
set-cookie headers, since the browser cookie jar will misunderstand,
but you could return them as additional attributes in the response to
makeRequest and let the javascript code cache/manage them.
Re: cookie support
Posted by Fernando Padilla <fe...@alum.mit.edu>.
yes. I'm a little confused as to what yo umean by "cookie jar". :)
But yes. I was proposing the shindig proxies to host cookies for the
back-end server. You could even use the application data module to
store this information (associated to application and user). So that
you don't have to create a new data storage system, and developers could
even go into the app-data through rest or javascript and read/modify the
cookies directly if need be. (maybe with a special prefix to tell the
proxies which ones are 'cookies').
Henning P. Schmiedehausen wrote:
> "Kevin Brown" <et...@google.com> writes:
>
>> ------=_Part_24352_2474838.1214684004406
>> Content-Type: text/plain; charset=ISO-8859-1
>> Content-Transfer-Encoding: 7bit
>> Content-Disposition: inline
>
>> On Sat, Jun 28, 2008 at 12:40 PM, Fernando Padilla <fe...@alum.mit.edu>
>> wrote:
>
>>> Hello.
>>>
>>> I was wondering if there is any plans to have the shindig makeRequest
>>> proxies support cookies between the proxy and the server side? Facebook
>>> supports this, and it's quite useful to be able to use standard server-side
>>> frameworks within signed requests sent via makeRequest.
>>>
>
>> No, cookies are intentionally avoided in opensocial, because there's no way
>> to guarantee the host your gadget will render on will be the same for two
>> renders (and, therefore, this becomes useless).
>
> Let's see if I got this wrong, but I think he wants to have the http
> fetchers (stuff implementing HttpFetcher) to support cookies so that
> the "other side" can request setting a cookie on the HttpFetcher when
> Shindig is proxying content in. This should be doable, however one
> would have to juggle a number of cookie jars (probably one per
> gadget/domain) through the ProxyHandler.
>
> Those cookies would never go out from the Server to the Browser. They
> are used for Shindig <-> outside server communication. This would
> allow the server serving the Gadget to use frameworks that e.g. want
> to have session tracking. Or Google Analytics. ;-)
>
> Ciao
> Henning
>
Re: cookie support
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Kevin Brown" <et...@google.com> writes:
>------=_Part_24352_2474838.1214684004406
>Content-Type: text/plain; charset=ISO-8859-1
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline
>On Sat, Jun 28, 2008 at 12:40 PM, Fernando Padilla <fe...@alum.mit.edu>
>wrote:
>> Hello.
>>
>> I was wondering if there is any plans to have the shindig makeRequest
>> proxies support cookies between the proxy and the server side? Facebook
>> supports this, and it's quite useful to be able to use standard server-side
>> frameworks within signed requests sent via makeRequest.
>>
>No, cookies are intentionally avoided in opensocial, because there's no way
>to guarantee the host your gadget will render on will be the same for two
>renders (and, therefore, this becomes useless).
Let's see if I got this wrong, but I think he wants to have the http
fetchers (stuff implementing HttpFetcher) to support cookies so that
the "other side" can request setting a cookie on the HttpFetcher when
Shindig is proxying content in. This should be doable, however one
would have to juggle a number of cookie jars (probably one per
gadget/domain) through the ProxyHandler.
Those cookies would never go out from the Server to the Browser. They
are used for Shindig <-> outside server communication. This would
allow the server serving the Gadget to use frameworks that e.g. want
to have session tracking. Or Google Analytics. ;-)
Ciao
Henning
--
Henning P. Schmiedehausen -- hps@intermeta.de | J2EE, Linux,
91054 Buckenhof, Germany -- +49 9131 506540 | Apache person
Open Source Consulting, Development, Design | Velocity - Turbine guy
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350
Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen
"Professor Peach in the library with the lead piping!" -- Donna
Re: cookie support
Posted by Kevin Brown <et...@google.com>.
On Sat, Jun 28, 2008 at 12:40 PM, Fernando Padilla <fe...@alum.mit.edu>
wrote:
> Hello.
>
> I was wondering if there is any plans to have the shindig makeRequest
> proxies support cookies between the proxy and the server side? Facebook
> supports this, and it's quite useful to be able to use standard server-side
> frameworks within signed requests sent via makeRequest.
>
No, cookies are intentionally avoided in opensocial, because there's no way
to guarantee the host your gadget will render on will be the same for two
renders (and, therefore, this becomes useless).
Every gadget has to be rendered on a unique subdomain to prevent
cross-gadget scripting.
You might be able to get away with using just session cookies, but it would
be very hard to rely on it unless it's standardized throughout opensocial,
which creates just another area where code has to be forked.