On Sat, Jan 17, 2009 at 8:02 PM, Scott Wilson
scott.bradley.wil...@gmail.com wrote:
Hi Marcos,
The engine/platform has to provide a means for a widget to access
externally-offered web services without breaking the same origin policy of
the browser. To do this both projects have implemented a server-side proxy
that routes requests from the widget via the widget engine, so that widgets
only make requests within the same domain from which they are served.
Ok, makes sense.
In the case of Wookie, the Widget object has a proxify(url) method that just
returns a rewritten URL formatted for a server-side whitelisting proxy; the
widget JS implementation can then invoke XMLHttpRequest (or use an AJAX
library such as Prototype) - with the value of the proxified URL instead
of using the original URL, which would most likely be blocked by the browser
as a x-site scripting violation.
Also makes sense.
E.g. if the original URL was http://www.elsewhere.com/service/; then the
result of proxify(http://www.elsewhere.com/service;) might be
https://www.here.com/wookie/services/proxy?url=http%3A%2F%2Fwww.elsewhere.com%2Fservice%2F;
In the case of Palette, the project created wrappers methods in the Widget
object for the various remote access methods (get, post, getJSON, put,
delete) that rewrites the request to point via its proxy endpoint.
The net result is the same, but the question is which is the better approach
in terms of API design? We designed an approach to give widget developers
flexibility wrt libraries and tools for handling requests; Palette's design
goal was for making development of widgets simpler.
Ok, I guess the thing the working group needs to take away from this
is how do we deal with widgets not having an origin. This might not be
too much of an issue so long as the author declares which domains they
want to communicate with. That way, the widget engine can allow access
to the desired domains without requiring a server-side proxy as an
intermediary.
Given your implementation experience, if you have any suggestion on
how you think we should proceed we would certainly like to hear them.
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
