You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Jordan Zimmerman <jo...@shop.com> on 2009/02/26 22:10:48 UTC
makeRequest and cookies
Is it planned that makeRequest will eventually proxy cookies? Currently,
it doesn't. It would be easy to add to Shindig but if it's not part of
the spec gadgets can't count on it.
Jordan Zimmerman
Principal Software Architect
831.647.4712
831.214.2990 (cell)
jordanz@shop.com
SHOP*COMTM
Shop Smart, Save Big(tm)
www.shop.com
This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this
message
immediately if this is an electronic communication.
Thank you.
RE: makeRequest and cookies
Posted by Jordan Zimmerman <jo...@shop.com>.
>Sounds like you are proposing a javascript library that implements
>browser cookie rules on top of makeRequest.
>
>I'd be fine with that, in principle. In practice It's hard to mimic
>the cookie jar precisely, some of the rules are subtle.
Very true! So, time for me to get on-board with your proposal which
gives enough functionality for gadgets to get the behavior they need.
Jordan Zimmerman
Principal Software Architect
831.647.4712
831.214.2990 (cell)
jordanz@shop.com
SHOP*COMTM
Shop Smart, Save Big(tm)
www.shop.com
This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this
message
immediately if this is an electronic communication.
Thank you.
Re: makeRequest and cookies
Posted by Brian Eaton <be...@google.com>.
On Thu, Feb 26, 2009 at 3:00 PM, Jordan Zimmerman <jo...@shop.com> wrote:
> However, I don't see any problems with the gadget setting/getting
> cookies from its remote server. It's implicit in the spec anyway
> (especially if your proposal were to be accepted
> http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread
> /thread/51b016b80e9d21e6?pli=1). Why not make this easier on gadgets?
Sounds like you are proposing a javascript library that implements
browser cookie rules on top of makeRequest.
I'd be fine with that, in principle. In practice It's hard to mimic
the cookie jar precisely, some of the rules are subtle. Quick! What
should happen if foo.example.com and bar.example.com set two cookies
like this?
foo.example.com: name=v1; path=/bar; domain=.example.com
bar.example.com: name=v2; path=/bar/some; domain=.example.com
Rather than worry about that question, I think we should get
makeRequest to expose the cookies, then let other people build
libraries on top of that functionality.
Cheers,
Brian
RE: makeRequest and cookies
Posted by Jordan Zimmerman <jo...@shop.com>.
>> As I just wrote out that scenario, I can see a potential security
hole.
>> The remote server would be get all cookies set in the container.
>
>That's not a potential hole. That's game over.
I agree. Writing out the scenario makes it plain.
However, I don't see any problems with the gadget setting/getting
cookies from its remote server. It's implicit in the spec anyway
(especially if your proposal were to be accepted
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread
/thread/51b016b80e9d21e6?pli=1). Why not make this easier on gadgets?
BTW - should I move this discussion to the OS spec board?
Here's a revised proposal:
* MyGadget is running in container www.oscontainer.com
* MyGadget makes a makeRequest call to "http://www.shop.com/whatever"
* The container, when processing the call, checks for an internal cache
of cookies set for the gadget. If found, they're included as a "Cookie"
request header.
* When the container processes the response, any "Set-Cookie" response
headers are added to the gadgets cache.
With your idea of including HTTP response headers, this would all be
possible to do manually in the gadget anyway.
Jordan Zimmerman
Principal Software Architect
831.647.4712
831.214.2990 (cell)
jordanz@shop.com
SHOP*COMTM
Shop Smart, Save Big(tm)
www.shop.com
This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this
message
immediately if this is an electronic communication.
Thank you.
Re: makeRequest and cookies
Posted by Brian Eaton <be...@google.com>.
On Thu, Feb 26, 2009 at 2:44 PM, Jordan Zimmerman <jo...@shop.com> wrote:
> As I just wrote out that scenario, I can see a potential security hole.
> The remote server would be get all cookies set in the container.
That's not a potential hole. That's game over.
> But,
> then, this hole exists anyway as the gadget could get all cookies using
> plain JS and send it in the makeRequest as a POST or whatever.
No, it can't. Production opensocial containers run gadgets on cookie
isolation domains for just this reason.
For security purposes type=html gadgets are nothing but web
applications that happen to be passed through a proxy. They don't get
to mess with the container except in limited ways.
Re: makeRequest and cookies
Posted by John Hjelmstad <fa...@google.com>.
On Thu, Feb 26, 2009 at 2:44 PM, Jordan Zimmerman <jo...@shop.com> wrote:
> >To be clear, by browser-passed and "proxy" you mean that makeRequest
> become
> >a mechanism for setting cookies (and sending) on the domain on which a
> >gadget is rendered?
> The terminology is unclear to me. So, instead, here's a scenario:
Your scenario matches what I was describing. The "domain on which a gadget
is rendered" => "Opensocial compatible container" in your scenario.
>
>
> a) MyGadget is running an OpenSocial compatible container:
> www.oscontainer.com
> b) MyGadget calls makeRequest() to the URL
> "http://www.shop.com/whatever"
> c) When the container is processing the makeRequest() call, it includes
> cookies set at "www.oscontainer.com" as a standard "Cookie" request
> header in the call to "http://www.shop.com/whatever".
> d) When the container is sending the response back to the gadget, it
> includes any new cookies (i.e. "Set-Cookie" response header) as a
> Set-Cookie response to the container.
>
> As I just wrote out that scenario, I can see a potential security hole.
> The remote server would be get all cookies set in the container. But,
> then, this hole exists anyway as the gadget could get all cookies using
> plain JS and send it in the makeRequest as a POST or whatever.
That's true; that's one of a few reasons that locked-domain exists. In
addition to cookie-sharing, gadgets rendered on the same domain (eg
www.oscontainer.com) can read each other's entire DOMs through window.frames
traversal in the browser.
<just got the note from Brian echoing the same>
As aforementioned, I might be open to supporting cookie-like functionality
so long as storage isn't tied to the domain/oscontainer.
It seems like your main concern is server-side session creation and the
waste associated with it. But, AFAIK, there's no real standard for that, so
I'm not sure how you'd represent this in a standardized spec unless you
specified that *all* makeRequest calls proxy cookies to and from this
separate store, which it seems to me is overkill.
Going with your original example of a gadget that makes a call to the
endpoint server (with which it presumably has a close enough relationship to
care about its performance :)) that creates sessions per-request in lieu of
a cookie... it seems to me that as long as makeRequest doesn't filter out a
header with the name "Cookie", nor response header with the name
"Set-Cookie", the gadget can store the session token itself (as a userPref,
in AppData, or whatever), to optimize its own server.
--John
>
>
> Jordan Zimmerman
> Principal Software Architect
> 831.647.4712
> 831.214.2990 (cell)
> jordanz@shop.com
>
> SHOP*COMTM
> Shop Smart, Save Big(tm)
> www.shop.com
>
> This message (including any attachments) is intended only for
> the use of the individual or entity to which it is addressed and
> may contain information that is non-public, proprietary,
> privileged, confidential, and exempt from disclosure under
> applicable law or may constitute as attorney work product.
> If you are not the intended recipient, you are hereby notified
> that any use, dissemination, distribution, or copying of this
> communication is strictly prohibited. If you have received this
> communication in error, notify us immediately by telephone and
> (i) destroy this message if a facsimile or (ii) delete this
> message
> immediately if this is an electronic communication.
>
> Thank you.
>
RE: makeRequest and cookies
Posted by Jordan Zimmerman <jo...@shop.com>.
>To be clear, by browser-passed and "proxy" you mean that makeRequest
become
>a mechanism for setting cookies (and sending) on the domain on which a
>gadget is rendered?
The terminology is unclear to me. So, instead, here's a scenario:
a) MyGadget is running an OpenSocial compatible container:
www.oscontainer.com
b) MyGadget calls makeRequest() to the URL
"http://www.shop.com/whatever"
c) When the container is processing the makeRequest() call, it includes
cookies set at "www.oscontainer.com" as a standard "Cookie" request
header in the call to "http://www.shop.com/whatever".
d) When the container is sending the response back to the gadget, it
includes any new cookies (i.e. "Set-Cookie" response header) as a
Set-Cookie response to the container.
As I just wrote out that scenario, I can see a potential security hole.
The remote server would be get all cookies set in the container. But,
then, this hole exists anyway as the gadget could get all cookies using
plain JS and send it in the makeRequest as a POST or whatever.
Jordan Zimmerman
Principal Software Architect
831.647.4712
831.214.2990 (cell)
jordanz@shop.com
SHOP*COMTM
Shop Smart, Save Big(tm)
www.shop.com
This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this
message
immediately if this is an electronic communication.
Thank you.
Re: makeRequest and cookies
Posted by John Hjelmstad <fa...@google.com>.
To be clear, I'm opposed to using the browser's cookie jar and, by
extension, the rendering domain scheme to store cookies. With another
storage mechanism defined, I'm open to discussion.
--John
On Thu, Feb 26, 2009 at 2:36 PM, John Hjelmstad <fa...@google.com> wrote:
> To be clear, by browser-passed and "proxy" you mean that makeRequest become
> a mechanism for setting cookies (and sending) on the domain on which a
> gadget is rendered?
> --John
>
> On Thu, Feb 26, 2009 at 2:28 PM, Jordan Zimmerman <jo...@shop.com>wrote:
>
>> >Subscribe to the opensocial-and-gadgets-spec and read through some of
>> >the archives for OpenSocial 0.9 spec proposals:
>> >http://groups.google.com/group/opensocial-and-gadgets-spec.
>> Thanks. Unless you object, I'd like to propose something different -
>> that makeRequest proxy cookies. It would be straightforward. The
>> container includes any browser-passed cookies to the target URL and the
>> container returns any set-cookie headers in the response back to the
>> browser.
>>
>> Jordan Zimmerman
>> Principal Software Architect
>> 831.647.4712
>> 831.214.2990 (cell)
>> jordanz@shop.com
>>
>> SHOP*COMTM
>> Shop Smart, Save Big(tm)
>> www.shop.com
>>
>> This message (including any attachments) is intended only for
>> the use of the individual or entity to which it is addressed and
>> may contain information that is non-public, proprietary,
>> privileged, confidential, and exempt from disclosure under
>> applicable law or may constitute as attorney work product.
>> If you are not the intended recipient, you are hereby notified
>> that any use, dissemination, distribution, or copying of this
>> communication is strictly prohibited. If you have received this
>> communication in error, notify us immediately by telephone and
>> (i) destroy this message if a facsimile or (ii) delete this
>> message
>> immediately if this is an electronic communication.
>>
>> Thank you.
>>
>
>
Re: makeRequest and cookies
Posted by John Hjelmstad <fa...@google.com>.
To be clear, by browser-passed and "proxy" you mean that makeRequest become
a mechanism for setting cookies (and sending) on the domain on which a
gadget is rendered?
--John
On Thu, Feb 26, 2009 at 2:28 PM, Jordan Zimmerman <jo...@shop.com> wrote:
> >Subscribe to the opensocial-and-gadgets-spec and read through some of
> >the archives for OpenSocial 0.9 spec proposals:
> >http://groups.google.com/group/opensocial-and-gadgets-spec.
> Thanks. Unless you object, I'd like to propose something different -
> that makeRequest proxy cookies. It would be straightforward. The
> container includes any browser-passed cookies to the target URL and the
> container returns any set-cookie headers in the response back to the
> browser.
>
> Jordan Zimmerman
> Principal Software Architect
> 831.647.4712
> 831.214.2990 (cell)
> jordanz@shop.com
>
> SHOP*COMTM
> Shop Smart, Save Big(tm)
> www.shop.com
>
> This message (including any attachments) is intended only for
> the use of the individual or entity to which it is addressed and
> may contain information that is non-public, proprietary,
> privileged, confidential, and exempt from disclosure under
> applicable law or may constitute as attorney work product.
> If you are not the intended recipient, you are hereby notified
> that any use, dissemination, distribution, or copying of this
> communication is strictly prohibited. If you have received this
> communication in error, notify us immediately by telephone and
> (i) destroy this message if a facsimile or (ii) delete this
> message
> immediately if this is an electronic communication.
>
> Thank you.
>
Re: makeRequest and cookies
Posted by Brian Eaton <be...@google.com>.
On Thu, Feb 26, 2009 at 2:28 PM, Jordan Zimmerman <jo...@shop.com> wrote:
>>Subscribe to the opensocial-and-gadgets-spec and read through some of
>>the archives for OpenSocial 0.9 spec proposals:
>>http://groups.google.com/group/opensocial-and-gadgets-spec.
> Thanks. Unless you object, I'd like to propose something different -
> that makeRequest proxy cookies. It would be straightforward. The
> container includes any browser-passed cookies to the target URL and the
> container returns any set-cookie headers in the response back to the
> browser.
I have objections. The browser cookie jar should not be used in
gadgets because it has *no idea* where the actual request is going.
RE: makeRequest and cookies
Posted by Jordan Zimmerman <jo...@shop.com>.
>Subscribe to the opensocial-and-gadgets-spec and read through some of
>the archives for OpenSocial 0.9 spec proposals:
>http://groups.google.com/group/opensocial-and-gadgets-spec.
Thanks. Unless you object, I'd like to propose something different -
that makeRequest proxy cookies. It would be straightforward. The
container includes any browser-passed cookies to the target URL and the
container returns any set-cookie headers in the response back to the
browser.
Jordan Zimmerman
Principal Software Architect
831.647.4712
831.214.2990 (cell)
jordanz@shop.com
SHOP*COMTM
Shop Smart, Save Big(tm)
www.shop.com
This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this
message
immediately if this is an electronic communication.
Thank you.
RE: makeRequest and cookies
Posted by Jordan Zimmerman <jo...@shop.com>.
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread
/thread/7ef764a779257c48#
Jordan Zimmerman
Principal Software Architect
831.647.4712
831.214.2990 (cell)
jordanz@shop.com
SHOP*COMTM
Shop Smart, Save Big(tm)
www.shop.com
This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this
message
immediately if this is an electronic communication.
Thank you.
Re: makeRequest and cookies
Posted by Brian Eaton <be...@google.com>.
Ah, you're looking for the definition of the "normal" non-OAuth fields.
Yes. Someone should write those down. Check out
MakeRequestHandler.java in Shindig for the reference implementation.
(I'm amazed developers aren't complaining.)
On Thu, Feb 26, 2009 at 6:19 PM, Jordan Zimmerman <jo...@shop.com> wrote:
>>http://www.opensocial.org/Technical-Resources/opensocial-spec-v08/gadge
> ts->reference08#gadgets.io.makeRequest
>>
>>http://code.google.com/apis/gadgets/docs/oauth.html#makeRequest
> The schema for the response is never defined. There is example code, but
> that's it.
>
> Jordan Zimmerman
> Principal Software Architect
> 831.647.4712
> 831.214.2990 (cell)
> jordanz@shop.com
>
> SHOP*COMTM
> Shop Smart, Save Big(tm)
> www.shop.com
>
> This message (including any attachments) is intended only for
> the use of the individual or entity to which it is addressed and
> may contain information that is non-public, proprietary,
> privileged, confidential, and exempt from disclosure under
> applicable law or may constitute as attorney work product.
> If you are not the intended recipient, you are hereby notified
> that any use, dissemination, distribution, or copying of this
> communication is strictly prohibited. If you have received this
> communication in error, notify us immediately by telephone and
> (i) destroy this message if a facsimile or (ii) delete this
> message
> immediately if this is an electronic communication.
>
> Thank you.
>
RE: makeRequest and cookies
Posted by Jordan Zimmerman <jo...@shop.com>.
>http://www.opensocial.org/Technical-Resources/opensocial-spec-v08/gadge
ts->reference08#gadgets.io.makeRequest
>
>http://code.google.com/apis/gadgets/docs/oauth.html#makeRequest
The schema for the response is never defined. There is example code, but
that's it.
Jordan Zimmerman
Principal Software Architect
831.647.4712
831.214.2990 (cell)
jordanz@shop.com
SHOP*COMTM
Shop Smart, Save Big(tm)
www.shop.com
This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this
message
immediately if this is an electronic communication.
Thank you.
Re: makeRequest and cookies
Posted by Brian Eaton <be...@google.com>.
http://www.opensocial.org/Technical-Resources/opensocial-spec-v08/gadgets-reference08#gadgets.io.makeRequest
http://code.google.com/apis/gadgets/docs/oauth.html#makeRequest
On Thu, Feb 26, 2009 at 6:07 PM, Jordan Zimmerman <jo...@shop.com> wrote:
>>Then write one up for opensocial .NEXT, and get consensus on how
>>things should look.
> Anyone have any idea where in the spec the makeRequest() response object
> is defined? The only reference I can find is here:
> http://sites.google.com/site/opensocialdraft/Home/gadgets-api-specificat
> ion/gadgets-io and all it says is "The makeRequest() callback parameter
> is passed a javascript object with several OAuth-specific fields in
> addition to the normal values returned."
>
> Jordan Zimmerman
> Principal Software Architect
> 831.647.4712
> 831.214.2990 (cell)
> jordanz@shop.com
>
> SHOP*COMTM
> Shop Smart, Save Big(tm)
> www.shop.com
>
> This message (including any attachments) is intended only for
> the use of the individual or entity to which it is addressed and
> may contain information that is non-public, proprietary,
> privileged, confidential, and exempt from disclosure under
> applicable law or may constitute as attorney work product.
> If you are not the intended recipient, you are hereby notified
> that any use, dissemination, distribution, or copying of this
> communication is strictly prohibited. If you have received this
> communication in error, notify us immediately by telephone and
> (i) destroy this message if a facsimile or (ii) delete this
> message
> immediately if this is an electronic communication.
>
> Thank you.
>
RE: makeRequest and cookies
Posted by Jordan Zimmerman <jo...@shop.com>.
>Then write one up for opensocial .NEXT, and get consensus on how
>things should look.
Anyone have any idea where in the spec the makeRequest() response object
is defined? The only reference I can find is here:
http://sites.google.com/site/opensocialdraft/Home/gadgets-api-specificat
ion/gadgets-io and all it says is "The makeRequest() callback parameter
is passed a javascript object with several OAuth-specific fields in
addition to the normal values returned."
Jordan Zimmerman
Principal Software Architect
831.647.4712
831.214.2990 (cell)
jordanz@shop.com
SHOP*COMTM
Shop Smart, Save Big(tm)
www.shop.com
This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this
message
immediately if this is an electronic communication.
Thank you.
Re: makeRequest and cookies
Posted by Brian Eaton <be...@google.com>.
On Thu, Feb 26, 2009 at 1:51 PM, Jordan Zimmerman <jo...@shop.com> wrote:
>>Jordan, if you believe this is the right approach would you be willing
>>to drive it through the opensocial spec process?
> I'd be very interested! What do I need to do?
Subscribe to the opensocial-and-gadgets-spec and read through some of
the archives for OpenSocial 0.9 spec proposals:
http://groups.google.com/group/opensocial-and-gadgets-spec.
Then write one up for opensocial .NEXT, and get consensus on how
things should look.
Then implement a prototype.
Then call it done.
Well, that's how I think it works. There is some better documentation
on the process in some mail threads in that group. The most important
parts are building consensus and getting a prototype done.
Cheers,
Brian
RE: makeRequest and cookies
Posted by Jordan Zimmerman <jo...@shop.com>.
My view is that the container is acting as proxy for the request and
proxies generally retain cookies. Not setting cookies has two potential
problems. 1) Most servers allocate some kind of internal session for
requests, so each makeRequest will end up allocating a new session which
is wasteful. 2) Gadgets may want to make a sequence of makeRequest calls
and having a session would make this far easier.
Of course, you could do it with URL parameters, but that's a pain and is
why cookie-based sessions were developed to begin with.
>Jordan, if you believe this is the right approach would you be willing
>to drive it through the opensocial spec process?
I'd be very interested! What do I need to do?
Jordan Zimmerman
Principal Software Architect
831.647.4712
831.214.2990 (cell)
jordanz@shop.com
SHOP*COMTM
Shop Smart, Save Big(tm)
www.shop.com
This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this
message
immediately if this is an electronic communication.
Thank you.
Re: makeRequest and cookies
Posted by John Hjelmstad <fa...@google.com>.
Good point. I'm OK with explicitly-passed cookies, just not using them
implicitly during rendering.
--John
On Thu, Feb 26, 2009 at 1:24 PM, Brian Eaton <be...@google.com> wrote:
> I sort of agree with John on this, but I'm not quite as much of a
> cookie-hater as he is. Cookies in the browser cookie jar don't make
> sense for gadgets. Cookies with gadgets.io.makeRequest, though, can
> be useful. It has come in handy for integration of gadgets with
> third-party web services that require cookies.
>
> I put together a spec proposal on this, and it is implemented in
> Shindig. It's not a formal part of the opensocial spec, yet.
>
>
> http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/51b016b80e9d21e6?pli=1
>
> Jordan, if you believe this is the right approach would you be willing
> to drive it through the opensocial spec process?
>
> Cheers,
> Brian
>
> On Thu, Feb 26, 2009 at 1:15 PM, John Hjelmstad <fa...@google.com> wrote:
> > No -- gadgets run on a jail domain for the obvious security reasons,
> which
> > is not stable from the perspective of the gadget developer (even a locked
> > domain algorithm may change) and which may be shared by other gadgets
> (more
> > security issues). As such, cookies don't make sense for gadgets, so
> proxying
> > them would just add confusion.
> > --John
> >
> > On Thu, Feb 26, 2009 at 1:10 PM, Jordan Zimmerman <jo...@shop.com>
> wrote:
> >
> >> Is it planned that makeRequest will eventually proxy cookies? Currently,
> >> it doesn't. It would be easy to add to Shindig but if it's not part of
> >> the spec gadgets can't count on it.
> >>
> >> Jordan Zimmerman
> >> Principal Software Architect
> >> 831.647.4712
> >> 831.214.2990 (cell)
> >> jordanz@shop.com
> >>
> >> SHOP*COMTM
> >> Shop Smart, Save Big(tm)
> >> www.shop.com
> >>
> >> This message (including any attachments) is intended only for
> >> the use of the individual or entity to which it is addressed and
> >> may contain information that is non-public, proprietary,
> >> privileged, confidential, and exempt from disclosure under
> >> applicable law or may constitute as attorney work product.
> >> If you are not the intended recipient, you are hereby notified
> >> that any use, dissemination, distribution, or copying of this
> >> communication is strictly prohibited. If you have received this
> >> communication in error, notify us immediately by telephone and
> >> (i) destroy this message if a facsimile or (ii) delete this
> >> message
> >> immediately if this is an electronic communication.
> >>
> >> Thank you.
> >>
> >
>
Re: makeRequest and cookies
Posted by Brian Eaton <be...@google.com>.
I sort of agree with John on this, but I'm not quite as much of a
cookie-hater as he is. Cookies in the browser cookie jar don't make
sense for gadgets. Cookies with gadgets.io.makeRequest, though, can
be useful. It has come in handy for integration of gadgets with
third-party web services that require cookies.
I put together a spec proposal on this, and it is implemented in
Shindig. It's not a formal part of the opensocial spec, yet.
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/51b016b80e9d21e6?pli=1
Jordan, if you believe this is the right approach would you be willing
to drive it through the opensocial spec process?
Cheers,
Brian
On Thu, Feb 26, 2009 at 1:15 PM, John Hjelmstad <fa...@google.com> wrote:
> No -- gadgets run on a jail domain for the obvious security reasons, which
> is not stable from the perspective of the gadget developer (even a locked
> domain algorithm may change) and which may be shared by other gadgets (more
> security issues). As such, cookies don't make sense for gadgets, so proxying
> them would just add confusion.
> --John
>
> On Thu, Feb 26, 2009 at 1:10 PM, Jordan Zimmerman <jo...@shop.com> wrote:
>
>> Is it planned that makeRequest will eventually proxy cookies? Currently,
>> it doesn't. It would be easy to add to Shindig but if it's not part of
>> the spec gadgets can't count on it.
>>
>> Jordan Zimmerman
>> Principal Software Architect
>> 831.647.4712
>> 831.214.2990 (cell)
>> jordanz@shop.com
>>
>> SHOP*COMTM
>> Shop Smart, Save Big(tm)
>> www.shop.com
>>
>> This message (including any attachments) is intended only for
>> the use of the individual or entity to which it is addressed and
>> may contain information that is non-public, proprietary,
>> privileged, confidential, and exempt from disclosure under
>> applicable law or may constitute as attorney work product.
>> If you are not the intended recipient, you are hereby notified
>> that any use, dissemination, distribution, or copying of this
>> communication is strictly prohibited. If you have received this
>> communication in error, notify us immediately by telephone and
>> (i) destroy this message if a facsimile or (ii) delete this
>> message
>> immediately if this is an electronic communication.
>>
>> Thank you.
>>
>
Re: makeRequest and cookies
Posted by John Hjelmstad <fa...@google.com>.
No -- gadgets run on a jail domain for the obvious security reasons, which
is not stable from the perspective of the gadget developer (even a locked
domain algorithm may change) and which may be shared by other gadgets (more
security issues). As such, cookies don't make sense for gadgets, so proxying
them would just add confusion.
--John
On Thu, Feb 26, 2009 at 1:10 PM, Jordan Zimmerman <jo...@shop.com> wrote:
> Is it planned that makeRequest will eventually proxy cookies? Currently,
> it doesn't. It would be easy to add to Shindig but if it's not part of
> the spec gadgets can't count on it.
>
> Jordan Zimmerman
> Principal Software Architect
> 831.647.4712
> 831.214.2990 (cell)
> jordanz@shop.com
>
> SHOP*COMTM
> Shop Smart, Save Big(tm)
> www.shop.com
>
> This message (including any attachments) is intended only for
> the use of the individual or entity to which it is addressed and
> may contain information that is non-public, proprietary,
> privileged, confidential, and exempt from disclosure under
> applicable law or may constitute as attorney work product.
> If you are not the intended recipient, you are hereby notified
> that any use, dissemination, distribution, or copying of this
> communication is strictly prohibited. If you have received this
> communication in error, notify us immediately by telephone and
> (i) destroy this message if a facsimile or (ii) delete this
> message
> immediately if this is an electronic communication.
>
> Thank you.
>