>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) [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.
