- From: Arve Bersvendsen <arveb@opera.com>
- Date: Mon, 26 Feb 2007 10:52:55 +0100
- To: "Marcos Caceres" <m.caceres@qut.edu.au>, "Stephen Paul Weber" <singpolyma@gmail.com>
- Cc: public-appformats@w3.org
On Sat, 24 Feb 2007 11:25:07 +0100, Marcos Caceres <m.caceres@qut.edu.au> wrote: [Cross-domain XMLHttpRequest] >> Perhaps some sort of note could be made that there >> SHOULD (if rendering in a webpage) be a variable in the JavaScript >> (defined by the rendering system, ie, parent page) that contains a URL >> to a proxy script (ie, http://example.com/proxy/?url=) and that if >> this is present the widget code SHOULD access using this proxy. If >> using a desktop rendering system (ala Google Desktop) there SHOULD NOT >> be such a variable. If there is no such variable the widget code >> SHOULD access resources directly. >> > > Sorry, this solution sounds a bit hackish to me. There are better ways > to do off-line persistent storage. I also don't see how it addresses > the XMLHttpRequest security issues Arve mentioned. > > Arve, I guess in regards to XMLHttpRequest security issue, the browser > security model still applies. For widgets rendered in a web page, the browser security model would still have to apply, since the user would normally not be given a choice whether to allow cross-domain access or not. As for widgets and XMLHttpRequest in typical web desktop setups, the right choice would be for the author of the web desktop to change the XMLHttpRequest.open() prototype before injecting the document so that it rewrites the URL to use the proxy, NOT to invent some magic attribute prone to failure. -- Arve Bersvendsen, Web Applications Developer Opera Software ASA, http://www.opera.com/
Received on Monday, 26 February 2007 09:53:11 UTC