On Sat, 24 Feb 2007 11:25:07 +0100, Marcos Caceres <[EMAIL PROTECTED]>
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/
