On Thu, Feb 26, 2009 at 2:44 PM, Jordan Zimmerman <[email protected]> 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) > [email protected] > > 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. >
