Cross Domain Web Workers
Asked Answered
B

3

5

I am aware that this question might be considered duplicate, but it is a new technology and I can not find a recent confirmation of my findings. I also think it potentially useful to have all the error messages in one place (feel free to add any other browsers).

trying to loads a worker script from another domain:

new Worker('http://otherdomain.co/worker.js');

I have set headers (using ModHeader Chrome Extension) to:

Access-Control-Allow-Methods:* Access-Control-Allow-Origin:*

But in Chrome I get:

Uncaught SecurityError: Failed to construct 'Worker': Script at 'http:otherdomain.co/worker.js' cannot be accessed from origin

Safari give me:

[Error] SecurityError: DOM Exception 18: An attempt was made to break through the security policy of the user agent

Firefox gives me:

SecurityError: The operation is insecure.

Is it still that this is not something we can do? If so, what is considered the best practise work around?

Basseterre answered 30/5, 2014 at 11:29 Comment(1)
just stumbled across this: https://mcmap.net/q/160742/-web-worker-settings-for-chromeLoyola
G
7

I know it's a little late now, but is this what you're looking for?

"Creates a url for the specified blob that can be passed to methods that expect a url. When done with the returned url, call revokeObjectURL() to free the resources associated with the created url."

This method easily allows you to create a Worker using a local script instead of a remote url.

Grunt answered 26/2, 2018 at 16:55 Comment(1)
Oh, I love this one!Horrocks
C
5

You are not allowed to create cross-domain web workers.

Note : The URI passed as parameter of the Worker constructor must obey the same-origin policy . There is currently disagreement among browsers vendors on what URIs are of the same-origin; Gecko 10.0 (Firefox 10.0 / Thunderbird 10.0 / SeaMonkey 2.7) and later do allow data URIs and Internet Explorer 10 does not allow Blob URIs as a valid script for workers.

Source: https://developer.mozilla.org/en/docs/Web/Guide/Performance/Using_web_workers

One workaround that I can think of is to create a server-side script to load the required remote JS file, and supply it to the browser from your domain.

Eg: You supply url to :

http://YOUR_DOMAIN/getRemoteJS.php

This PHP file will request the remote file on the server side, and echo it as the response, and set mime-type to application/javascript.

I have not personally tried this workaround, but you can perhaps look into it.

Good Luck!

Cawthon answered 30/5, 2014 at 12:2 Comment(4)
Nice idea, mega hacky though!Basseterre
Glad you like it, and I agree, its kinda hacky. Please mark it as the correct answer if it works for you. Thanks!Cawthon
I am holding out for a better one!Basseterre
You could probably also work around this with an <iframe> and postMessage? I wouldn't go there though - it's going to be fragile and difficult to understand.Pronation
L
0

There's a way to run cross-origin workers with:

  • fetching JS code of the worker
  • run worker from data: string or blob:

Working solution: https://github.com/CezaryDanielNowak/CrossOriginWorker

Laurettalaurette answered 21/10, 2022 at 14:54 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.