Re: Using W3C widgets in a web container: two implementations contrasted

On Sat, Jan 17, 2009 at 8:02 PM, Scott Wilson
<scott.bradley.wilson@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

Received on Friday, 23 January 2009 10:29:42 UTC