Re: [Workers] Worker same-origin and usage in JS libraries...

On Tue, Dec 6, 2011 at 5:05 PM, Travis Leithead
<travis.leithead@microsoft.com> wrote:
> A new scenario just came to my attention that I thought I might
> pose to the list. Given the current same-origin restrictions on
> new Worker(), it is problematic for Worker usage by any JS
> libraries on a CDN.
>
> A site using a CDN simply provides an absolute URL reference to
> the library, and it is subsequently downloaded and executed in
> the context of the current page's domain. Relative URLs to a
> worker script will resolve according to the domain of the hosting
> page:
>
> // http://cdn.net/dowork.js which was included from http://test.com/home.htm
> var w = new Worker("lib/workers/w1.js");
> // Tries to open http://test.com/lib/workers/w1.js
>
> and absolute URLs will fail due to the cross-origin restrictions
> on the new Worker constructor:
>
> // same setup as before
> var w = new Worker("http://cdn.net/lib/workers/w1.js");
> // Cross-origin failure from http://test.com/home.htm
>
> I looked back through the list and at the original worker proposals
> to try and discover why the same-origin restrictions is in place.
>
> The root of the issue seems to be the expectation that WorkerGlobalScope
> runs and executes everything according to its own location.URL.
> Thus, allowing http://cdn.net/lib/workers/w1.js to load in the
> previous example, would allow http://test.com/home.htm to potentially
> modify any data associated with cdn.net's domain (like through
> Indexed DB, or XHR, etc).
>
> One way to allow the CDN scenario to work would be to provide an explicit
> way to tell a worker to run in the host context, rather than the context
> that the Worker is loaded from (which is what <script> inclusion and
> importScripts does today).
>
> Since Workers _can't_ be loaded cross-origin [currently], the Workers
> are already running in the host context by virtue of this limitation.
> Codifying that a WorkerGlobalScope's execution environment is always
> that of the document that created it, and then allowing workers to be
> constructed from any URL would effectively solve the CDN problem IMHO.
>
> Later, when/if we open up cross-origin workers, we can provide a special
> way to instruct the workers to set their execution context to that of the
> URL they are loaded from.
>
> Thoughts from the group?

It's not an entirely bad idea.

We've solve the solution in a somewhat less elegant way. Since firefox
generally considers data:-uris to be same-origin with whatever page
loaded them, you can create a worker using a data:-uri which then
importScripts the cross-origin script. (This is relatively newly
implemented so I forget if it's in released versions of firefox).

But I can't really come up with any arguments against your proposal...

/ Jonas

Received on Wednesday, 7 December 2011 05:51:09 UTC