Last Comment Bug 756589 - testcase: importScripts works only with same-origin
: testcase: importScripts works only with same-origin
Product: Firefox
Classification: Client Software
Component: SocialAPI (show other bugs)
: unspecified
: x86 Mac OS X
-- blocker (vote)
: ---
Assigned To: Shane Caraveo (:mixedpuppy)
: Shane Caraveo (:mixedpuppy)
Depends on:
Blocks: 733414
  Show dependency treegraph
Reported: 2012-05-18 13:27 PDT by Shane Caraveo (:mixedpuppy)
Modified: 2012-05-28 12:06 PDT (History)
1 user (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Shane Caraveo (:mixedpuppy) 2012-05-18 13:27:47 PDT
The code does use nsIURI.resolve on any urls passed to importScripts, we should have a unit test for that.  As well, importScripts should support data URIs.
Comment 1 User image Mark Hammond [:markh] 2012-05-20 17:59:28 PDT
Please clarify: does this mean the "same origin" used by the browser itself, or the more relaxed "provider origin" we are using (which doesn't include the scheme)?  The distinction may be important.

Also, what is the use-case for supporting data URIs?  IIUC, a data url would have the javascript source embedded in it, so eval() could be used directly by the worker to support this?
Comment 2 User image Shane Caraveo (:mixedpuppy) 2012-05-20 23:19:41 PDT
importScripts is defined in the web worker spec.  IIUC, you can only import relative scripts, or at most same origin (proto+host+port) urls.
section 9.3.1
Comment 3 User image Mark Hammond [:markh] 2012-05-21 19:50:47 PDT
I'm actually not sure the worker spec says this at all:

* implies the origin is used to resolve relative URLs. has the word "fetch" with a link, and following that link it mentions an optional "same-origin flag" - but doesn't mention this flag - just the "synchronous flag".

* has an example where importScripts is used to load from

* is a chromium bug which talks about information leakage in cross-origin importScripts.  It implies the error is simply the leakage, not the fact that cross-domain importScripts works.

* implies no such restriction too.

FWIW though, gecko *does* currently have such restrictions - - but that may well end up being considered a bug...

All that said though, it would be prudent for us to enforce it too.  I think this means we should *only* accept relative URLs, otherwise we end up with a problem of http:// vs https:// (ie, bug 756021 is so we can have the same provider from a http and https URL, but if we enforce the same origin restriction here, the worker can't use a fully-qualified URL as either the http or the https one will fail to load in the other context)
Comment 4 User image Shane Caraveo (:mixedpuppy) 2012-05-28 12:06:17 PDT
for now, enforcing same-origin for importscripts.  We can loosen later if that makes sense.


Note You need to log in before you can comment on or make changes to this bug.